DIDComm Messaging is a communication method built on top of Decentralized Identifiers (DID).
In this article, we introduce the cryptographic primitives used by DIDComm and discuss some of its resulting security properties, showing that it does not guarantee Forward Secrecy. In a future article, we will extend our analysis to show its Post-Compromise Security properties, and the (lack of) resilience against Key-Compromise Impersonation attacks.
We refer to the security properties of static and ephemeral Diffie-Hellman key exchanges in several sections of this article. This article provides a quick summary of such concepts.
NOTE Whereas DIDComm has support for features (e.g. DID rotation) that MAY be used to achieve forward secrecy, in our analysis we focus on the properties that are (in all scenarios) GUARANTEED by the protocol.
Forward secrecy
Forward secrecy (FS), also known as perfect forward secrecy (PFS), is a property that protects past communications against future key compromises. In the context of key exchange mechanisms, forward secrecy ensures that the keys derived in a protocol run remain secure against the future compromise of any static (long-term) private material used during the agreement [1, 2].
FS is typically achieved by the frequent generation of fresh session keys, while ensuring that subsequent keys do not leak information about previous ones. While this is relatively simple for session-oriented protocols like TLS, in asynchronous systems (e.g. asynchronous messaging) the required orchestration is more challenging and many systems (e.g. PGP and some versions of Apple iMessage) do not provide this guarantee [3].
DIDComm goals
The DIDComm specification explicitly states the protocol’s security goals. In the context of this article, we are interested in message confidentiality which is captured as
MUST prevent unauthorized third parties from learning who’s communicating about what
The specification explicitly leaves forward secrecy outside the scope of the protocol, stating
perfect forward secrecy is not formally required due to the lack of a session construct, but similar outcomes must be achievable, as described in the Guidebook.
The linked Guidebook argues that forward secrecy is feasible in DIDComm, as long as keys in DID documents are frequently updated or DIDs are rotated. We concur.
The rest of this article analyses the security properties of basic DIDComm usage where no rotations are performed. We hope this text serves to encourage DIDComm users to make extensive use of rotations, and to further the discussion on ways to make such rotations the default for all DIDComm-based communications.
Key exchange and encryption in DIDComm
Encryption in DIDComm is performed by one of two message formats: anoncrypt for anonymous encryption, or authcrypt for authenticated encryption.
Anoncrypt
Anoncrypt performs encryption using a key exchange mechanism that involves the public key of the recipient, but not the one from the sender, an approach that can be used to guarantee the confidentiality and integrity of the data while not revealing nor authenticating the identity of the sender.
This is adequate for scenarios in which the the sender wants to remain
anonymous to the recipient, but it can also be
useful in wrapped message structures (e.g.
anoncrypt(authcrypt(plaintext))) where the authentication is already
provided by another envelope in the structure.
Anoncrypt makes use of the
ECDH-ES (Elliptic Curve Diffie-Hellman Ephemeral Static)
key exchange mechanism.
ECDH-ES is used in key wrapping mode, that is, the shared secret
derived from the Diffie-Hellman exchange is used as a key to an AES
cipher that encrypts (wraps) the actual content encryption key (CEK).
As its name suggests, ECDH-ES is an
ephemeral-static Diffie-Hellman variant,
where the sender can combine the private part of a freshly generated
ephemeral key pair with the public key of the recipient. The encrypted
message, the wrapped CEK, and the public part of the ephemeral key pair
are then sent to the recipient, who can undo the process using the
received public key and its own private key.
No other parties are able to decrypt the message, as one of the two private keys is necessary. Note that the receiver has no identifiable information about the sender, as they used a completely anonymous ephemeral key pair.
One major advantage of this scheme is that it can be used asynchronously. As long as the sender knows the recipient’s public key, no interaction is required between peers. Another advantage is that only one Diffie-Hellman exchange is required.
Authcrypt
Authcrypt is DIDComm’s default envelope and the one recommended by the specification for most scenarios. Like anoncrypt, it ensures confidentiality and integrity, but it also proves the identity of the sender by making use of their static key pair as part of the key agreement protocol.
Authcrypt makes use of the ECDH-1PU (Elliptic Curve Diffie-Hellman One-Pass Unified Model) key exchange. Like anoncrypt, it uses key wrapping mode.
ECDH-1PU is a non-ratified standard closely related to ECDH-ES, that
performs an additional static-static Diffie-Hellman exchange alongside
the ephemeral-static one.
The approach is based on the One-Pass Unified Model scheme as defined
by NIST’s
Recommendation for Pair-Wise Key-Establishment Schemes.
In ECDH-1PU, the secret from the ECDH-ES ephemeral-static exchange
is combined with an additional secret obtained from a static-static
key agreement between the static private keys of sender and recipient.
This scheme is an example of the use of a
combination of Diffie-Hellman exchanges
to benefit from the properties of the set.
Like ECDH-ES, the ECDH-1PU scheme can be used asynchronously. Since
the recipient does not contribute ephemeral material, the sender can
complete the exchange knowing the recipient’s public key alone.
Attacks on DIDComm encryption schemes
After reviewing the cryptographic mechanisms that underpin the two encryption methods provided by DIDComm, we can now informally analyse the security properties they exhibit.
In our analysis we consider an attack model with two possible adversaries:
A passive attacker with global access to network traffic.
An active attacker with global access to network traffic.
Basic security properties
If we consider all cryptographic primitives secure, we can extrapolate the basic security properties aplicable to both passive and active attackers. Anoncrypt provides confidentiality, integrity and message repudiation. Authcrypt provides those, plus message authentication.
| Property | Anoncrypt | Authcrypt |
|---|---|---|
Confidentiality | yes | yes |
Integrity | yes | yes |
Message authentication | no | yes |
Message repudiation | yes | yes |
Forward secrecy
We now set out to analyse the forward secrecy of the two encryption schemes.
Both ECDH-ES and ECDH-1PU are examples of hybrid encryption, where
public-key cryptography is used to establish the keys to be used by a
symmetric cipher.
One of the advantages of hybrid schemes is that the symmetric keys used for content encryption (CEK) can easily be made ephemeral, which improves forward secrecy by isolating the impact of a CEK compromise to the scope of that key.
Compromise of content encryption keys
DIDComm generates new content encryption keys for every message and recipient, and this keys are generated via complete independent key exchange mechanisms, so the compromise of one content encryption key provides no knowledge of past or future keys, providing good forward secrecy for this type of compromise.
Compromise of static keys
We are also interested in the security assurances with regard to the compromise of the private keys of the communicating entities.
In Diffie-Hellman key exchanges forward secrecy is typically achieved by mixing ephemeral material into the exchange. This material can be deleted immediately after the exchange, which entirely avoids a compromise at a later date.
Analysing the building blocks of ECDH-ES and ECDH-1PU, we can see
that in both cases the sender side contributes ephemeral material,
making the protocols forward secret against compromises of the sender’s
private key.
However, none of them includes ephemeral material from the receiver’s side, which exposes all key exchanges (and therefore all message contents) to compromises of the recipient’s private key.
Note that this weakness applies to both passive and active attackers, because by simply collecting traffic, an attacker could gain access to all communication data should a private key ever be compromised.
| Compromised material | Anoncrypt | Authcrypt |
|---|---|---|
Content encryption key | yes | yes |
Sender static key | yes | yes |
Receiver static key | no | no |
Conclusions
Whereas DIDComm provides, in many scenarios, security assurances like confidentiality, integrity, repudiation and optional message authentication, we identify an important weakness in the lack of forward secrecy.
The protocol is forward secret for the compromise of content encryption keys and the static key of the sender, but a compromise of a recipient’s static key can expose the entire communication history of that DID to any passive attacker that gained access to past (encrypted) data.
The problem is mainly caused by the lack of ephemeral cryptographic material on the receiver’s side of key exchange interactions. The chosen cryptographic primitives ensure strong support for asynchronous messaging, but at the cost of a substantial impairment in the forward secrecy of the protocol.
Mitigation
The weakness can be mitigated by rotating the "key agreement keys" declared in DID documents, or by rotating the DID itself.
These rotation mechanisms are largely left to the discretion of DIDComm users/implementers. To ease adoption, it would be advisable to increase the standardisation of these rotations in either DIDComm, implementation profiles, or higher level protocols.
Ratcheting is a key exchange technique that can provide forward secrecy in an asynchronous context. It is used by notable protocols like Signal and Messaging Layer Security (MLS). We may assess the suitability of a ratcheting mechanism for DIDComm in a future article.
Related posts
[WIP] Post-Compromise Security [4] and Key-Compromise Impersonation [5] attacks in DIDComm
References
[1] Diffie, Whitfield, Paul C Van Oorschot, and Michael J Wiener. 1992. “Authentication and Authenticated Key Exchanges.” Designs, Codes and Cryptography 2 (2): 107–25.
[2] Barker, EB, L Chen, A Roginsky, A Vassilev, and R Davis. 2018. “Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography.(National Institute of Standards and Technology, Gaithersburg, Md).” https://doi.org/10.6028/NIST.SP.800-56Ar3.
[3] Green, Matthew D, and Ian Miers. 2015. “Forward Secure Asynchronous Messaging from Puncturable Encryption.” In 2015 Ieee Symposium on Security and Privacy, 305–20. IEEE.
[4] Katriel Cohn-Gordon, Cas Cremers, and Luke Garratt. “On post-compromise se- curity”. In: 2016 IEEE 29th Computer Security Foundations Symposium (CSF). IEEE. 2016, pp. 164–178.
[5] EB Barker et al. Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography.(National Institute of Standards and Tech- nology, Gaithersburg, MD). https://doi.org/10.6028/NIST.SP.800- 56Ar3. [Ac- cessed 27-May-2023]. 2018.