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. Additionally, using functionality for indexing and querying data provided by the server increases the performance.

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. However, many features like especially querying data are very hard to perform efficiently on the client-side. Therefore, Cumulus4j currently does not (yet) provide any client-side encryption.

The Cumulus4j-team already developed plans for a full-featured client-side encryption including query-engine, but implementing these plans is far from trivial. Since the degree of data-protection provided by Cumulus4j already now is far higher than the current state-of-the-art, the team decided to focus on providing a reliable and fast solution for the server-side, first. If the market as well as fellow developers (this is a free software project!) are interested in both the current solution and the further development for data-protection on the client-side, we're happy to implement the plans we already devised.

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.

How can I manage my data? My query program shows only BLOBs!

Since Cumulus4j encrypts all data before writing it into the underlying database, it is logical that you cannot use your normal query program for managing your data. Either you extend your application with administration features or you take a look at Vestigo - The JDO/JPA Query Tool And Browser. Vestigo supports Cumulus4j and you can not only query your encrypted database on the object level without even noticing it's encrypted, but also modify your persistent data.