Under the hood¶

Re:lock’s patent-pending technology behind the Active API Armour consists of two main components - identity entanglement, enabled by our key generation algorithm, and chained ticket system.

Identity entanglement¶

Today more than 80% of successful attacks on APIs come from seemingly legitimate users and exploit authentication vulnerabilities. We believe that one of the key vulnerabilities is the fact that all of the current authentication standards verify user identity based on possession. If the user is in possession of some secret material, such as a token, key, certificate, or password, we consider them legitimate.

To address the need for innovation in that space, for the Active API Armour we have designed a new approach. We propose a direct, endpoint-to-endpoint authentication, based on a state rather than on possession.

In our approach each pair of users, a ‘producer’ and a ‘consumer’, are first introduced to each other. During the introduction they establish a root secret. This operation is completed only once, at the first interaction.

The root secret established by the two parties is unique to them. It is also only ever known to them, as it is generated within their secure software enclaves, never leaves this isolated environment, and is protected with encryption specific to it. Thanks to these characteristics it becomes their shared mutual identity.

The root secret is in a state of constant change. It functions in a feedback loop in which it is re-keyed asynchronously and mutually by both endpoints, during each request / response. We call this process identity entanglement.

Root secret establishment¶

The current version of the Active API Armour uses X25519, a variant of ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), for the initial, one-time exchange of the seed used to generate the root secret. It is our target to add the option to exchange the seed with some of the currently developed quantum-safe algorithms, such as the Kyber key encapsulation mechanism (KEM).

ECDHE is a key exchange method that two parties can use to negotiate a secure key over an insecure communication channel - it’s a well documented and known secure way for key exchange. X25519 is a specific elliptic curve, designed for use with ECDHE, that offers 128 bits of security (256-bit key size) and is one of the fastest curves.

         Bob                                     Alice
     random key      ------ request ----->    Public key
   (random bytes)                             random key
     Public key      <----- response -----  (random bytes)

     Shared key                               Shared key
 (HKDF derivation)                         (HKDF derivation)
Identity derivation                       Identity derivation

The shared seed is used as input for a key derivation function (HKDF) by both endpoints. The Armour derives a large, variable-size set of pseudo-random bytes. These bytes become the root secret - the shared mutual identity.

Root secret re-keying¶

After the initial establishment of the root secret with the use of ECDHE and HKDF, the API Armour uses re:lock’s patent-pending mutual key generation method to re-key the root secret with each request / response between the users.

Each request generates a new set of random bytes by deriving them from the shared root secret. The only input on both endpoints is a set of random numbers, transmitted between them with the ticket.

The numbers are converted with re:lock’s KDM algorithm into specific positions in the root secret material that enable both endpoints to asynchronously generate the same bytes.

       Bob                                     Alice
  Shared identity                         Shared identity

   random bytes      ---------------->  (locate positions)
(locate positions)   <----------------     random bytes

(identity rekeying)                    (identity rekeying)

The numbers transmitted with the ticket are not considered a secret. They contain no underlying cryptographic information and can only be used by these two exact endpoints. Even if intercepted, they provide no value for a potential adversary.

Chained ticket system¶

Each single API request, secured with the API Armour, is based on an exchange of a unique, ephemeral, one-time-use ticket.

Re:lock’s patent-pending system of tickets builds on some design elements of double ratchet, used by the Signal or iMessage protocols, and introduces several innovative and proprietary features. Some basic distinctive notions of the chained ticket system are:

The Armour can issue only one ticket for the same purpose at the same time
Alice can request only one ticket at a time, using the last issued ticket as a request permission (tickets are chained)
Tickets are active only for the exact duration of the request, preventing interception or use for another request
Tickets need to be validated and stamped at both endpoints to enable decryption of the payload (entangled identity)
In the event of a fully compromised consumer, an adversary may be able to issue unauthorized tickets but will always be detected as soon as there is a ticket request from the legitimate process (ticket collision), triggering the automated fail-safe disconnect

If you want to know more about the chained ticketing system, would like to access our patent applications, or are interested in a possible co-development or partnership, feel free to contact us at contact@relock.id.

Cryptographic suite¶

The Armour uses the highest standards of encryption. The cryptographic suite currently used by the software is X25519_AES256GCM_SHA256_Ed25519. This integrates 256-bit (64 bytes) AES with SIV mode and uses X25519 for key exchange, SHA512 for hashing and Ed25519 for digital signatures.

X25519 is an elliptic Diffie-Hellman key exchange using Curve25519. It allows two parties to jointly agree on a shared secret, using an insecure channel.
Ed25519 is a public-key cryptographic algorithm used for digital signature generation and verification. It is based on the elliptic curve cryptography and is considered more secure than other commonly used algorithms, such as RSA and DSA.
BLAKE is a cryptographic hash function based on Daniel J. Bernstein’s ChaCha stream cipher, but a permuted copy of the input block, XORed with round constants, is added before each ChaCha round.
The AES-256-GCM construction is composed of the AES block cipher utilizing Galois Counter Mode (GCM). Authenticated encryption with associated data (AEAD) are encryption schemes which provide both confidentiality and integrity for their ciphertext. They also support providing integrity for associated data which is not encrypted.
The AES-GCM-SIV construction is defined in RFC 8452 and is composed of the AES block cipher, utilizing Galois Counter Mode (GCM) and a synthetic initialization vector (SIV). The SIV construction is defined in RFC 5297. Depending on how it is used, SIV allows either deterministic authenticated encryption or nonce-based, misuse-resistant authenticated encryption.

Additionally, the Active API Armour uses a proprietary key generation called KDM. The algorithm allows the program to generate multiple, unique, ephemeral keys based on the root secret, that are used for encryption of the requests, tickets, as well as root secrets within the enclave.

Payload layer security¶

All keys used for encryption by the Active API Armour are ephemeral and generated by the users’ enclaves based on their shared root secrets.

The keys are generated separately at each endpoint for each operation of encryption / decryption. Keys are also unique for each request / response and, as a result, live only in memory and just for the exact duration of the operation.

The method of their generation implies that the keys are never stored at the endpoint, or shared or exchanged between the endpoints. The only information shared between the endpoints is the random number included with the ticket which is used to re-key the root secret.

The use of ephemeral keys and continuous re-keying prevents attacks on keys. Any attempt of extraction or exfiltration from memory is impracticable, even for a talented attacker. From the perspective of key management, there are no additional actions that you need to undertake to ensure security. The ephemeral keys and root secrets require no management, saving you significant time and resources.

Available encryption variants¶

Active API Armour offers two default variants of encryption, each benefitting equally from the advantages of the use of ephemeral keys: in-application encryption and in-enclave encryption. These variants differ in terms of the flow of encryption.

You should consider exploring both variants and using the one that presents a better fit for your specific application.

In-application encryption¶

In-application encryption is a secure variant recommended for most typical use cases. In this variant the application receives a validated ticket from the Armour and with it, in the same operation, gets an ephemeral encryption key generated from the root secret. The application then uses the ephemeral keys to encrypt / decrypt the request and the response.

if response := http.get('http://' + host,
                        headers={'Content-Type': 'application/json',
                                  **arm.headers()},
                        json={'time': arm.encrypt(time.time())}):
    if ticket := arm.stamp(response.headers):
        logging.info('Decrypted %s', arm.decrypt(response.json().get('time')))

In this variant the ephemeral key exists temporarily outside of the secure software enclave as it is used for encryption by the application, but retains all the benefits related to its ephemeral character. Nonetheless, in theory, there is a small window of opportunity for an attacker to attempt key extraction from the application’s memory.

In-enclave encryption¶

In-enclave encryption is an enhanced variant intended for use with data of the highest sensitivity that requires more resources, given there are additional request operations performed.

In this variant, the application sends sensitive data to the secure software enclave containing the Armour. The Armour then generates separate ephemeral keys for each encryption call, encrypts the data, and returns ciphertext to the application.

if response := http.get('http://' + host,
                        headers={'Content-Type': 'application/json',
                                  **arm.headers()},
                        json={'time': arm.encrypt(time.time(), True)}):
    if ticket := arm.stamp(response.headers):
        logging.info('Decrypted %s', arm.decrypt(response.json().get('time'), True))

Once one endpoint sends the ciphertext to the other endpoint, the receiver will be required to make a request to the secure enclave. Only their corresponding Armour will be able to decrypt the ciphertext.

The level of security of this operation is enhanced, as in this variant the ephemeral keys never leave the secure software enclave and are known only to the Armour. Neither the user application, nor any other party including with root privileges, has access to them, not even for the duration of the encryption / decryption operation.