Quantum Proofing your VPN

// under cryptography architecture vpn

The predictable future arrival of Quantum Computers is problematic at the present time, and especially encryption protocols need attention. How can you use your VPN in a Quantum Proof manner?

As explained before, it is not a question if Quantum Computers will be made, but when. Compare it to industrial farming/marketing of meat if you like; we knew that a pandemic would come but not when; humans are surprisingly weak in battling such situations.

But when Quantum Computers arrive, it will be like Corona, and certificate authentication will need to be locked down everywhere. Those who neglected encryption will be beyond help at that time; encryption should already be your concern today, because traffic captured now can be decrypted in the future and is likely to still be a potent source of abuse and hindsight responsibility. Perhaps surprisingly, this includes almost all VPNs. This survey of techniques can help you weigh their risks.

Perfect Forward Secrecy

A valuable technology for deriving encryption keys is Diffie-Hellman (in either its modular-exponentiation or elliptic-curve form) where each party generates a public key and mixes their private key with the other party's public key. The result is a shared secret that both can use, but no interceptor of the intermediate result can derive that same shared secret.

Briefly put, the intermediate is always one step behind the proper parties that each have a private key. This principle even scales up to more than two participants in a key exchange, and the capturing middle man is always just not clever enough to do what the proper parties can do.

The best schemes are those where a private key (with a matching public key) is generated on the fly. This produces a scheme with Perfect Forward Secrecy, that is, no ability to derive one session key from a past (or future) one. This is a great improvement over something like RSA-based encryption, where a fixed public key is used and once its private key is derived all past and future work done with it can be reverse-engineered.

Unfortunately, under Quantum Computers, it will be possible to reverse a Diffie-Hellman public key (in either its modular-exponentiation or elliptic-curve form) and so, any derived secrecy can be reversed.

Craving for Entropy

The obvious solution is to add entropy, that is, a bunch of random bits that are somehow exchanged out-of-band. One way of doing this is Kerberos, and it is precisely that principle that we employed in our TLS-KDH. This happens to work because Kerberos is a key-derivation scheme that starts off as a shared secret between a user and the realm controller or KDC.

Another solution is to not send the public key in plain sight. This is also difficult in general, because you either need to magically know it (which will not work in the first-contact situations for which public-key crypto is most useful) or you need to have some way of encrypting the public key... which is introduces a loop in our reasoning. The only way to do this might be with Kerberos, for reasons of its pre-established encryption keys.

In general, it is difficult to find good sources of entropy, especially when they are to be kept out-of-band. The value of Perfect Forward Secrecy is so great that it is nonetheless used, but the Internet needs sources for entropy sharing. Either that or a Quantum Proof form of Diffie-Hellman, but there are currently no hopes for that.

Protocol Structures

Most encryption protocols use Diffie-Hellman to derive a session key, and use it without mixing in entropy (because there usually is nothing that could add this). This applies to OpenSSH, TLS and IKEv2 -- the driving protocols for Secure Shells and Secure File Transfer, for the most common Internet protocols like web and mail, and for the most common VPN technology IPsec. Oops!

Since Diffie-Hellman alone is not secure enough, its exchanges are often used for authentication. This means that the session key is somehow hashed in with credentials in a non-reversible manner, and it is verified that both derive the same result.

The nice aspect of this structure is that the protocol first encrypts, and only then starts sending identities. The observation of these identities would be possible for a party that actively intervenes in the traffic flow, but then authentication would not work, so this tapping party would be noticed during authentication.

The step that is not taken next, but that might be useful, is to merge the credentials used for authentication with the session key to form a new encryption key for the session. That way, the protocol would:

1. Setup a session key through Diffie-Hellman
2. Authenticate (and detect active intervention by tappers)
3. Update the session key with credential entropy
4. Exchange the actual data

Not much is needed to do this securely. Pretty much anything that cannot be computed back, or that allows isolation of the credentials or old session key would work. For instance, one might derive a session key from a secure hash over

1. If the session key can vary in size, include its size
2. The session key
3. A secure hash of the credential

Another approach could be to use the CRAM-xxx(key,input) method with the credential as the key and the session key as the input to sCRAMble. For xxx same hash can be used in other parts of the protocol.

This could easily be integrated into SASL or GSS-API exchanges, as well as the session key incorporated into each Kerberos ticket and made available to both ends.

Survey of VPN Systems

How do the various VPN systems hold up in practice?

OpenVPN with TLS is a proprietary but popular, somewhat documented protocol that uses TLS to derive a key. Since TLS is not Quantum Proof, this solution is not either.

<!-- TODO: WireGuard has a somewhat difficult to read specification that is founded on Diffie-Hellman, but it makes the choice to not pass the public keys as part of the protocol. As long as no certificate or other standardised format is added, this gives it some protection from Quantum Computers; however, the same Diffie-Hellman key is presumably used for all peers, so to gain access to the public keys between two parties it suffices to be in contact with both. Having said that, in lieu of a PKI the networks are bound to be less flexible and at least have no automated oracle presenting the public keys. The design looks more complicated than required, and it is not clear why the widely implemented PF_KEY infrastructure from IPsec was abandoned instead of just designing a new key exchange mechanism for WireGuard. -->

IPsec with IKEv2 is used in a broad category of VPNs, usually over L2TP or directly over IP or UDP/IP. The offerings include interesting open source variants such as StrongSWAN with Charon as its IKEv2 driver. The standard key exchange mechanism is IKEv2, where session keys are solely based on Diffie-Hellman. When certificates are used, there is no extra entropy (private keys are not known on both ends and are not Quantum Proof anyway). And when a PSK is used, it only serves to authenticate the Diffie-Hellman exchange, rather than used for added entropy as suggested above. This solution is not Quantum Proof but at least the PSK-variant could be fixed as explained above.

IPsec with KINK is a solution that virtually nobody knows, and it only seems to be implemented in Racoon2. KINK leverages Kerberos for key derivation and is in that form Quantum Proof. It has an option for adding Perfect Forward Secrecy, where the public keys are sent in Kerberos-encrypted form and so they are Quantum Proof (and at the same time have Perfect Forward Secrecy).

Since storage of today's encrypted traffic mostly suffices for decryption once we have Quantum Computers, it is best to switch to a VPN that works today to thwart this future doom scenario. It may save you from abusive practices and give you ample time to update any credential that may ever have crossed a wire that was assumed safe on account of a VPN. The solution for today is IPsec with KINK; future extensions to IPsec with IKEv2 are possible, as well as for SASL and GSS-API mechanisms, but it remains to be seen how long that will take to standardise.

Update 2020-09-01: There are a few other ways to make IPsec a Quantum Proof protocol. First, the latest IKEv2 update specifies a "Kerberos Token" as a certificate payload. It does not specify what this means, but it is worth noting that the Kerberos spec uses distinct [APPLICAITON n] tagging for the various chunks of data that make sense in protocols. Basically, there is some room and it could get standardised, but it is not clear yet.

A recent extension well worth mentioning is the mixing of pre-shared keys with the Diffie-Hellman exchange that puts plain IPsec at jeapourdy of Quantum Computers. Pretty much any mix-in of such additional entropy solves matters but the price is high -- there is a need for somehow establishing this key up front. One way of doing this, once again, is to use the session key incorporated into every Kerberos ticket, or possibly the subkey incorporated into the Authenticator ("signature") for a session. Beyond this, it's preconfiguration of shared secrets that are then stored on the machines that serve as IPsec endpoints.

Go Top