In the world of cybersecurity, timing is indeed everything. While quantum computers capable of breaking todays encryption schemes may still be years away, the threat they pose is already here. That’s because data does not vanish after it has been transmitted, it is often stored for years. Nation-states and threat actors are already collecting encrypted traffic with the intent to decrypt it once quantum technology catches up. This strategy is known as “harvest now, decrypt later”, which turns todays secure communications into an open book tomorrow.

This looming vulnerability puts sensitive information at long-term risk. That is why the transition to post-quantum encryption is not about a theoretical exercise for the future. It is an urgent and proactive measure that needs to begin now in order to safeguard the confidentiality of data across modern networks.

Quantum computing threatens current cryptography like RSA, diffie-hellman (DH) and elliptic-curve diffie-hellman (ECDH) since these encryption schemes rely on math problems – such as factoring large numbers or solving discrete logarithms. These problems take exponential time to crack for a traditional computer, but with quantum computers using qubits instead or regular bits, they can try many possible answers at once. With Shor’s algorithm, quantum computers can quickly spot patterns in numbers – which in theory makes it possible to crack these encryptions in hours or potentially minutes. This is why we need to convert to quantum-safe encryption, which is already today supported in some network operating systems, as in Cisco IOS-XE. Let’s dive in to how we can accomplish this when setting up a VPN connection.

Cisco IOS-XE

To harden IKEv2/IPsec VPNs against future quantum threats, Cisco IOS-XE supports RFC 8784, allowing the integration of post-quantum preshared keys (also known as PPK). This setup enhances security by mixing a quantum-safe PPK into the IKEv2 key derivation process. See the example below.

There are two possible ways of generating a PPK:

1. Manually providing the configuration with the PPKs on responder and initiator
2. Using the Cisco Secure Key Integration Protocol (SKIP) for dynamic PPK provisioning with an external key source

Configuration

To summarize this blog post I thought it would be fun to show how we can accomplish this in a lab. The lab will be built on the following topology.

On both R1 and R2, let’s define the PPK manually

! R1 config
crypto ikev2 keyring PPK-KEYRING
 peer 1
  address 172.22.0.2 255.255.255.255
  ppk manual id ppk_id key ROUTERALLE

! R2 config
crypto ikev2 keyring ppk-keyring
 peer 1
  address 172.22.0.1 255.255.255.255
  ppk manual id ppk_id key ROUTERALLE

After this, we can normally use the keyring in our profile.

! R1 config
crypto ikev2 profile IKEv2-PROF
 match identity remote address 172.22.0.2 255.255.255.255
 authentication remote pre-shared key ROUTERALLE
 authentication local pre-shared key ROUTERALLE
 keyring ppk PPK-KEYRING

! R2 config
crypto ikev2 profile IKEv2-PROF
 match identity remote address 172.22.0.1 255.255.255.255
 authentication remote pre-shared key ROUTERALLE
 authentication local pre-shared key ROUTERALLE
 keyring ppk PPK-KEYRING

Don’t forget about a transform-set before making the IPsec profile.

crypto ipsec transform-set TS-AES256 esp-gcm 256
 mode tunnel

And then bind this information to an IPsec profile

crypto ipsec profile IPSEC-PPK-PROF
 set transform-set TS-AES256
 set ikev2-profile IKEv2-PROF

Now we can arrange the tunnel interface in our two routers.

! R1 config
interface Tunnel10
 ip address 10.1.1.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 172.22.0.2
 tunnel protection ipsec profile IPSEC-PPK-PROF

! R2 config
interface Tunnel10
 ip address 10.1.1.2 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel destination 172.22.0.1
 tunnel protection ipsec profile IPSEC-PPK-PROF

Let’s verify the state of our tunnel on one of the routers by issuing a show command for viewing the security association.

R2#show crypto ikev2 sa detailed 
 IPv4 Crypto IKEv2  SA 

Tunnel-id Local                 Remote                fvrf/ivrf            Status 
1         172.22.0.2/500        172.22.0.1/500        none/none            READY  
      Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:19, Auth sign: PSK, Auth verify: PSK, QR
<-- omitted output -->
      Status Description: Negotiation done
      Local id: 172.22.0.2
      Remote id: 172.22.0.1
<-- omitted output -->
      Initiator of SA : Yes
      Quantum-safe Encryption using Manual PPK
      PEER TYPE: IOS-XE
<-- omitted output -->

We can now see that the encryption used is quantum-safe by the line “Quantum-safe Encryption using Manual PPK”.