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? |
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.
- 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.
- The Site A QKD device returns a key identified by a unique key ID to the
Initiator.
- 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.
- 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.
- 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.
- The Site B QKD device returns the symmetric key to Responder.