How Quantum Key Distribution Resists Quantum Computing Threats
Focus
Network Security

How Quantum Key Distribution Resists Quantum Computing Threats

Table of Contents

How Quantum Key Distribution Resists Quantum Computing Threats

QKD resists quantum threats by protect encryption keys using the fundamental laws of nature.
Where Can I Use This?What Do I Need?
  • PAN-OS
  • PAN-OS 12.1 or later.
Conventional key distribution relies on public key ciphers using math; however quantum computing will render most of today's public key encryption strategies unsafe. Quantum key distribution (QKD) solves the problem of key distribution by allowing the exchange of secure cryptographic keys between remote parties over optical fiber optic networks with absolute security, guaranteed by the fundamental laws of physics. QKD requires special purpose equipment and requires dedicated fiber optic connections or physically managed free-space transmitters because QKD is based on physical properties, and its security derives from unique physical layer communications. It can’t be implemented in software or as a service on a network, and can’t be easily integrated into existing network equipment. However, since QKD is hardware-based, it also lacks flexibility for upgrades or security patches.
QKD uses the transmission of many light particles, or photons, over fiber optic cables between parties. Each photon has a random quantum state, and collectively, the photons sent make up a stream of ones and zeros. This stream of ones and zeros are called quantum bits (qubits)—the equivalent of bits in a binary system. When a photon reaches its receiving end, it travels through a beam splitter, which forces the photon to randomly take one path or another into a photon collector. The receiver then responds to the original sender with data regarding the sequence of the photons sent, and the sender then compares that with the emitter, which would have sent each photon.
Photons in the wrong beam collector are discarded; what's left is a specific sequence of bits used as a key to encrypt data. QKD uses a phase of error correction and other postprocessing steps to remove any errors or data leakage. Delayed privacy amplification is another postprocessing step that removes any information an eavesdropper might have gained about the final secret key.
The ETSI GS QKD 014 standard provides a set of standardized API calls that enables a PAN-OS NGFW to communicate with and request symmetric encryption keys from a QKD device. Under the ETSI-014 standard, the PAN-OS firewall acts as the SAE device and makes API calls to the QKD device, called the key management entity (KME). The standard does not specify how to secure the communication and is outside of the ETSI-014 API. But most implementations typically use a TLSv1.3 tunnel to secure the communications between the PAN-OS firewall and the KME. Depending on the QKD vendor’s implementation, you can use TLSv1.3 to secure the key generation process. Certificate authentication can also be used to authenticate one or both parties when setting up the secure TLS tunnel as well.
  1. When the IKEv2 peering process begins, the Initiator (NGFW at Site A) issues an ETSI-014 API call to perform a key request from the Site A QKD device.
  2. The Site A QKD device returns a key identified by a unique key ID to the Initiator.
  3. The QKD device at each site synchronizes with the other and regularly exchanges key and key ID pairs. The QKD devices use a dedicated fiber optic connection to transmit key material using qubits and securely synchronize the key information; the laws of quantum physics protect the key material. Therefore, third parties can’t intercept or view keys between the QKD devices. Any attempts to do so result in a change in the qubit's state and detection of the hijacking attempt.
  4. After receiving the key and key ID pair, the NGFW at Site A places the key ID in the IKEv2 exchange and sent to the Responder (NGFW at Site B). The IKEv2 peering process sends the key ID only; the transmission never includes the key itself.
  5. The Responder receives the key ID sent by the Initiator and makes an ETSI-014 API call to fetch the symmetric key from the Site B QKD device using the key ID.
  6. The Site B QKD device returns the symmetric key to Responder.