Security considerations¶
The API Armour adopts a threat model which includes multiple forms of endpoint/client compromise. While adversaries are in a strong position if they have compromised a consumer, there are still situations where security guarantees can be recovered thanks to the constant re-keying properties offered by the Armour.
In this section we will explore the consequences and recommendations regarding the following compromise scenarios:
The attacker has access to an ephemeral symmetric AEAD key
The attacker has access to new request ticket generation (consumer compromise)
The attacker has access to a root secret on consumer or producer
The attacker has access as an eavesdropping actor (full state compromise)
Compromise of symmetric keying material¶
As described above, each API Armour request/response creates a new set of ephemeral secrets. These secrets are then used to re-key a per-sender root secret, which in turn is used to create a per-sender ephemeral key with additional data (AEAD), that is then used to encrypt request / response-level plaintext messages.
Because of the properties of the key derivation function from the root secret, it is not possible to compute the root secret from any of its corresponding AEAD keys or compute the root secret n-1 from root secret n.
Below, we consider the compromise of each of these pieces of keying material in turn, in ascending order of severity. While this is a limited form of compromise, it can be realistic in cases of implementation vulnerabilities where only part of the memory leaks to the adversary.
Compromise of AEAD ephemeral keys¶
In some circumstances, adversaries may have access to specific AEAD keys and nonces which protect a request-level payload. Compromise of these keys allows the attacker to decrypt the specific payload encrypted with that key but no other; because the AEAD keys are derived from the root secret, an adversary cannot generate the next root secret and hence not the next AEAD key.
In the case of an application message ‘payload’, an AEAD key compromise means that the encrypted application payload will be leaked, as well as the signature over that payload. This means that the compromise has both confidentiality and privacy implications on the future AEAD encryptions of that chain. In the case of a payload, only the privacy is affected, as the signature is revealed. Note that under that compromise scenario, authentication is not affected in either of these cases. Successful decryption of an AEAD encrypted payload, only guarantees that some part of information leaks to adversaries.
Compromise of the AEAD keys does not allow the attacker to send an encrypted message using that key and cannot send a message to a producer or consumer which appears to be a valid root secret derived key since the root secret will not match on both sides. This applies to all forms of symmetric key compromise described in this section.
Compromise of root service material¶
When a root secret is compromised, the adversary can compute both the current AEAD keys for a given sender as well as any future keys for that sender. Thus, it can decrypt current and future messages by the corresponding sender. However, because it does not have previous root secrets, it cannot decrypt past messages as those secrets and keys have been deleted.
The Armour provides post-compromise security against an active adaptive attacker across the time for AEAD encryption. That means that as soon as a root secret is re-keyed, if the attacker does not have access to additional required secret material, they will not be able to access any protected payload.
We consider the compromise of a root secret as highly impractical. Root secrets are subject to continuous re-keying and the re-keying material is delivered by both endpoints, thus requiring the attacker to turn off the legitimate process, leading to easy and fast detection.
Compromise of consumer environment¶
When a consumer environment is compromised, the adversary can make a direct request to the isolated enclave and generate new tickets. Thus, has the ability to make the correct request to the producer and grab the response ticket, and decrypt the response payload. However, because it does not have previous payloads and tickets, it cannot decrypt past payloads as those secrets and keys have been deleted. In the event of an ephemeral AEAD key compromise, a single request’s payload and its signature will be leaked.
Active API Armour provides post-compromise security against an active adaptive attacker across consumer environments. Configuration of the ticket system allows for an easy detection of a situation when there is more than one ticket in the ecosystem. The window of attack lasts as long as the legitimate process is not taking any action. Once the legitimate process requests a new ticket, the system will issue two different tickets to the attacker and to the legitimate process, leading to an evident collision between them. This triggers the fail-safe disconnect of all tickets issued within the same bundle.
RECOMMENDATION: We strongly recommend the implementation of periodical health checks between consumer and producer (this may be just an empty periodical request/response).
RECOMMENDATION: We strongly recommend the implementation of periodical ticket generation on the consumer side (‘empty’ ticket generation).
Full state compromise¶
In real-world compromise scenarios, adversaries often target specific devices to obtain parts of the memory or even the ability to execute arbitrary code in the targeted process. Additionally, many applications retain unencrypted data. In such a case, the adversary does not have to break the encryption to access request / response payload. In a full state compromise the attacker may also use a legitimate process to make a request to the Armour and will receive a response.
RECOMMENDATION: If payloads are stored on the device, they should be protected using encryption at rest, and the keys used for that should be stored securely using dedicated mechanisms on the device.
RECOMMENDATION: If the threat model of the system is against an adversary which can access the payload on the device without even needing to attack the Armour, the application should delete plaintext and ciphertext data as soon as practical, after encryption or decryption.
Note that none of the secrets used by the program require, and are suitable for, protection by HSM or other hardware enclave features. The only secrets that exist beyond the duration of a single encryption / decryption are the root secrets, and these secrets are re-keyed and completely modified with high frequency and reside in the isolated secure software enclave.