EDS

Security Features

EDS is written a as a pure Java / Jakarta EE backend solution. It is thus relying on very solid and proven Java Server components, which is frequently seeing security updates. By not relying on anything else, the security problems have been minimized.

All data stored in EDS is encrypted using a combination of a MasterKey and a CircleKey. Both of these are AES based Symmetric keys, and CircleKeys are protected using a RSA based Asymmetric key. The entire setup is build around the notion that control of keys and data belongs to the owners.

This also means that EDS is the perfect companion for anyone requiring a secure storage to be GDPR compliant.

Rock Solid Backend Service

EDS, is designed as a standalone component, which runs in any Jakarta EE based container. It is not relying on any third-party dependencies and via the REST based Web Services, it is possible to embed EDS into other systems as a Microservice or use it as a backend component for other applications, websites, or mobile apps.

Since EDS is build around Jakarta EE and thus relies on JPA (Java Persistence API) for database communication, any RDBMS will work. For the cryptographic operations, JCE (Java Cryptography Extension) is used, so problems or errors in this will be corrected by the Java system.

Circles of Trust

EDS is based on a the following use cases:

Use Case 1: Two or more parties wishes to securely share data.

Use Case 2: A Web shop needs a secure way to store customer data, so only the relevant parties can access it.

Introducing "Circles of Trust", a simple concept, build around the same principles as PGP (Pretty Good Privacy). Any member can create a Circle, and add other members to it. EDS will then create a CircleKey, which is used to encrypt and decrypt all the data, which the members wishes to exchange.

Presentations

YouTube presentation from BSides Munich 2018.

Documentation

For installation instructions, see the Readme file provided along the EDS sources on github.

For developers, there is a full documentation of the API available.

Who is this for

EDS was created initially, as a way to add an extra security layer into existing web-based applications. It uses JCE, Java Cryptography Extension, for all cryptographic operations, meaning that it will work independently of what is offered by Hosting or Cloud Providers.

If you are using a Hosting or Cloud Provider for your Web-based Application, EDS may improve your security. Even if you aren't using a Hosting or Cloud Provider, EDS may still improve the data stored, by adding an additional encryption layer. This way, if your server is compromised your data may still be secure.

Disclaimer

The old paper Reflections on trusting trust shows that perfect security is an illusion. For any system running, there is simply too many aspects to consider. From flaws in servers, missing security patches, undisclosed bugs - or flaws and bugs in your own Application.

Generally, there are 3 areas where the security will come up short:

Hosting or Cloud Provider
If the Provider is not taking their customers data security seriously, either by not patching their software or protecting their services using firewalls. Then, EDS cannot give you a guarantee that your data is secure. As EDS requires that the underlying software to run Java & Java EE must be properly updated.
Network Communication
Today, SSL should be standard for all Web-based communication, regardless if it is dynamic or static web-sited or it is internal communication between service layers. If just one part of the entire system has been compromised, all parts may be compromised by insecure communications. SSL should therefore be applied in all layers, and the setup should be made as secure as possible by limiting or removing protocols and increase key strength. See SSL Labs for testing and hints - to start, you can use Let'sEncrypt to get free SSL Certificates.
Data Processing
When handling a request, EDS requires that the Data and Keys are available in the memory and CPU of the server - although the time of most requests can be measured in milliseconds, it may be possible for someone skilled enough to extract the information using memory dumps.

Of the above mentioned shortcomings, the first two will be the easiest to compromise, and also the easiest to add processes to prevent. Meaning, that the last one may both sound and appear as the worst. However, if this is something that is of concern, you may reconsider using a Provider for your Application, as nothing will be able to give you the level of trust you requires except hosting the servers yourself. And even if you host the servers yourself, EDS may still give you an additional security layer as your stored data is encrypted so even if someone compromises your system, the data and keys should still be secure, as it is stored encrypted.

PGP for Clouds

Data Protection & Privacy is a right, not a privilege

About EDS