Diffie-Hellman (DH), Elliptic Curve Cryptography (ECC), and Elliptic Curve Diffie-Hellman (ECDH) are used extensively in both PKI encryption and IKE key exchange mechanisms (KEMs) to create shared key material to perform data encryption. This technology is at risk of being broken by a cryptographically relevant quantum computer (CRQC) within the next 5-8 years. Although quantum computers do not have sufficient power to break these encryption protocols today, Harvest Now, Decrypt Later attacks are being conducted to gather encrypted data now and decrypt it when a sufficiently powerful CRQC becomes available.
The vulnerability in asymmetric encryption protocols stems from Shor’s Algorithm, which enables factoring large numbers and calculating discrete logarithms to reverse the primes used in key creation. Even though Shor’s algorithm was created in 1994, there was never enough computing power to exercise it to break modern PKI encryption protocols fully. However, with the promise of quantum computers being millions of times more powerful than the most powerful classic supercomputers today, Shor’s algorithm becomes a new tool for breaking encryption.
For symmetric encryption, the Advanced Encryption Standard (AES) cryptographic algorithm is still considered safe from a QC attack when long key lengths are used. For example, replacing weaker AES-128 with AES-256 encryption still provides sufficient security strength against a quantum computer. As most VPN implementations utilize asymmetric key exchange with DH and ECDH, IT professionals must begin reviewing their crypto inventory and develop plans to upgrade their critical VPN infrastructure.
|
Best Practice Tip: If your company is a potential target of harvesting attacks, each day you delay taking action gives the attacker more information to decrypt later. Taking action earlier helps to reduce the window of opportunity for harvesting attacks. |
To start arming customers with quantum-resistant tools, Palo Alto Networks is introducing several new features to enhance the IKEv2 protocol, providing Post-Quantum (PQ) Resistant VPN capabilities. The first feature offered is based on RFC 8784, which uses Post-Quantum Preshared Keys (PPK), and this was released in Cosmos PAN-OS 11.1.
The second PQ VPN feature provided the ability to use the new Post Quantum Cryptography (PQC) algorithms to produce hybrid encryption keys as described in RFC 9242, Intermediate Key Exchange and RFC 9370 Multiple Key Exchanges in IKEv2. This capability was released in PAN-OS 11.2 Quasar.
The next PQ VPN security feature being released in PAN-OS is the support for the ETSI-014 standard, which provides a standard API to obtain high-quality encryption keys from an external Quantum Key Distribution (QKD) device.
QKD is of strategic importance for a high-value traffic environment, such as telcos and financial industries. Telcos are rolling out QKD on metro and inter-DC fiber as a premium, quantum-safe transport that they can sell to high-value customers like finance, government, and critical infrastructure. The financial sector is piloting QKD for ultra-sensitive, low-latency links for scenarios like trading, financial transactions, and inter-DC replication, to avoid Harvest Now, Decrypt Later attacks. QKD provides a physics-guaranteed key exchange that complements PQC, facilitating broader cryptographic migration.
The ETSI-014 standard provides a set of standardized API calls that allow the PAN-OS NGFW to communicate and request symmetric encryption keys from a QKD device, typically located in the exact location as the NGFW used to establish the site-to-site VPN tunnel. Any QKD device or platform that supports the ETSI-014 standard should be interoperable with the PAN-OS firewall.
Under the ETSI-014 standard, the PAN-OS firewall acts as the SAE device and makes API calls to the QKD device, referred to as the KME. The standard doesn’t specify how the communication is secured, and this is outside of the ETSI-014 API. However, most implementations typically use a TLSv1.3 tunnel to ensure communication between the PAN-OS firewall and the KME. Depending on the QKD vendor’s implementation, either classic encryption and/or PQC encryption can be used to secure the key generation process from a quantum attack.
Certificate authentication can also be used to authenticate one or both parties when setting up the secure TLS tunnel. Palo Alto Networks’ QKD implementation will support both PQC-based TLSv1.3 connections and bi-directional certificate authentication.
Looking at the illustration below, we can see how the VPN initiator (Alice) and responder (Bob) utilize the ETSI-014 APIs to retrieve encryption keys from their KME QKD appliances, which are located in the exact locations as their respective PAN-OS firewalls.
With the same symmetric key deployed on both PAN-OS firewalls, the IPSec tunnel is brought up and the data is encrypted using the key from the KME QKD devices.
The advantages of QKD and ETSI-014 include:
The disadvantages of QKD include:
NOW let’s look at the Configurations for ETSI-014 and QKD in PAN-OS
The PAN-OS firewall provides support for QKD and the ETSI-014 standard as follows:
|
Best Practice Tip: To ensure strong security for the QKD communication network, VLANs should be used to segment QKD communications from other network traffic. Access to the QKD network should be limited to specific authorized personnel only. |
With QKD enabled, the PAN-OS firewall will not use RFC 8784 PQ VPN PPK or the PQ VPN Hybrid Key key generation mechanisms to generate the symmetric key. The assigned KME QKD device will provide the encryption key over the secure TLS channel.
Enabling IKEv2 with QKD Encryption Keys
To enable the new PQ VPN QKD feature, reference the configuration screens below to configure the firewall’s QKD profile(s) and IKE Gateway’s PQ QKD settings.
QKD Profile Configuration
The QKD Profile allows you to configure a unique connection profile to each KME QKD device the firewall is to communicate with. In most use cases, an enterprise site-to-site VPN topology should only require one KME QKD device connection per site. PAN-OS firewalls used in a service provider use case may require additional QKD profiles to support different parties sharing the same firewall.
2. Click Add to create a new QKD profile and provide the information requested on the form.
IKE Gateway Configuration
Navigate to the IKE Gateway>Advanced Options, select the PQ QKD tab as shown in the illustration below.
QKD Profile: Select the QKD profile to assign to the IKE gateway in the dropdown list.
SAE ID: (Read Only) The local SAE ID is displayed for confirmation.
Peer SAE ID: Enter the SAE ID assigned to the IKE peer on the other side VPN tunnel.
Key Size (bits): The key size for the key returned from the KME QKD device. The default is 256 bits.
QKD Timeout (Sec): The timeout value to wait for the QKD response
Service Route Configuration
By default, the QKD connection will use the management plane (MP) interface to communicate with the KME. If the KME is on a different network that is connected to the NGFW’s data plane (DP), you will need to configure a service route to redirect the QKD communications from the MP to the DP.
The Service Route Configuration option is found in the Device>Setup>Services menu. Select the QKD service option and configure the source interface and IP address for the service redirection.
Test connectivity to KME host,
Once the configuration is set up, click on Test connectivity to KME host, to verify if the NGFW firewall can reach the KME host from each firewall. Below is an output example you should see if the connection is successful.
The following list of CLI commands can be used to validate the QKD configuration.
To learn more about the cybersecurity impact of quantum computers and how your organization can begin your Quantum Readiness journey now, check out our new CISO’s Guide to Quantum Security video series. Or follow our Quantum Readiness Blog, Quantum documentation, and how Palo Alto Networks is helping customers in their Quantum Secure journey.
