Threat Modelling on a Secure File Transfer solution using QKD keys
We want to establish:
Claim: Quantum Key Distribution (QKD) uses quantum properties of light to distribute indeterministic and unpredictable sets of keys between two communicating nodes. This makes the communications encrypted using these keys quantum-safe.
But the devil is in the details, so we do a simple table-top threat modelling exercise to understand the system better. The framework we will use is STRIDE (by Kohnfelder and Garg of Microsoft) as it is well suited for evaluating data security applications.
Architecture
The application we will evaluate is a simple Secure File Transfer Solution shown in Figure 1.
An example usage scenario would be:
- Alice connects to the her File Server to send a file
- Alice's File Server connects to Alice's QKD Node to obtain an AES Key to encrypt the file
- Encrypted file is transmitted to Bob's File Server
- Bob connects to his File Server to view the file.
- Bob's File Server connects to Bob's QKD Node to obtain an AES key to decrypt the file
Assumptions
We assume the following:
- Communication between the File Servers and QKD Nodes is using mutual-TLS v1.3.
- Proper certificate and key handling have been done to create the respective X.509 certificates and keys and install them securely in the respective devices.
- 256-bit keys used for AES encryption / decryption are quantum-safe. We should not accept anything less.
- The file encryption scheme is at least IND-CPA secure (e.g., AES-CBC with random IV, or AES-CTR with random nonce)
Threat Modelling Exercise
We focus the modelling on the communications between the File Servers with the QKD Nodes as shown in yellow (Figure 1). We also include a "Next steps" column for follow-up action needed.
| No | Threat | Attack | Outcome | Remarks | Next steps |
| 1 | Spoofing the QKD Node | Attacker creates a fake QKD Node to respond to Alice's or Bob's request for an AES key | Mutual TLS session setup will fail since the attacker will have to also steal the TLS private key | Reliant on classical cryptography for authentication | This needs to be upgraded to post-quantum TLS in the future |
| 2 | Spoofing the QKD Node | Attacker creates a man-in-the-middle device between the 2 QKD Nodes to relay quantum communications and key negotiations | Attacker can potentially know the AES keys that are generated by the QKD Nodes | More in-depth study is needed to understand how the QKD Nodes can detect and defend against man-in-the-middle attacks | Ask the QKD vendor for more information |
| 3 | Spoofing the File Server | Attacker creates a fake File Server to send requests to the QKD Nodes | Mutual TLS session setup will fail since the attacker will have to also steal the TLS private key | Reliant on classical cryptography for authentication | This needs to be upgraded to post-quantum TLS in the future |
| 4 | Tampering the QKD Node response for AES key | Attacker modifies the response from the QKD Node to the File Server | TLS communication will detect integrity failures in the communication | Reliant on classical cryptography for authentication | This needs to be upgraded to post-quantum TLS in the future |
| 5 | Tampering the QKD Node key negotiations | Attacker modifies the TCP/IP key negotiation packets | Assuming the QKD Nodes are using BB84, Bob's QKD Node may arrive at a different key compared to Alice's QKD Node | Confidentiality is not affected, but files sent by Alice may not be decrypted by Bob | Can consider using TLS to improve the integrity of the communication |
| 6 | Receiver Repudiation | Attacker sends some random file to Bob, claiming it is from Alice | Bob is unable to decrypt the file. Bob is unable to prove that it is / is not from Alice | Non-repudiation is not a security primitive supported by QKD | - |
| 7 | Sender Repudiation | Alice sends an encrypted file which Bob can decrypt. Alice refuses to admit she sent the file | Bob knows that the file came from Alice. However, Bob cannot prove to a 3rd party that the file came from Alice | Non-repudiation is not a security primitive supported by QKD | - |
| 8 | Information (Key) disclosed at QKD node | Attacker installs a malware in the QKD Node to sniff for keys before it is sent to the File Server | Attacker can potentially know the AES keys that are generated by the QKD Nodes | More in-depth study is needed to understand how the QKD Nodes can detect and defend against internal malware | Ask the QKD vendor for more information |
| 9 | Information (Key) disclosed in Quantum communication link | Attacker selectively samples some of the quantum photonic communications to guess the key | Assuming the QKD Nodes are using BB84, the attacker can recover up to 25% of the AES key without being detected | File Servers should not directly use the AES Key returned from the QKD Node for encryption | The AES Key should be further derived with other quantum-safe secret material to ensure full key strength of 256 bits |
| 10 | Information (Key) disclosed in response from QKD Node | Attacker sniffs the network between the File Server and QKD Node to collect the TLS traffic, and use a quantum computer in the future to decrypt | The AES keys used for File encryption/decryption are susceptible to harvest-now-decrypt-later (HNDL) attacks | The communication between the File Servers and QKD Nodes require post-quantum TLS | The AES key should be further derived with other quantum-safe secret material to prevent the HNDL attack |
| 11 | Denial of Service (DOS) | Attacker breaks the quantum communication link between the QKD Nodes | No more AES keys can be returned by the QKD Nodes | QKD setups are susceptible to DOS attacks | Alternative quantum-safe sources of keys must be made available to prevent DOS attacks |
| 12 | Elevation of Privilege | Attacker obtains the admin credentials to login to QKD Node | Attacker can potentially look at the logs and gain access to AES keys | More in-depth study on the QKD Node is required | Proper access control must be put in place for the QKD Nodes |
Clearly there are a lot more threat scenarios that can be examined, but you get the idea.
Conclusion
Our simple (and incomplete) threat modelling exercise has yielded 12 scenarios, we have found that:
- Scenario 5 (Tampering of quantum communications) shows that confidentiality is not compromised due to the properties of quantum communications. Using TLS between QKD nodes can improve the integrity of the communications.
- Scenarios 1, 3 and 4 rely on classical TLS authentication which needs to be upgraded in the near future.
- Scenarios 6 and 7 (Non repudiation) are out of scope for QKD implementations.
- Scenarios 2, 8 and 12 are implementation-specific topics for QKD Nodes, and need to be studied in more detail to ascertain its security.
- Scenarios 9, 10 and 11 (Disclosure of keys, Denial of Service) highlight vulnerable areas which must be fixed/mitigated before such a system is used for actual production.
Ask your QKD vendor how it mitigates against (i) Man-in-the-middle attacks; (ii) Malware in the QKD Node; (iii) Harvest-now-decrypt-later attacks on API connections; (iv) Sniffing of partial keys by eavesdroppers; (v) Service unavailability due to connection disruptions; (vi) Unauthorized logins to the QKD Node.
At pQCee, we have implemented QKDLite, a key management middleware which implements post-quantum TLS, integrates with FIPS140-certified HSMs, includes built-in quantum-safe key derivation, with end-to-end encryption to provide the necessary security constructs to ensure a quantum-safe and secure implementation of Secure File Transfer.
Our QKDLite for Secure File Transfer demo is available at https://qkdlite.pqcee.com
Contact us at info@pqcee.com for more information
Author
Tan Teik Guan
Teik Guan is CEO of pQCee.com. He works in the niche area of cryptographic security design and integration, having implemented numerous successful projects for banks, government agencies and enterprises. He holds a BSc and MSc from NUS and a PhD from SUTD.
Contributors