Ephemeral KEM key pair for message protection

[HBrock]

Antonio pointed me again at https://eprint.iacr.org/2017/634.pdf. In figure 3 an authenticated key exchange protocol is described where both parties are authenticated. There P1 generates an ephemeral KEM key pair pk/sk and sends it together with of the encrypted value using P2's public KEM key to P2. In return P2 sends two encrypted values, one using the ephemeral public key pk and one using the public KEM key of P1. Finally all concatenate the three resulting keys using a hash function. Should we extend Section 5.1.3.4 accordingly also adding an ephemeral KEM key?

[HBrock]

Does anyone has an opinion?

[HBrock]

Design team meeting minutes: We submit the version of Section 5.1.3.4 with out the third HPKE and then ask on the LAMPS list if people think that we should add a third HPKE with an ephemeral KEM keypair to the exchange as proposed in figure 3 of the paper.

[HBrock]

Design team meeting minutes: Mike offered to read the paper and provide his opinion on this topic.

[ounsworth]

Some things I note from the paper:

In key exchange constructions using a KEM, it is common to hash the “view” of each participant (i.e., all received and sent messages) into the final key

Should we do that? That would be equivalent to the TLS "transcript". It might solve one of the problems we have with the client and server using different values for HPKE.L.

[ounsworth]

I think this is the relevant sentence for the issue of adding a 3rd (ephemeral) KEM key to the handshake:

Concretely, security of Kyber.AKE in the Canetti– Krawczyk model with weak forward secrecy [27] follows My u directly from the generic security bounds of [22], [37]. (Note that full forward secrecy is not achievable for a two-round authenticated key-exchange protocol [27].)

---

I agree with that analysis. Here is my reasoning:

Consider first a basic 2-key KEM AKE

Static long-term KEM keys: (pk_c, priv_c), (pk_s, priv_s)

Client:
(c1, k1) <- KEM.encaps(pk_s)

Server:
k1 <- KEM.decaps(c1, priv_s)
(c2, k2) <- KEM.encaps(pk_c)

Client: 
k2 <- KEM.decaps(c2, priv_c)

Both:
key := H(k1, k2)

Here if an attacker records the traffic c1, c2 and then is able to learn, even some time later, both parties' private keys priv_s, priv_c, then they can re-run the KEM.decaps()'s and recover both k1, k2, and then the final key.

This is, I believe, already an improvement over the current CMP KeyTrans or KeyAgree message protection where only the server's private key is required to decrypt the exchanged key.

The paper goes a step further by adding an ephemeral key (I believe it should be fine to add it to either party). This means that obtaining key requires knowledge of both long-term private keys, plus the ephemeral private key which is discarded at the end of the handshake. They claim this provides "weak forward secrecy". I think they are implying that "full forward secrecy" would require both parties to have ephemeral keys, which would require an extra 0.5 round-trip to exchange the 4th ciphertext.

---

My opinion is that Static-Static KEM AKE is already improved over KeyTrans or KeyAgree in CMP, but if it does not cost us anything to add an ephemeral key as described in the paper, then why not.

I would feel more confident if everyone thinks about this and agrees with my logic ... including Hans Aschaur, who has an excellent mind for these crypto puzzles.

[HBrock]

The paper goes a step further by adding an ephemeral key (I believe it should be fine to add it to either party). This means that obtaining key requires knowledge of both long-term private keys, plus the ephemeral private key which is discarded at the end of the handshake. They claim this provides "weak forward secrecy". I think they are implying that "full forward secrecy" would require both parties to have ephemeral keys, which would require an extra 0.5 round-trip to exchange the 4th ciphertext.

I am uncertain if an extra 0.5 round-trip would be required as the client could include its ephemeral public KEM key in the first genm messages together with its certificate. The first message exchange is unprotected, but I think a man-in-the-middle could exchange the ephemeral key, but this would also brake the establishment of the shared key later on.

My opinion is that Static-Static KEM AKE is already improved over KeyTrans or KeyAgree in CMP, but if it does not cost us anything to add an ephemeral key as described in the paper, then why not.

As of now authkem dose not include a third ephemeral KEM key as well. But I see your point. What doe the implementer think about this? Is it cumbersome to add a third HPKE with an ephemeral KEM key to the exchange?

[HBrock]

Some things I note from the paper:

In key exchange constructions using a KEM, it is common to hash the “view” of each participant (i.e., all received and sent messages) into the final key

Should we do that? That would be equivalent to the TLS "transcript". It might solve one of the problems we have with the client and server using different values for HPKE.L.

What do the implementers think, would it be much harder to incorporate a hash on the PKIMessage into the HPKE Send/RecieveExportBase than only incorporating transactionID, senderNonce, and recipNonce?

[HBrock]

I will add L to HpkeCiphertext. Therefore I thing it is sufficient using transactionID, senderNonce, and recipNonce for domain separation.

[HBrock]

I propose to go ahead without an additional ephemeral KEM key. This is also in line with draft-ietf-lamps-cms-kemri.

[ounsworth]

This is also in line with draft-ietf-lamps-cms-kemri.

I think their design rationale does not translate to CMP, so this justification is not sufficient. CMS is an offline / non-interactive protocol so they do not have the luxury of doing an online key establishment. CMP is already an online / interactive protocol, so we could add an ephemeral KEM without impacting the message flows.

That said, there is an argument that the KEMs in CMP are used for authentication, not for long-term confidentiality (except for encryption of server-generated keys?)

I suggest we add a Security Consideration like the following:

Security Considerations Forward Secrecy of KEMs In general, mutually-authenticated KEM exchanges ("Authenticated Key Exchanges (AKEs)") embed an ephemeral KEM in order to add forward secrecy protecting against later decryption of the content if the long-term private keys become known. This attack does not apply because CMP uses mutually-authenticated KEM exchanges for the purposes of computing a MAC for authentication, so this usage does not have forward secrecy concerns.

NOTE: this SecCon should mention the option for the client to provide an ephemeral protocol protection key if it wishes to have forward secrecy on the encrypted server-generated key.

[HBrock]

I feel like the forward secrecy is relevant for all keys used for CMP protection of central key generation. Therefore, I propose to extend the scope of this security consideration to protection of centrally generated keys.

[HBrock]

@ounsworth What do you think of this text? `Forward Secrecy for long-term protection

Authenticity of CMP messages relies on signature-based or MAC-based protection. Long-term protection is not required as it is assumed that a PKI management operation using CMP is concluded in a reasonably short time.

When encrypted values are transported as described in Section 5.2.2, long-term security requirements may be relevant. CMP used CMS EnvelopedData for protecting such encrypted values. As CMS is an offline / non-interactive protocol, it does not offer forward secrecy out of the box. As CMP is an interactive protocol, ephemeral keys could be introduced instead of using the existing long-term keys. This would introduce forward secrecy and would offer enhanced long-term security.`

[HBrock]

In the meantime the current draft contains the domain separation using the KemOtherInfo ` KemOtherInfo ::= SEQUENCE { staticString PKIFreeText, transactionID OCTET STRING, senderNonce OCTET STRING, recipNonce OCTET STRING, len INTEGER (1..MAX), ct OCTET STRING }

staticString MUST be "CMP-KEM"

transactionID, senderNonce, and recipNonce MUST be the values from the message previously received containing the ciphertext ct in KemCiphertext

len MUST be the value from that KemCiphertext

ct MUST be the ciphertext from that KemCiphertext`

Do we need all these data as context information for domain separation, specifically ct?

[HBrock]

The second point in this issue was on adding perfect forward secresy using additional ephemeral KEM keys to the exchange. The result of the current discussion is, not do do this, but to add the following ecurity consideration. `Forward Secrecy for long-term protection

Authenticity of CMP messages relies on signature-based or MAC-based protection. Long-term protection is not required as it is assumed that a PKI management operation using CMP is concluded in a reasonably short time.

When encrypted values are transported as described in Section 5.2.2, long-term security requirements may be relevant. CMP used CMS EnvelopedData for protecting such encrypted values. As CMS is an offline / non-interactive protocol, it does not offer forward secrecy out of the box. As CMP is an interactive protocol, ephemeral keys could be introduced instead of using the existing long-term keys. This would introduce forward secrecy and would offer enhanced long-term security.`

Any comments on the tect of this securtiy consideration?

[HBrock]

If we whish to add ephemeral keys, this would require the delivery of this ephemeral kem key together with the KEM certificate. This would require an additional id-it InfoTypeAndValue.

This should be optional, as it is only needed with encrypted delivery of a centrally generated key pair. Do we want to go this extra mile?

[HBrock]

Do we need to add the hash of the whole PKIMessage containing the KemCiphertext as input for KemOtherInfo?

[HBrock]

Meeting 11.05.23 Proposal is to add TLS for the cases where longterm privacy is needed.

[ounsworth]

Meeting 11.05.23 Proposal is to add TLS for the cases where longterm privacy is needed.

To be clear: that is principally cases where private keys are transported over CMP.

[HBrock]

@ounsworth What do you think of this security consideration? @DDvO Any proposals for rephrasing?

Perfect Forward Secrecy

Long-term security typically requires perfect forward secrecy (pfs). PKI management operations are usially completed in a limited time and therefore CMP message protection providing integrity and authenticity does not require long-term security. When encrypted valuest, e.g., centrally generated private keys or revocation passphrases, are transferred, long-term confidentiality and therefore pfs may be important. In contrast, long-term security is may not be required when the indirect method is used to provide a POP {{sect-5.2.8.2}} by delivering the newly issued certificates in encrypted form.

Encrypted values {{sect-5.2.2}} are transferred using CMS EnvelopedData [RFC5652] which does not offer pfs. If long-term security is required, CMP messages SHOULD be transferred using TLS, or a comparable security protocol offering pfs.

[DDvO]

Fixing some typos etc., re-ordering the items for streamlined reading, and taking into consideration that for the time frame of authenticity and integrity, not a whole CMP transaction is relevant but just a single message transfer:

Long-term security typically requires perfect forward secrecy (pfs). When transferring encrypted long-term confidential values such as centrally generated private keys or revocation passphrases, pfs likely is important. Yet it is not needed for CMP message protection providing integrity and authenticity because transfer of PKI management messages is usually completed in very limited time. For the same reason it typically is not required for the indirect method of providing a POP {{sect-5.2.8.2}} delivering the newly issued certificate in encrypted form.

Encrypted values {{sect-5.2.2}} are transferred using CMS EnvelopedData [RFC5652], which does not offer pfs. In cases where long-term security is needed, CMP messages SHOULD be transferred over a mechanism that provides pfs, such as TLS.

[HBrock]

Thank you for rephrasing.

[johngray-dev]

Thanks for the updated text. Looks good. Just one comment: Is there something that will indicate this part is in the context of KEM? When I read it, I was thinking you can get PFS with an ephemeral ECDH (or DH) key in EnvelopedData. So we probably need to make sure it is clear this applies when KEM is used because we don't offer PFS when KEM is used.

[ounsworth]

Looks good.

One comment:

When transferring encrypted long-term confidential values such as centrally generated private keys or revocation passphrases, pfs likely is important.

There is actually more to this story. There is a chicken-and-egg situation here because you are typically encrypting the private keys or revocation keys back to the key holder, so if you have compromised the client sufficiently to obtain the (transport) keys then presumably you already have access to the keys being transported. This further reduces the importance of forward secrecy.

[HBrock]

Is there something that will indicate this part is in the context of KEM? When I read it, I was thinking you can get PFS with an ephemeral ECDH (or DH) key in EnvelopedData.

CMS KeyAgreeRecipientInfo for EnvelopedData uses the static ECDH (or DH) public key from the recipient's certificate identified by the KeyAgreeRecipientIdentifier. See https://datatracker.ietf.org/doc/html/rfc5652#section-6.2.2 The KeyAgreeRecipientIdentifier is a CHOICE with two alternatives specifying the recipient's certificate, and thereby the recipient's public key, that was used by the sender to generate a pairwise key-encryption key. Therefore, I thought that psf is a general topic. @johngray-dev Am I wrong?

[HBrock]

There is actually more to this story. There is a chicken-and-egg situation here because you are typically encrypting the private keys or revocation keys back to the key holder, so if you have compromised the client sufficiently to obtain the (transport) keys then presumably you already have access to the keys being transported. This further reduces the importance of forward secrecy.

This is right. Generally, any centrally generated key or revocation passphrase relys on the security of the keys used to protect its delivery. The point for psf is, that one could cash or sniff the communication and at a later point in time decrypts the encrypted value and so get access to the new keymaterial. Finally it is also a mater of security of the algorithms used to protect the delivery of the encrypted values and the encrypted keys themselves. @ounsworth Do you think we should change something in the text?

[HBrock]

Meeting 15.6.23 Issue can be closed