Real-World Hybrid Keying

[John Mattsson]

Hi,

 

I think there is more to discuss about hybrid keying, in particular PSKs, re-negotiation, chaining sessions, and minimizing damage when a breach occurs. In the real-world, there are typically many sessions between the same nodes over a long period of time. The more vulnerabilities I see in the real-world, the more I believe in conservative layered defense-in-depth approaches to minimize the probability of breach and to minimize the damage when a breach occurs. For most consumer and industry applications, and ignoring users shooting themselves in the foot, the biggest threats are implementation errors and side-channels, especially in new implementations. Customer and industry products often rely on self-certification, which too often turns out to be incorrect. National security systems are a completely different thing, with long and very detailed analysis of every single detail of the implementation. My view is that in customer and industry products, the risk of a weak KEM implementation is much bigger than the risk that a (quite simple) KEM combiner introduces vulnerabilities.

 

My general view:

 

1. Use a PQC KEM.
2. ECDHE is inexpensive and already supported. Use it.
3. If it is possible to use a PSK, do so. The PSK may be external to the protocol or come from a previous session.
4. For sessions, continuously re-negotiate the key at frequent intervals.

 

Martin Ekerå (Swedish NCSA) has a good overview of keying in chapter 4 of [1]. Below is a figure (CC BY) of my high-level view on hybrid key exchange with several sessions, heavily inspired by Stephan Ehlen’s (BSI) figure from PKIC [2].

 

 

A lot of the discussions I have seen, focus on a limited part like ECC+PSK, PQC+ECC, or session chaining where the first session in unauthenticated, but does not discuss the typical real-world scenario of many sessions between two nodes over a long period of time and where the first session is authenticated. Often the sessions are over different networks and in different geographical locations.

 

- Continuously re-negotiating the key at frequent intervals implies that an adversary breaching one session key, cannot derive future keys.

 

- Chaining sessions implies that even if the asymmetric crypto is breached, an attacker that missed to record a single re-negotiation cannot breach any future keys.

 

I like RFC 8784 and RFC 8773, which remove the restrictions in IKEv2 and TLS 1.3 that you cannot do hybrid keying with an external PSK when you authenticate with certificates. I don't see any reason for these restrictions.

I was happy to see the following general recommendations in [1] written by an author from Swedish NCSA:

 

"to always use asymmetric keying whenever feasible to achieve forward secrecy"

"The asymmetrically distributed key can be refreshed at very frequent intervals"

 

I have in the past referenced R12 and R13 in ANSSIs document [3]. These recommendations are great but are artificially restricted to IPsec. I hope more governments will provide general recommendations on keying, especially concerning frequent rekeying with ephemeral keys. Good government recommendations are very important, when arguing for strong security in industry SDOs.

 

Cheers,

John Preuß Mattsson

 

[1] Martin Ekerå (Swedish NCSA), ”On factoring integers, and computing discrete logarithms and orders, quantumly”

https://diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf

 

[2] Stephan Ehlen (BSI), ”Post-Quantum Policy & Roadmap of the BSI”

https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_stephan-ehlen_bsi_post-quantum-policy-and-roadmap-of-the-bsi.pdf

 

[3] ANSSI, ”Recommendations for securing networks with IPsec”

https://cyber.gouv.fr/sites/default/files/2015/09/NT_IPsec_EN.pdf