Quantum-Safe Encryption Using Postquantum Preshared Keys
| Feature Name | Release Information | Description |
|---|---|---|
|
SKIP Protocol Support for Quantum Safe IKEv2 Encryption |
Cisco IOS XR Release 24.1.1 |
Traditionally, the IKEv2 encryption was vulnerable to quantum attacks. Now, IKEv2 encryption complies with RFC 8784, which specifies using postquantum preshared keys (PPK) to make it resilient to quantum attacks. You can generate both manual and dynamic PPKs. The dynamic PPKs are generated using the Cisco Secure Key Integration Protocol (SKIP). The IKEv2 encryption is configured through CLI or by the Cisco-IOS-XR-um-ikev2-cfg Yang model. CLI:
|
Quantum computers have raised concerns about the security of cryptographic algorithms used extensively today. AN example of a cryptosystem that could be vulnerable to quantum computers is the Internet Key Exchange Protocol Version 2 (IKEv2). Any VPN communications could be decrypted in the future when a quantum computer becomes available. To address this issue, IKEv2 can be extended that uses preshared keys making it resistant to quantum computers.
Postquantum Preshared Keys
Session keys that are derived from preshared keys are safe to quantum attacks if the preshared keys are endowed with sufficient entropy. Therefore, the resulting system is deemed secure against classical attackers of today, and against future quantum attackers.
RFC 8784 (Mixing Preshared Keys in IKEv2 for Postquantum Security) outlines an enhancement to the IKEv2 protocol that renders it quantum-computer-resistant through the incorporation of preshared keys, referred to as PPKs. This RFC establishes the specifications for enabling PPK capability negotiation, PPK ID transmission, the integration of PPK as a supplementary factor in session key derivation, and the potential fallback to sessions not dependent on PPKs.
Dynamic Postquantum Preshared Keys and SKIP
The Cisco Secure Key Integration Protocol (SKIP) is an HTTPS-driven protocol designed to enable encryption devices like routers to import PPKs from an external key source. These externally imported PPKs, referred to as dynamic PPKs, provide advantages such as automated provisioning and updates, and improved PPK entropy. Encryption devices must have the SKIP client and the external key source must have the SKIP server.
To be SKIP-compliant, an external key source must follow the Cisco SKIP protocol and use an out-of-band synchronization mechanism. This ensures that the same PPK is provided to both the initiator and responder encryption devices. The external key source can be in the form of a Quantum Key Distribution (QKD) device, software, or cloud-based key source or service.
The external key source must meet the following expectations to be SKIP-compliant:
-
Must implement the SKIP protocol or API, as specified in the Cisco SKIP specification.
-
Must provide the same PPK to the encryption device pair—initiator and responder—using an out-of-band synchronization mechanism.
 Note |
Key source vendors, such as QKD vendors, must contact their Cisco representative to implement the Cisco SKIP protocol. |
The following figure shows quantum-safe IKEv2 and OTNsec session keys using dynamic PPK.
The IKEv2 initiator and responder are connected to their respective local key sources and are configured with the SKIP client that specifies the IP address and port of the key source. The PPK sources are also configured with the SKIP parameters, which include the local key source identity and a list of identities of the peer key sources.
The high-level operation of Cisco SKIP protocol is as follows:
-
The IKEv2 initiator places a request for a PPK from its key source. The key source replies with a PPK and the corresponding PPK ID.
-
The initiator-side key source synchronizes the PPK to the responder-side key source using an out-of-band mechanism that is specific to the type of key source. The IKEv2 initiator communicates the PPK ID to the IKEv2 responder over IKEv2 using the RFC 8784 extensions.
-
The IKEv2 responder requests from its key source, the PPK corresponding to the PPK ID received from the IKEv2 initiator. The key source replies with the PPK corresponding to the PPK ID.
-
The IKEv2 initiator and responder mix the PPK in the key derivation, as specified in RFC 8784. The resulting IKEv2 and OTNsec session keys are quantum-safe.
Configure Dynamic PPK in IKEv2
Cisco Secure Key Import Protocol (SKIP) is a protocol that allows an encryption device to securely import keys from an external PPK source. The externally imported PPKs are known as dynamic PPKs. To use SKIP, the encryption devices must implement the SKIP client, and the PPK source must implement the SKIP server. SKIP allows the use of QKD devices or Cisco Session Key Service (SKS) servers as the source of PPKs.
Configuring Dynamic PPK using SKS SKIP
Use the following commands to configure the dynamic PPK for one or more peers or groups of peers, in the IKEv2 keyring.
configure terminal
keyring dynamic
peer name
ppk dynamic sks-profile-name [required]
pre-shared-key key-string
address {ipv4-address mask}
ikev2 profile name
match identity remote address {ipv4-address mask}
keyring ppk keyring-name
keyring keyring-name
sks profile profile-name type remote
kme server ipv4 ip-address port port-number
exit
exit
Example :
RP/0/RP0/CPU0:ios#configure terminal
RP/0/RP0/CPU0:ios(config)#keyring dynamic
RP/0/RP0/CPU0:ios(config-ikev2-keyring)#peer peer1
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#ppk dynamic qkd required
RP/0/RP0/CPU0:ios(config-ikev2-keyring)#pre-shared-key cisco123!cisco123
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#address 10.0.0.1 255.0.0.0
RP/0/1/CPU0:ios(config)#ikev2 profile test
RP/0/1/CPU0:ios(config-ikev2-profile-test)#keyring dynamic
RP/0/1/CPU0:ios(config-ikev2-profile-test)#keyring ppk dynamic
RP/0/1/CPU0:ios(config-ikev2-profile-name)#match address 10.0.0.1 255.255.255.0
RP/0/1/CPU0:ios(config)#sks profile qkd type remote
RP/0/1/CPU0:ios(config-sks-profile)#kme server ipv4 192.0.2.34 port 10001
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#exit
RP/0/RP0/CPU0:ios(config)#exitManual Postquantum Preshared Keys
You can also use another easier way known as manual PPKs. When using the manual PPKs, you can provision the same PPKs on both the IKEv2 and OTNsec initiator and responder by manually configuring the PPKs on both sides.
Ensure that a manual PPK is of sufficient size, entropy, and is frequently rotated by the administrator.
In the following figure, you can see the session keys of quantum-safe IKEv2 and OTNsec, which are obtained through a manual PPK.
Configure Manual PPK in IKEv2
Use the following commands to configure the manual PPK for one or more peers or groups of peers, in the IKEv2 keyring.
configure terminal
keyring keyring-name
peer name
ppk manual id ppk-id key [ clear | password ] password [required]
pre-shared-key key-string
address {ipv4-address mask }
ikev2 profile name
match identity remote address {ipv4-address mask}
keyring ppk keyring-name
keyring keyring-name
exit
exit
Example :
RP/0/RP0/CPU0:ios#configure terminal
RP/0/RP0/CPU0:ios(config)#keyring manual
RP/0/RP0/CPU0:ios(config-ikev2-keyring)#peer peer1
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#ppk manual id cisco123 key password 060506324F41584B56 required
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#pre-shared-key cisco123cisco123
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#address 10.0.0.1 255.0.0.0
RP/0/RP0/CPU0:ios(config-ikev2-keyring-peer)#exit
RP/0/RP0/CPU0:ios(config)#exit
RP/0/1/CPU0:ios(config)#ikev2 profile test
RP/0/1/CPU0:ios(config-ikev2-profile-test)#keyring manual
RP/0/1/CPU0:ios(config-ikev2-profile-test)#keyring ppk manual
RP/0/1/CPU0:ios(config-ikev2-profile-test)#match address 10.0.0.1 255.255.255.0
RP/0/RP0/CPU0:ios(config-ikev2-profile-test)#exit
RP/0/RP0/CPU0:ios(config)#exitNote |
When using the |
Feedback