As we have discussed in the previous post, Post-Quantum Pre-shared Keys provide a way to mitigate the current “Harvest Now, Decrypt Later” threat. However one question remains: how can we exchange these PPK between the different peers? Are we back 25 years in the past when we had to call our peer and spell the key over the phone? Charlie-India-Sierra-Charlie-Oscar-1-2-3?
Luckily not! Unfortunately though, Diffie-Hellman and asymmetric cryptography in general are exactly what a Cryptographically Relevant Quantum Computer (CRQC) would break, so they can’t help here either. People have been investigating other possibilities.
Quantum Key Distribution to the rescue #
One of them is Quantum Key Distribution (QKD). This is a field that can become pretty complex but the bottom line is that it relies on quantum properties to exchange a common secret, usually over an optical fiber (satellite may be another, less common, option). The details of how QKD achieves this are fascinating but beyond the scope of this post… what matters here is the output: both sides end up with the same secret key.
Ok so each side has now established a common secret thanks to their “QKD box”. How can we use that key as a PPK for our VPN?
Enter SKIP #
This is exactly where the “Secure Key Integration Protocol” or SKIP comes into play. SKIP is the interface between the “QKD box” (the key provider) and the “VPN box” (the encryptor).
The protocol was introduced by Cisco and everything is properly explained in an RFC draft: https://datatracker.ietf.org/doc/draft-cisco-skip/ The standardisation process is still ongoing… it morphed into https://datatracker.ietf.org/doc/draft-singh-skip/00/ in April 2026, moving from a Cisco-authored draft to a broader IETF community effort.
Location A Location B
+------------------+ +------------------+
| +---------+ | IKEv2 | +---------+ |
| |Encryptor|====================|Encryptor| |
| +---------+ | | +---------+ |
| | | | | |
| SKIP | | | SKIP | |
| | | | | |
| +------------+ | | +------------+ |
| |Key Provider|= = = = = = = = =|Key Provider| |
| +------------+ | Arbitrary | +------------+ |
+------------------+ +------------------+There is no rocket science in there, the protocol is a simple REST API… think web requests over HTTP, the same technology your browser uses to load a page. Each key provided by the key provider is assigned a label, the keyID. If Alice wants to establish a VPN with Bob, she starts by requesting a key from her local key provider; she receives a key and a keyID, KeyA. Through IKEv2, she lets Bob know she wants to use a key corresponding to KeyA. Bob then queries his own key provider, asking for the key identified as KeyA. His key provider is connected to Alice’s key provider through that “arbitrary channel” and knows which key matches KeyA. It answers Bob with the related key. Alice and Bob have now established a shared secret they can use as a PPK.
The chicken and egg problem #
A detail worth noting is that we now have an extra link to protect, the one between the encryptor and the key provider, since the protocol is based on HTTP. TLS is a natural choice… but isn’t TLS vulnerable to a CRQC?!
Well, not really. The link between Alice and Bob is insecure by default (think Internet), while we can assume the link between the key provider and the encryptor is local and more controlled.
In some cases, that link is not even physical (as in a wire), it can live within the router itself. This is the kind of implementation provided by PhioTX, a product from QuantumXC, where the key provider is installed in a virtual container running directly on the router.
Anyway, the options to protect that connection are TLS 1.2 or TLS 1.3. You could use post-quantum crypto (such as ML-KEM) to encrypt the link, but again that feels a bit like a chicken and egg issue! There is however an alternative I had overlooked: TLS with Pre-Shared Keys (which, conveniently, doesn’t rely on asymmetric crypto at all).
Does SKIP have a future now that PQC is here? #
For quite some time, this kind of architecture was the main option to mitigate the HNDL threat. Now that PQC is finally being standardised, we could wonder if SKIP has any future…
It is still required for QKD! I’ll write more about that later but, even if the US doesn’t seem to bet heavily on that technology, other parts of the world still consider it a valuable option.
Another aspect worth discussing is that the arbitrary channel between the two key providers could be anything. We have mostly assumed QKD so far, but it could very well be based on PQC. This is actually what PhioTX is doing, and their reasoning comes down to crypto agility.
Why would you even consider that? It sounds rather convoluted: if PQC is available, why not directly use it to encrypt the channel between Alice and Bob?
Well, if tomorrow we discover that an algorithm we thought was quantum-safe has a serious flaw, it might be easier to swap to another algorithm in a third-party device than in the encryptor itself… even more so if that third-party solution is based on open-source.
SKIP vs ETSI-14 #
There is one more player in this space we haven’t mentioned yet: ETSI (the European Standards Institute). While Cisco was implementing SKIP, ETSI standardised a very similar protocol, ETSI-14, or more precisely ETSI GS QKD 014. The name already tells us it was introduced specifically for QKD, even if in theory nothing prevents it from being used with something else.
The issue is that we now have two very similar protocols: Cisco sticks to SKIP while its competitors would rather adopt ETSI-14. That means if you are a QKD vendor, you should ideally support both…
In the next post, I’m going to share the details of a lab setup based on SKIP.