What is Cumulus4j and who is it for?

Cumulus4j provides an encryption layer that protects application-data from the access of the company that hosts the application (i.e. cloud infrastructure providers). It is a plug-in to the DataNucleus access platform. Cumulus4j targets Java developers of cloud and web-based systems that use JPA or JDO for persistence.

Why not simply use an encrypted file system?

An encrypted file system (e.g. LUKS, TrueCrypt) uses one single key for a whole device. Additionally, once opened, the data is accessible plain text while the application is running. Cumulus4j on the other hand uses many keys to encrypt the data, so that if one key is stolen it will only reveal access to a small part of the data. Furthermore, Cumulus4j keeps plain text data and keys only in memory temporarily; data will never be written do the datastore in plain text.

Why does Cumulus4j separate its data?

Cumulus4j keeps two types of data, the actual application-data and index-data that is kept in order to implement efficient queries. In order to increase the security of your data Cumulus4j supports the physical separation of these two, i.e. using separate infrastructure providers for each one.

Is the encryption done on the server side?

Yes, currently Cumulus4j encrypts and decrypts the application-data while writing to and from the datastore; see the theory section for more details. The decrypted data should then be transferred to the client using secure techniques like HTTPS.

Isn't client-side encryption better?

Of course, the degree of data protection is much higher, if keys never leave the trusted environment of the client. In its first project phase the Cumulus4j project provided server-side libraries. This is to ease integration into existing applications as these libraries can be used mostly transparently to the developer. However, in a coming phase of the project, starting early 2012, a possibility for client-side encryption will be provided, too.

Where are the keys kept?

The keys Cumulus4j uses for encryption are transferred to the server-application on demand (e.g. for a query execution) and forgotten quickly after usage. The keys are never stored in persistent memory on the server-side. The keys are actually kept in another physical location. This can be the client-computer itself or a local server within the client's internal network or a separate server far away from the databases (i.e. hosted by a company that has no relation to the company hosting the actual application).

For this purpose, Cumulus4j provides two kinds of key-storage and key-management: A local, file-based key-store and a web-service (key server). Both can be accessed by the user via a command-line application or by the developer via a unified API (which is the same for both storage systems). See the key-store documentation for details.