What is Hermes? An overview. #

Hermes — cryptographic framework for building multi-user end-to-end encrypted data storage and sharing/processing with zero leakage risks from storage and transport infrastructure (so called end-to-end encrypted zero knowledge architectures).

Hermes acts as a protected data circulation layer with cryptographic access control for your distributed application, with zero security risk of data exposure from servers and storage.

Hermes allows deploying end-to-end encrypted data exchange, sharing, and collaboration in your apps. Hermes is platform-agnostic: it works for mobile, web, or server applications storing data in any database/datastore.

Hermes-core is a proof of concept implementation for Hermes — a practical data security scheme with the reference implementation, which enables distributed sharing and collaboration, enforcing access control cryptographically, while the maximum possible number of security guarantees for the protected data is preserved even in the case when one or more parts of the system are compromised.

Hermes in a nutshell #

Hermes-core is a proof of concept for Hermes – a practical data security scheme with the reference implementation, which enables distributed sharing and collaboration, enforcing access control cryptographically, while the maximum possible number of security guarantees for the protected data is preserved even in the case when one or more parts of the system are compromised.

Hermes is an end-to-end encryption methodology for manipulating structured records with crypto-controlled CRUD rights. Hermes-core is a proof-of-concept implementation of Hermes as a standalone library, which can be easily embedded into a networked or local application.

Hermes maps privileges — read, write, update, delete — to cryptographic keys, in arbitrary granularity towards protected object’s structure. Hermes does that via cryptographic process, so no attack on Hermes’s execution flow can affect the protected data - in the worst case, it will lead to nothing worse than a denial of service.

Hermes relies on stacking several cryptographic processes (symmetric and asymmetric encryption without interactive key exchange, MACs) and managing keys/data structures/encryption scopes. It uses battle-proven cryptographic algorithms and their implementations and is built using special encryption abstraction library Themis, which allows swapping problematic crypto-primitives or even whole algorithm families without changing a line of high-level code.

Access is managed via private keys, sharing, and permission set assignments. These procedures rely on the use of Public Key Infrastructure. A bare-bones version of such infrastructure is aimed at easy integration using a simple flat file storage because Hermes is aimed at integration with any data and trust sources.

Hermes is a proprietary framework licensed by Cossack Labs.

Hermes-core code repository is open-source (AGPL 3.0), created for developers and security community to illustrate the proof of concept of Hermes, which should be used for studying and verification of the methodology and cryptographic backend. Hermes-core is not a production version of Hermes but more of a sneak peek at its core layer.

Drop us an email to info@cossacklabs.com if you are interested in commercial license for Hermes or support.

What’s so unique about Hermes #

Access control list (ACL) in Hermes is cryptographic.
Hermes binds over (almost) any data structure.
Hermes works with any network/server/client layout (to Hermes it all is just data).

Hermes represents a practical scheme that takes into account a number of important requirements:

Presence of only strong end-to-end encryption between the entities;
Provision of enforced security simultaneously with access policy distribution to data, compared to algorithmic ways and operational guidelines;
Processing of sensitive data in plain text only in user’s context and storage of sensitive data on Server-side entities in encrypted form only.

When at least some of the aforementioned requirements are fulfilled, it significantly increases the security level of the system.

Use cases and industries #


Healthcare	Share FHIR and other medical records safely and distribute granular access to personnel in a secure way. Cut HIPAA costs by pushing many security controls to the encryption layer.
Finance	Store and process customer payment data securely, minimise insider threats and enable secure, accountable cross-organisation data exchange.
Enterprise	Protect commercially sensitive data and enforce access control, integrate with existing PKI and IAM stack, enforce group policies and efficient key/storage management – while keeping the data end-to-end encrypted.
B2C: Customer apps	Instill greater trust in your product by implementing end-to-end encryption of customer data. It’s not only E2EE messengers that deserve the right to use user trust as competitive advantage.

A typical use-case for Hermes: an online medical service where the patients securely interact with the staff of multiple medical institutions. For example, a patient’s records contain a number of results for medical examinations. The patient’s personal physician needs to be able to access all of them, while the employees of the medical institutions need to be able to access only the latest results to adjust their activities towards the patient. Leaving access control management to a medical service opens up a risk of an accidental privilege misplacement or an intentional data leak. Being able to manage the access permissions only from trusted endpoints enables provable security for collaboration of such datasets.

Enforcing access control cryptographically

The access control distribution in Hermes is based on possession of cryptographic key and is much stronger than traditional operation guidelines and algorithmic mechanisms.

Provision of controlled secure data sharing in an environment with limited trust to server

Hermes allows using servers with limited trust level. A server is only used for storage of encrypted sensitive data.

Why Hermes does it better #

Sensitive data is only ever processed in plain text within the client execution environment. Server-side components only operate with encrypted sensitive data;
Compromisation of a single server-side component causes only limited damage;
Hermes only uses end-to-end encryption with mutual authentication between the entities;
Hermes only uses well-examined, extremely secure cryptographic algorithms.

Strong cryptographic base #

Hermes (and correspondingly, Hermes-core) is built on top of Themis, which is a high-level cryptographic services library that allows you to protect data at rest (in your database, files or wherever you store them in your application) and data in motion (e.g. travelling between client and server, server and server, application and application, etc.).

Features #


End-to-end data security	Client apps are responsible for data encryption and access control through using Hermes, while the server-side knows nothing about the nature of data.
Data model-agnostic	Hermes imposes no limitations on data structure and database choice.
Bulletproof cryptographically	The ACL in Hermes relies completely on cryptography, where trust is bound to client’s keys. As long as the keys are safe – the system is safe.
Security cornerstone	With a solid security foundation on the data layer, building other security controls gets easier, the risk model becomes precise, and the overall security cost goes down considerably.
Defence in depth	Hermes provides a foundation layer of data protection, Hermes is fully compatible with the following layers of security controls: TLS, firewalls, WAFs, SIEM, IDS, etc.
Searchable encryption ᵉ	available for enterprise customers in a separate license
Provides pseudonymisation ᵉ	available for enterprise customers in a separate license
Audit log protected cryptographically ᵉ	available for enterprise customers in a separate license

How Hermes works #

Hermes operates with data that is subdivided into records that represent the hierarchy of recordsets and groups of recordsets. Each blob of data is encrypted using a symmetric key, from which a set of hashes is generated. Possession of a symmetric key by a user allows reading and carrying out other processes on hashes (including with writing data).

In Hermes-core a document equals a block and is not subdivided further as it is a basic building block for the hierarchic infrastructure of Hermes.

Hermes core

Hermes entities #

There are 3 storage entities in Hermes (and, consequently, in Hermes-core) that constitute the Server side:

Data store contains the hierarchy of encrypted objects.
Credential store stores keys and hashes, asymmetrically encrypted in such a way that can only be decrypted by authorised user’s private key. Those can contain access control key which grants READ access and Update Tag which allows performing WRITE operations.
Keystore contains the symmetric keys (for READ and UPDATE), with as many copies of these keys as there are users authorised to access to the record, where every copy is wrapped (asymmetrically encrypted) with a public credential of the respective authorised user. If the permissions to READ and to WRITE extend to not just blocks, but to the list of blocks, they turn into permissions to DELETE/ADD elements.

The 4th entity of Hermes is Client:

Client (or clients) is the active entity in the Hermes architecture, the one that actually produces or consumes the data. Client only possesses the keypair that allows decrypting the asymmetrically encrypted data from the Server. The READ permissions are always checked on Client. The absence of the key for performing READ operations will not allow Client to decrypt the downloaded piece of data. The WRITE permissions are checked both on Client and Server so they cannot “fool” each other.

Glossary of common Hermes' terminology #

This is a table of common terms used to describe the processes and notions of Hermes (and, consequently, Hermes-core).

Term	Definition
Record	Atomic (granular) data unit within the Hermes’ scheme.
Recordset	A document that consists of all records with appropriate Update tags.
Update tag (UT)	Message authentication code of a record. A UT is used for the UPDATE authorisation process. Belongs to the Data store.
Access control key (ACK)	Symmetric key that allows performing operations on data. Belongs to the Keystore.
Access control policy (ACP)	A combination of access rules set for the specified records.
READ ACK (READ token)	ACK for performing READ function on the data. Belongs to the Keystore.
UPDATE ACK (UPDATE token)	Symmetric key for performing UPDATE function on the data. Belongs to the Keystore.
Key encryption key (KEK)	Cryptographic key (symmetric or asymmetric) used for encrypting other cryptographic keys in the Hermes’ scheme. Belongs to the Keystore.

Documentation and papers #

Hermes page and Hermes product sheet contain latest details about features and technical environments (supported technological stacks, databases and client sides).
Project’s GitHub Wiki contains the ever-evolving official documentation, which contains everything from deployment guidelines to use-cases, including charts and tutorials you might find useful.
Ever-evolving Implementing Hermes-based Security Systems document describes the details of implementing Hermes-based systems in the real world.
The scientific paper “Hermes – a framework for cryptographically assured access control and data security” explains the concept behind Hermes, math model, risk & threats analysis and provides implementation details. Also find it in the IACR Eprint Archive. Useful for security engineers and cryptographers.