SafeCloud Platform Components

SafeCloud has developed reusable components for building cloud solutions with great security. Click on the technology names below to learn more.

Secure communication
Component: Vulnerability-tolerant channels Protected channels Route-aware channels
Gives: Tolerance to vulnerabilities in components Decreased risk of fake certificates; resistance to port scans and enumeration of network infrastructure Improved confidentiality with warnings about route hijacking and making harder access to communication
API: Extended secure socket API Extended secure socket API Extended secure socket API
Secure storage
Component: Secure block storage Secure data archive Secure file system
Gives: Block storage on individual data centers with fine control over data placement Entangled immutable data storage for protection against tampering and censorship Distributed secure file storage leveraging the secure block storage
API: Key/value REST (S3 or similar) POSIX-like
Secure queries
Component: Secure database server Secure multi-cloud database server Secure multi-cloud application server
Gives: Privacy of data against the server Privacy of data against non-colluding servers Privacy of data against non-colluding servers and clients

Integration blueprints

Possible combinations of SafeCloud components

This figure illustrates how the SafeCloud technologies can be used together to build applications with superior security guarantees. One line on this figures means that it makes sense to build an application that uses these technologies together.

We will now explain the justification behind these lines.


All SafeCloud's secure communication (SC) technologies have similar integration properties. Each of the SC technologies can be used by an application that uses the socket API to connect to other applications. This makes integration easier for both client-server and peer-to-peer applications that need additional assurances about the security of its channels.

SC technologies can be combined with each other, but this should be done after considering the need for each particular set of guarantees. Typically, if an application can use one SC technology, it can use any of them.


The storage technologies are more diverse than the communication technologies. Firstly, SS1 is by itself a backend for SS2 or SS3 that is not intended for use separately. SS2 is a unique storage system that supports its own category of applications with its entangled, censorship-resistant storage. As such, it makes sense to use SS2 in a secure information system with secure transport layers, but doesn't integrate directly with any of the query systems.

SS3 can be a secure storage backend for all SafeCloud query systems SQ1, SQ2, and SQ3 (although it makes less sense for the last of them). While one can imagine a system that uses SS3 and any of the communication platforms, there is no direct value in combining them.


While all three SafeCloud query engines provide a SQL interface, they support different applications. For example, information systems based on SQ1 and SQ2 can benefit from additional security offered by all SCx technologies. SQ3 implements its own protocol between all peers in the system and SC solutions would be hard to integrate.

All SQ technologies can be combined with SS3 for additional storage security, but there is no direct benefit of combining SQ technologies with SS2.

Example architectures

Classical information system with SafeCloud Security
Censorship-resistant information system