Making QKD-VPN setups resilient against disruptions

With the growing awareness of the threat of Quantum attacks, more organizations are considering to upgrade their IPSEC VPNs to include a Postquantum Preshared Key (PPK) to ensure that the IPSEC-encrypted traffic is secure against harvest-now-decrypt-later attacks. This PPK functionality (standardized as RFC8784) is already supported by many existing VPN providers such as Fortinet, Palo Alto, Juniper, Cisco, etc. 

We show how such setups can be made resilient against quantum communication link disruptions using a combination of QKDLite and hardware security modules (HSMs).

IPSEC VPN with RFC8784

To complete the post-quantum setup, the VPN gateways at each side needs to be connected to their respective QKD node to retrieve the identical PPK during the connection establishment as shown in Figure 1.

Connecting to the QKD Node is typically via REST APIs based on ETSI QKD 014 or CISCO SKIP. With the additional PPK used during session establishment, an attacker harvesting the IPSEC-encrypted traffic will not be able to use a quantum computer to easily decrypt the information. 

But what happens when the quantum communication link is disrupted? Since QKD Nodes rely on a dedicated link (typically dark fiber) to negotiate the PPK, any disruption (shown in Figure 2) will result in the unavailability of PPKs to be provided to the VPN gateways. 

This may not be acceptable to critical infrastructure operated by financial, utilities,  and healthcare enterprises. The problem is exacerbated by the fact that quantum communication links are difficult to restore which may lead to long downtimes and service unavailability.  

The current method of restoring the VPN session is to re-configure the VPN gateway to bypass the need for the PPK, and accept the risk to expose the session to harvest-now-decrypt-later attacks. Is this an acceptable compromise? Is there a better way to provide resilience to such a setup without the risk?

Add in QKDLite with HSM for resilience

We do so by inserting QKDLite, a QKD key management middleware by pQCee with Thales' Luna HSM, a FIPS-140 Level 3 certified hardware security module, between the VPN gateway and the QKD node. This is done at both sides of the VPN gateway as shown in Figure 3.

We next configured QKDLite to maintain a pool of PPKs in the HSMs. Since the HSMs are tamper-proof, the PPKs remain secure and protected within the HSMs. Under normal operations, the VPN gateways will connect to the QKDLite nodes to obtain the PPKs, while QKDLite continues to replenish the consumed PPKs from the actual QKD Nodes. The keys used in this setup retain the properties of forward-secrecy. 

If the quantum communications link is disrupted (see Figure 4), QKDLite continues to be able to serve PPKs to the VPN gateways without disruption.

QKDLite will continue to serve PPKs from the HSM until the pool of PPKs is depleted. Since the size of the PPK pool is configurable, and both QKDLite and HSM can be setup in high-availability modes, this makes for a more resilient setup as compared to Figure 1.

Testing the setup

We set up a live test based on Figure 3 using the following equipment:

• Fortigate VPN
• QKDLite
• Thales Luna HSM
• Toshiba QKD 

QKDLite configuration parameters used are

• Type of Keys: 32-byte keys
• Size of PPK key pool: 50 keys
• Refresh rate: every 10 minutes

Figure 5 shows the screenshot of the VPN connectivity with PPK 

We thank the team at Pacific Tech for their time and resources and Toshiba for making available their test environment for this live test.