EDS – Encrypted Data Share

EDS, Encrypted Data Share, works as a "PGP for the Cloud." It is designed as a backend component with the vision that it should be possible to exchange data between multiple parties using encrypted storage. The data exchanged between the parties can be anything from simple files to complex data objects – EDS only cares about bytes.

Via the public (REST-based) API, it is possible to access the internal logic, where keys are unlocked, based on user credentials, and used to encrypt and decrypt data, storing only encrypted keys and data. Using the same basic mechanism as PGP, combining Asymmetric & Symmetric keys, it is possible for multiple parties to exchange data safely and securely.

Since EDS only focused on bytes and does not have any care for more information, it can be used to share either files between users or data objects between apps or applications. This makes EDS the perfect companion for anyone who has Data Protection & Privacy concerns, such as GDPR.

EDS is written in Java 25 / Jakarta EE 11, with no third-part dependencies, meaning it can run on any Host or in any Cloud where a Jakarta EE Container is available. Currently, only the PostgreSQL database is supported, but thanks to the flexibility of Jakarta EE, it is possible to use any database desired. Testing of EDS has been done with WildFly and Quarkus.

Build, Install, and Run

The final version 1.2 can be downloaded from haugr.net, version 2.0 will be a major upgrade, with a new domain, project name, and various internal changes that make it a breaking update. Initial development of version 2.0 has completed, with no more changes in the pipeline. The next phase will focus on testing to guarantee that the stability will remain high. The build requires Java 25, and Maven.

In the root folder, there exists a small script, eds.sh, which can be used to build the entire project, including running all tests and quality checks.

OpenAPI Specification

in the accessories/release folder, there is an OpenAPI Specification file, openapi.json, which can be used to generate client code or documentation for the REST API.

Software Bill of Materials (SBOM)

The build can generate CycloneDX SBOM files (specification 1.6), in both JSON and XML format, via the CycloneDX Maven Plugin. SBOM generation is disabled by default, and is enabled with the sbom profile:

mvn clean package -Psbom -DskipTests

This produces the following files:

• target/eds-<version>-cyclonedx.(json|xml) – the aggregated SBOM, covering all modules of the project.
• <module>/target/<module>-<version>-cyclonedx.(json|xml) – an SBOM for each individual module, e.g. eds-quarkus-pg/target/eds-quarkus-pg-2.0-SNAPSHOT-cyclonedx.json.

The SBOM files are attached to the build, so they will also be installed or deployed together with the other artifacts when running mvn install -Psbom or mvn deploy -Psbom -Prelease. Test scoped dependencies are not included.

Note, the plugin needs online access to Maven repositories, so it is skipped when Maven runs in offline mode (-o).

The CI Build scans the aggregated SBOM with Grype, and fails if a vulnerability with severity High or Critical is found. The same scan can be run locally with:

grype sbom:target/eds-2.0-SNAPSHOT-cyclonedx.json --fail-on high

Vulnerabilities which have been reviewed and found not to apply to EDS, can be suppressed in .grype.yaml, together with a justification.

Container SBOMs

The Maven SBOM only covers the Java libraries. The containers from the Docker Compose setup in accessories/docker also contain operating system packages and a Java runtime, so the CI Build generates a CycloneDX SBOM for each container image with Syft:

• target/container-eds-quarkus-cyclonedx.json – the EDS image, built from accessories/docker/Dockerfile.quarkus.
• target/container-postgres-cyclonedx.json – the PostgreSQL image referenced in docker-compose.yml.

Both are scanned with Grype. The EDS image fails the build on High or Critical findings, the PostgreSQL image is a 3rd party image, so its findings are only reported. All SBOMs and vulnerability reports are available as build artifacts. The container SBOMs can be generated locally, after the Maven build, with:

docker build -f accessories/docker/Dockerfile.quarkus -t eds-quarkus:local .
syft scan eds-quarkus:local -o cyclonedx-json=target/container-eds-quarkus-cyclonedx.json
syft scan postgres:18-alpine -o cyclonedx-json=target/container-postgres-cyclonedx.json
grype sbom:target/container-eds-quarkus-cyclonedx.json --fail-on high

Who is this for

Anyone for whom data protection is important may find EDS useful. It is designed so everything is stored encrypted in a way, so only those who the data belongs to may access it. This is achieved by ensuring that the full control over all Keys is placed with the users.

Security Features

Besides encrypting all data stored, the EDS also has a number of features to ensure that the security is as high as it can be, considering that it can be deployed in a "hostile" environment.

• MasterKey – The MasterKey is used to encrypt and decrypt various information, and it must be set during startup, since it is not persisted anywhere.
• Invalidate Accounts, this allows a member to force the keys to be replaced internally, so it is possible to log in and view Circles. However, it will not be possible to extract data, as the keys are different from the ones that were used in the Circles.
• Data Corruption checks to verify if there have been alterations to encrypted data, which may result in inability to properly extract information.

Release Plan

This is the EDS 2.0 development branch, with the these features completed:

• Migrate code base to Java 25
• Migrate code base from Java 8 to Java 11
• Upgrade code base to Java 17
• Migrate from Java EE 7 to Jakarta EE 8
• Upgrade JavaEE/JakartaEE to JakartaEE 10
• Convert Date Objects to Java 8+ Time Objects
• Migrate to the haugr.net domain
• Rename Packages & Project to EDS

Wish to join

The overall quality of the software can only improve if more eyes look at it and help with implementing features and adding more tests. If you wish to join, please contact Kim Jensen (see below).

Code Quality

Code quality is important, which is why testing and quality checks are crucial. Unfortunately, with version 2.0, it is time to consider alternatives to FitNesse & Coverity from Synopsis, since neither supports Java 25.

The code is checked against as many analysis tools as possible. The final code must have zero issues of any kind before it is considered ready to be submitted into the main repository.

Documentation

Documentation of code is also important, having silly comments is meaningless, but often it helps to add inline comments to explain intentions and reasoning for choices made. Commenting on code is banned, if it is commented out, it is meaningless and should be removed.

Software License

The EDS is released under Apache License 2 or APL2.

Contact

Kim dot Jensen at haugr dot net