SlideShare a Scribd company logo

Quantum Safety in Certified Cryptographic Modules

•Download as PPTX, PDF•
•
OnBoard Security, Inc. - a Qualcomm Company
OnBoard Security, Inc. - a Qualcomm Company

This document discusses using quantum-safe cryptography to protect against future quantum computers. It proposes a "hybrid" approach where a FIPS-approved classical algorithm is used for conformance while a quantum-safe algorithm is also used to provide long-term security. Specifically, it examines using the "OtherInfo" field when deriving keys to include a quantum-safe symmetric key as part of the key derivation process. This would allow quantum-safe encryption of data even when using a FIPS-approved scheme for key establishment and compliance. However, it is unclear if including symmetric keys in "OtherInfo" is permitted by standards.

1 of 36
Quantum Safety In Certified Cryptographic Modules William Whyte, Lee Wilson
What’s Causing All the Fuss? Shor’s Algorithm (From Quantum Computing for Computer Scientists by Noson Yanofsky and Mirco Mannucci) Input: A positive integer N with n = [log2 N]. Output: A factor p of N if it exists. 1. Use a polynomial algorithm to determine if N is prime or a power of prime. If it is a prime, declare that it is and exit. If it is a power of a prime number, declare that it is and exit. 2. Randomly choose an integer a such that 1 < a < N. Perform Euclid’s algorithm to determine GCD( a, N). If the GCD is not 1, then return it and exit. 3. Use the quantum circuit below to find a period r. 4. If r is odd or if ar ≡ − 1 Mod N, then return to #2 and choose another a. 5. Use Euclid’s algorithm to calculate GCD((𝑎 𝑟/2 +1),N) and GCD((𝑎 𝑟/2 −1),N) . Return at least one of the nontrivial solutions. Note: These gate symbols denote measuring the qubit. Note: The QFT is a “Quantum Fourier Transform” gate.
Insights from “Cybersecurity in an era with quantum computers: will we be ready?” – 5 Main Points The referenced paper was written by Michele Mosca (University of Waterloo, Chairman of the Institute for Quantum Computing, Canada Research Chair in Quantum Computation) 1.The transition to quantum-safety will take lots of time and energy. • “There is no quick fix and we cannot quickly make up lost time.” 2.Quantum computer will arrive before we’re ready. 3.A wake up call is needed… The main challenges aren’t technical. • “Despite the many technical and scientific challenges to deploying quantum-safe cryptography, the main challenges in my opinion are the business and policy decisions that would drive the adoption of quantum-safe cryptography….” 4.Quantum computers will be of immense value to mankind, but the impact of quantum computers on cybersecurity will be catastrophic. • “Harnessing the power of quantum mechanics in large-scale quantum computers will allow us to solve many valuable problems for humanity, but we must first take the catastrophic impact of breaking cybersecurity off the table by developing and deploying a suite of quantum-safe cryptographic tools before quantum computers arrive.” 5.Quantum-safe cryptography is not an option in the new age of quantum computing. • “Quantum-safe cryptography is a necessary part of cybersecurity in an era with quantum computers…”
Microsoft Quantum Computing Predictions
From “A Two-Qubit Logic Gate in Silicon”, Nature Magazine, 10/15/15 “Although these silicon qubits represent the smallest scalable two-qubit system reported so far, the complete fabrication process is compatible with standard CMOS (complementary metal – oxide–semiconductor) technology, and is also consistent with current transistor feature sizes, offering the prospect of realizing a large-scale quantum processor using the same silicon manufacturing technologies that have enabled the current information age.” UNSW Can Now Make Qubits Using Standard CMOS Fabrication Technology….
Projected Probability of General Purpose Quantum Computers Arriving By Year Critical infrastructure and industries with fiduciary responsibilities MUST be re-tooled when the threat window opens! The green graph is based on data from the IQC (Institute for Quantum Computing) provided earlier in 2015. The red graph is based on data after significant breakthroughs were achieved (Microsoft, UNSW, IBM, Google, etc.) since the beginning of 2H15.
There are 2 Very Important Threats… The 1st Is Already Here… We Have a FIPS 140-2 Compliant Solution Threat #1: If QC arrives before all your classically encrypted data reaches end of life – you’ve got a major security breach (data vaulting attack) Threat #2: If QC arrives before you are retooled – the problem is even worse – your system’s real time security will be completely exposed and the fix will probably not be quick. X = “how many years does your data need to be secure” Y = “how long will it take you to retool” Z = “when will QC arrive”
Applying the IQC “Panic” Equation Time you need your current encryption to be secure (X) Time needed to retool crypto, standards and IT infrastructure (Y) Assessment on when QC threat arrives (see chart 5) (Z) Time Your Keys (and Confidential Data) are Exposed 15 10 10 15 Years 15 10 15 10 Years 15 3 5 13 Years 15 3 10 10 Years 15 3 15 10 Years 30 5 12 23 Years • More realistic confidentiality period for banks, healthcare, govt., etc. • Aggressive retooling time • Assumption that QC will arrive fairly slowly • Three years is extremely aggressive retooling – effectively mass panic mode. • Ten years is aggressive but achievable retooling. • Fifteen years of data confidentiality (x) is low for many govt, health, financial … institutions
From A New Study: “Most Organizations Can’t Protect Digital Information in the Long-Term” “New research has revealed that the majority of organizations DO NOT have a coherent long-term strategy for their vital digital information even though virtually all of them (98%) are required to keep information for ten years or longer.” “While 97% of information professionals understand the need for a specialized approach to these assets, only 11% are storing them in systems specifically designed to ensure long-term protection and access. This gap has economic, legal, and business competitiveness implications. The research, conducted by think tank the Information Governance Initiative (IGI), provides a new benchmark for organizations to evaluate their capability and outlines tactics for closing this critical gap. It also reports on how leading organizations like Associated Press, HSBC, and the State of Texas have addressed this challenge.” “The research, conducted by think tank the Information Governance Initiative (IGI), provides a new benchmark for organizations to evaluate their capability and outlines tactics for closing this critical gap. It also reports on how leading organizations like Associated Press, HSBC, and the State of Texas have addressed this challenge.” https://www.helpnetsecurity.com/2016/05/17/protect-digital-information/
A Common Sense Timeline to Quantum Safety – Building a Quantum Risk Mgmt. Plan (QRMP) 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 Deliver Phase 1 - Quantum Risk Management Plan as an RFP Response Deliver Phase 2 - Quantum-Safe Solutions: • Quantum-safe TLS to combat data vaulting threat • Quantum-safe code signing • Quantum-safe symmetric keys Deliver Phase 3 – Complete Quantum-Safety • Quantum-Safe Standardized PKI • Quantum-Safe Authentication, Key Management, etc. Probability of general purpose QC doing crypto breaking is very real after 2022 – it could occur sooner… 1 ½ yrs 4 ½ yrs Template for a “Quantum Risk Management Plan” (QRMP)
NTRU and pqNTRUsign Algorithm Summary Quantum Bit Strength NTRU Encryption Algorithm pqNTRUsign Signature Algorithm 128 NTRU-443 (Private key size = 396 bits Public key size = 665 bytes) pqNTRUsign-563 (Private Key Size= 540 bits, Public key size =1056 bytes, signature size = 1056 bytes ) 192 NTRU-587 (Private key size = 504 bits Public key size = 881 bytes) pqNTRUsign-743 (Private Key Size= 560 bits, Public key size =1486 bytes, signature size = 1486 bytes ) 256 NTRU-743 (Private key size = 740 bits Public key size = 1115 bytes) pqNTRUsign-907 (Private Key Size = 640 bits, Public key size =1814 bytes, signature size = 1814 bytes ) Notes: 1. For post-quantum cryptography you need to know their quantum bit strengths – not the classical bit strengths. 2. The suffixes on the NTRU and pqNTRUsign algorithms designate their polynomial which is one-half of the NTRU lattice size they use. 3. For NTRU private keys, store the seed and compute it on demand for decryption. (private keys are less than 100 bytes). The seed size is 2x the security level (quantum bit strength) (e.g. for NTRU-443 it is 256 bits.)
NTRU Standardization and Adoption • NTRUEncrypt • 2008: IEEE standard 1363.1 – NTRUEncrypt • 2010: X9 standard X9.98 – NTRUEncrypt • Quantum-Safe Hybrid (QSH) Internet Draft – Standalone RFC in Progress • Involved with quantum-safe standardization work with NIST, ISO, ETSI. • Implemented in: • wolfSSL (wolfSSL supports 1 billion TLS connections worldwide) • Cyph (IM), Imprivata ( Healthcare IT), Unseen (IM), Texas Instruments OMAP chip (cellphone technology), WikID (2FA) , EchoSat (POS credit card devices) • Following the NSA Announcement, 2015 technical breakthroughs, etc. … Interest has understandably skyrocketed.
How long do your secrets need to live? • If you send something now… • Encrypted with an algorithm that’s later broken… • And someone’s stored your message… • They can decrypt it • Encryption needs to take into account the lifetime for which your data might remain sensitive • Attacker who doesn’t actively get involved at the time of the interaction, but passively records traffic for later analysis • Fits known attacker pattern • Attacks: • Quantum computing • Other yet-to-be-discovered classical
Basic model of public-key encryption
Post-quantum problem
Solution 1
Solution 1 • No FIPS-approved quantum-safe algorithms
Potential transitional solution • “Hybrid” approach • FIPS-approved algorithm for conformance, quantum-safe algorithm for quantum- safety • But isn’t it still not allowed to run a non-Approved algorithm in Approved mode?
Approved mode
Approved mode
Looking closer at decryption (1)
Key Derivation methods • SP 800-56B, “Recommendation for Pair-Wise Key- Establishment Schemes Using Integer Factorization Cryptography”
Looking closer at decryption (2)
OtherInfo in KDF
Looking closer at decryption (3) • The field “OtherInfo” is input to the KDF and FIPS 140-2 puts no constraints on where it comes from • Idea: Use this to quantum- safe our exchange • Question: Is this permissible?
OtherInfo in KDF
OtherInfo in KDF
Can we include symmetric keys in OtherInfo?
Suitable schemes in SP 800-56B Scheme Section Uses KDF KAS1 Key Agreement (basic or with confirmation) 8.2 ✔ KAS2 Key agreement (basic or with any form of confirmation) 8.3 ✔ KTS-OAEP (basic or with confirmation) 9.2 NO KTS-KEM-KWS 9.3 ✔ KDF Section Allows OtherInfo Single-step Key- Derivation Function 5.8.1 ✔ Extraction-then- Expansion Key- Derivation Procedure 5.8.2 ✔ Application- Specific Key- Derivation Methods 5.8.2 … all but one scheme, and both baseline KDFs, in SP 800- 56B support OtherInfo ==> all but one scheme, if used with either baseline KDF, supports quantum-safe hybrid
Suitable Schemes in SP 800-56A Scheme Section Uses KDF dhHybrid1 6.1.1.1 ✔ (Cofactor) Full Unified Model 6.1.1.2 ✔ MQV2 6.1.1.3 ✔ Full MQV 6.1.1.4 ✔ dhEphem 6.1.2.1 ✔ (Cofactor) Ephemeral Unified Model 6.1.2.2 ✔ dhHybridOneFlow 6.2.1.1 ✔ (Cofactor) One-Pass Unified Model 6.2.1.2 ✔ MQV1 6.2.1.3 ✔ One-Pass MQV 6.2.1.4 ✔ dhOneFlow 6.2.2.1 ✔ (Cofactor) One-Pass Diffie-Hellman 6.2.2.2 ✔ dhStatic 6.3.1 ✔ (Cofactor) Static Unified Model 6.3.2 ✔ KDF Section Allows OtherInfo Single-step Key- Derivation Function 5.8.1 ✔ Extraction-then- Expansion Key- Derivation Procedure 5.8.2 ✔ Application- Specific Key- Derivation Methods 5.8.2 … every single scheme, and both baseline KDFs, in SP 800- 56A support OtherInfo ==> every scheme, if used with either baseline KDF, supports quantum-safe hybrid
This is clearly okay • q-pub/q-priv are ephemeral keys to the greatest extent possible – ideally, they are used for a single exchange and then deleted • It is clear that a FIPS-approved module, running in FIPS mode, can do this • You can construct a security proof showing that this “doesn’t make things worse”
TLS Negotiation with QSH (Quantum Safe Hybrid) Alice Symmetric Key (K1) K1 = KDF(S,q) Note: KDF = Key Derivation Function Bob Symmetric Key (K2) K2 = KDF(S,q) Note: KDF = Key Derivation Function #1 TLS Initial Handshake: • Client gives NTRU public key to server and indicates it has QSH support when it sends “HelloClient” to start negotiation • If server selects QSH, it creates a random number, q, encrypts it with the NTRU public key and sends it to the client. Alice Bob #2 Create Pre-Master Secret: • Standard Diffie-Hellman, RSA, ECC, etc. TLS handshake protocol runs creatings/sharing the same pre-master secret, S, on each endpoint Step #1 Step #2 Step #3 qq S S K1=K2
What about this? • Same as previous, except the quantum-safe decryption runs inside the secured boundary • Clearly more secure… • ... But can it be done in Approved mode?
Approved mode • If we could argue that QSH wasn’t a “security” function but a “key uniqueness” function, it would be okay to run it internally • If we could argue that QSH wasn’t a “security” function but a “personalization function”, it would be okay to run it internally • If NIST changed this to “employs only Approved security functions, except to derive the OtherInfo field”; or simply issued guidance that using non-Approved functions to derive the OtherInfo field is okay, it would be okay to run it internally
• Tomorrow: QSH via ephemeral keys in software outside the FIPS device, shared secret entered via OtherInfo • Two years (?): NIST issues guidance allowing OtherInfo to be obtained using non-Approved security mechanisms; FIPS- approved devices, running in FIPS Approved Mode, can carry out QSH • Five years (?): NIST approves quantum-safe algorithms: FIPS- approved devices can be in FIPS mode while only running quantum- safe algorithms Roadmap to quantum-safe devices running in FIPS Approved mode
NIST Position on QSH and FIPS 140-2

More Related Content

Quantum Safety in Certified Cryptographic Modules

  • 1. Quantum Safety In Certified Cryptographic Modules William Whyte, Lee Wilson
  • 2. What’s Causing All the Fuss? Shor’s Algorithm (From Quantum Computing for Computer Scientists by Noson Yanofsky and Mirco Mannucci) Input: A positive integer N with n = [log2 N]. Output: A factor p of N if it exists. 1. Use a polynomial algorithm to determine if N is prime or a power of prime. If it is a prime, declare that it is and exit. If it is a power of a prime number, declare that it is and exit. 2. Randomly choose an integer a such that 1 < a < N. Perform Euclid’s algorithm to determine GCD( a, N). If the GCD is not 1, then return it and exit. 3. Use the quantum circuit below to find a period r. 4. If r is odd or if ar ≡ − 1 Mod N, then return to #2 and choose another a. 5. Use Euclid’s algorithm to calculate GCD((𝑎 𝑟/2 +1),N) and GCD((𝑎 𝑟/2 −1),N) . Return at least one of the nontrivial solutions. Note: These gate symbols denote measuring the qubit. Note: The QFT is a “Quantum Fourier Transform” gate.
  • 3. Insights from “Cybersecurity in an era with quantum computers: will we be ready?” – 5 Main Points The referenced paper was written by Michele Mosca (University of Waterloo, Chairman of the Institute for Quantum Computing, Canada Research Chair in Quantum Computation) 1.The transition to quantum-safety will take lots of time and energy. • “There is no quick fix and we cannot quickly make up lost time.” 2.Quantum computer will arrive before we’re ready. 3.A wake up call is needed… The main challenges aren’t technical. • “Despite the many technical and scientific challenges to deploying quantum-safe cryptography, the main challenges in my opinion are the business and policy decisions that would drive the adoption of quantum-safe cryptography….” 4.Quantum computers will be of immense value to mankind, but the impact of quantum computers on cybersecurity will be catastrophic. • “Harnessing the power of quantum mechanics in large-scale quantum computers will allow us to solve many valuable problems for humanity, but we must first take the catastrophic impact of breaking cybersecurity off the table by developing and deploying a suite of quantum-safe cryptographic tools before quantum computers arrive.” 5.Quantum-safe cryptography is not an option in the new age of quantum computing. • “Quantum-safe cryptography is a necessary part of cybersecurity in an era with quantum computers…”
  • 5. From “A Two-Qubit Logic Gate in Silicon”, Nature Magazine, 10/15/15 “Although these silicon qubits represent the smallest scalable two-qubit system reported so far, the complete fabrication process is compatible with standard CMOS (complementary metal – oxide–semiconductor) technology, and is also consistent with current transistor feature sizes, offering the prospect of realizing a large-scale quantum processor using the same silicon manufacturing technologies that have enabled the current information age.” UNSW Can Now Make Qubits Using Standard CMOS Fabrication Technology….
  • 6. Projected Probability of General Purpose Quantum Computers Arriving By Year Critical infrastructure and industries with fiduciary responsibilities MUST be re-tooled when the threat window opens! The green graph is based on data from the IQC (Institute for Quantum Computing) provided earlier in 2015. The red graph is based on data after significant breakthroughs were achieved (Microsoft, UNSW, IBM, Google, etc.) since the beginning of 2H15.
  • 7. There are 2 Very Important Threats… The 1st Is Already Here… We Have a FIPS 140-2 Compliant Solution Threat #1: If QC arrives before all your classically encrypted data reaches end of life – you’ve got a major security breach (data vaulting attack) Threat #2: If QC arrives before you are retooled – the problem is even worse – your system’s real time security will be completely exposed and the fix will probably not be quick. X = “how many years does your data need to be secure” Y = “how long will it take you to retool” Z = “when will QC arrive”
  • 8. Applying the IQC “Panic” Equation Time you need your current encryption to be secure (X) Time needed to retool crypto, standards and IT infrastructure (Y) Assessment on when QC threat arrives (see chart 5) (Z) Time Your Keys (and Confidential Data) are Exposed 15 10 10 15 Years 15 10 15 10 Years 15 3 5 13 Years 15 3 10 10 Years 15 3 15 10 Years 30 5 12 23 Years • More realistic confidentiality period for banks, healthcare, govt., etc. • Aggressive retooling time • Assumption that QC will arrive fairly slowly • Three years is extremely aggressive retooling – effectively mass panic mode. • Ten years is aggressive but achievable retooling. • Fifteen years of data confidentiality (x) is low for many govt, health, financial … institutions
  • 9. From A New Study: “Most Organizations Can’t Protect Digital Information in the Long-Term” “New research has revealed that the majority of organizations DO NOT have a coherent long-term strategy for their vital digital information even though virtually all of them (98%) are required to keep information for ten years or longer.” “While 97% of information professionals understand the need for a specialized approach to these assets, only 11% are storing them in systems specifically designed to ensure long-term protection and access. This gap has economic, legal, and business competitiveness implications. The research, conducted by think tank the Information Governance Initiative (IGI), provides a new benchmark for organizations to evaluate their capability and outlines tactics for closing this critical gap. It also reports on how leading organizations like Associated Press, HSBC, and the State of Texas have addressed this challenge.” “The research, conducted by think tank the Information Governance Initiative (IGI), provides a new benchmark for organizations to evaluate their capability and outlines tactics for closing this critical gap. It also reports on how leading organizations like Associated Press, HSBC, and the State of Texas have addressed this challenge.” https://www.helpnetsecurity.com/2016/05/17/protect-digital-information/
  • 10. A Common Sense Timeline to Quantum Safety – Building a Quantum Risk Mgmt. Plan (QRMP) 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 Deliver Phase 1 - Quantum Risk Management Plan as an RFP Response Deliver Phase 2 - Quantum-Safe Solutions: • Quantum-safe TLS to combat data vaulting threat • Quantum-safe code signing • Quantum-safe symmetric keys Deliver Phase 3 – Complete Quantum-Safety • Quantum-Safe Standardized PKI • Quantum-Safe Authentication, Key Management, etc. Probability of general purpose QC doing crypto breaking is very real after 2022 – it could occur sooner… 1 ½ yrs 4 ½ yrs Template for a “Quantum Risk Management Plan” (QRMP)
  • 11. NTRU and pqNTRUsign Algorithm Summary Quantum Bit Strength NTRU Encryption Algorithm pqNTRUsign Signature Algorithm 128 NTRU-443 (Private key size = 396 bits Public key size = 665 bytes) pqNTRUsign-563 (Private Key Size= 540 bits, Public key size =1056 bytes, signature size = 1056 bytes ) 192 NTRU-587 (Private key size = 504 bits Public key size = 881 bytes) pqNTRUsign-743 (Private Key Size= 560 bits, Public key size =1486 bytes, signature size = 1486 bytes ) 256 NTRU-743 (Private key size = 740 bits Public key size = 1115 bytes) pqNTRUsign-907 (Private Key Size = 640 bits, Public key size =1814 bytes, signature size = 1814 bytes ) Notes: 1. For post-quantum cryptography you need to know their quantum bit strengths – not the classical bit strengths. 2. The suffixes on the NTRU and pqNTRUsign algorithms designate their polynomial which is one-half of the NTRU lattice size they use. 3. For NTRU private keys, store the seed and compute it on demand for decryption. (private keys are less than 100 bytes). The seed size is 2x the security level (quantum bit strength) (e.g. for NTRU-443 it is 256 bits.)
  • 12. NTRU Standardization and Adoption • NTRUEncrypt • 2008: IEEE standard 1363.1 – NTRUEncrypt • 2010: X9 standard X9.98 – NTRUEncrypt • Quantum-Safe Hybrid (QSH) Internet Draft – Standalone RFC in Progress • Involved with quantum-safe standardization work with NIST, ISO, ETSI. • Implemented in: • wolfSSL (wolfSSL supports 1 billion TLS connections worldwide) • Cyph (IM), Imprivata ( Healthcare IT), Unseen (IM), Texas Instruments OMAP chip (cellphone technology), WikID (2FA) , EchoSat (POS credit card devices) • Following the NSA Announcement, 2015 technical breakthroughs, etc. … Interest has understandably skyrocketed.
  • 13. How long do your secrets need to live? • If you send something now… • Encrypted with an algorithm that’s later broken… • And someone’s stored your message… • They can decrypt it • Encryption needs to take into account the lifetime for which your data might remain sensitive • Attacker who doesn’t actively get involved at the time of the interaction, but passively records traffic for later analysis • Fits known attacker pattern • Attacks: • Quantum computing • Other yet-to-be-discovered classical
  • 14. Basic model of public-key encryption
  • 17. Solution 1 • No FIPS-approved quantum-safe algorithms
  • 18. Potential transitional solution • “Hybrid” approach • FIPS-approved algorithm for conformance, quantum-safe algorithm for quantum- safety • But isn’t it still not allowed to run a non-Approved algorithm in Approved mode?
  • 21. Looking closer at decryption (1)
  • 22. Key Derivation methods • SP 800-56B, “Recommendation for Pair-Wise Key- Establishment Schemes Using Integer Factorization Cryptography”
  • 23. Looking closer at decryption (2)
  • 25. Looking closer at decryption (3) • The field “OtherInfo” is input to the KDF and FIPS 140-2 puts no constraints on where it comes from • Idea: Use this to quantum- safe our exchange • Question: Is this permissible?
  • 28. Can we include symmetric keys in OtherInfo?
  • 29. Suitable schemes in SP 800-56B Scheme Section Uses KDF KAS1 Key Agreement (basic or with confirmation) 8.2 ✔ KAS2 Key agreement (basic or with any form of confirmation) 8.3 ✔ KTS-OAEP (basic or with confirmation) 9.2 NO KTS-KEM-KWS 9.3 ✔ KDF Section Allows OtherInfo Single-step Key- Derivation Function 5.8.1 ✔ Extraction-then- Expansion Key- Derivation Procedure 5.8.2 ✔ Application- Specific Key- Derivation Methods 5.8.2 … all but one scheme, and both baseline KDFs, in SP 800- 56B support OtherInfo ==> all but one scheme, if used with either baseline KDF, supports quantum-safe hybrid
  • 30. Suitable Schemes in SP 800-56A Scheme Section Uses KDF dhHybrid1 6.1.1.1 ✔ (Cofactor) Full Unified Model 6.1.1.2 ✔ MQV2 6.1.1.3 ✔ Full MQV 6.1.1.4 ✔ dhEphem 6.1.2.1 ✔ (Cofactor) Ephemeral Unified Model 6.1.2.2 ✔ dhHybridOneFlow 6.2.1.1 ✔ (Cofactor) One-Pass Unified Model 6.2.1.2 ✔ MQV1 6.2.1.3 ✔ One-Pass MQV 6.2.1.4 ✔ dhOneFlow 6.2.2.1 ✔ (Cofactor) One-Pass Diffie-Hellman 6.2.2.2 ✔ dhStatic 6.3.1 ✔ (Cofactor) Static Unified Model 6.3.2 ✔ KDF Section Allows OtherInfo Single-step Key- Derivation Function 5.8.1 ✔ Extraction-then- Expansion Key- Derivation Procedure 5.8.2 ✔ Application- Specific Key- Derivation Methods 5.8.2 … every single scheme, and both baseline KDFs, in SP 800- 56A support OtherInfo ==> every scheme, if used with either baseline KDF, supports quantum-safe hybrid
  • 31. This is clearly okay • q-pub/q-priv are ephemeral keys to the greatest extent possible – ideally, they are used for a single exchange and then deleted • It is clear that a FIPS-approved module, running in FIPS mode, can do this • You can construct a security proof showing that this “doesn’t make things worse”
  • 32. TLS Negotiation with QSH (Quantum Safe Hybrid) Alice Symmetric Key (K1) K1 = KDF(S,q) Note: KDF = Key Derivation Function Bob Symmetric Key (K2) K2 = KDF(S,q) Note: KDF = Key Derivation Function #1 TLS Initial Handshake: • Client gives NTRU public key to server and indicates it has QSH support when it sends “HelloClient” to start negotiation • If server selects QSH, it creates a random number, q, encrypts it with the NTRU public key and sends it to the client. Alice Bob #2 Create Pre-Master Secret: • Standard Diffie-Hellman, RSA, ECC, etc. TLS handshake protocol runs creatings/sharing the same pre-master secret, S, on each endpoint Step #1 Step #2 Step #3 qq S S K1=K2
  • 33. What about this? • Same as previous, except the quantum-safe decryption runs inside the secured boundary • Clearly more secure… • ... But can it be done in Approved mode?
  • 34. Approved mode • If we could argue that QSH wasn’t a “security” function but a “key uniqueness” function, it would be okay to run it internally • If we could argue that QSH wasn’t a “security” function but a “personalization function”, it would be okay to run it internally • If NIST changed this to “employs only Approved security functions, except to derive the OtherInfo field”; or simply issued guidance that using non-Approved functions to derive the OtherInfo field is okay, it would be okay to run it internally
  • 35. • Tomorrow: QSH via ephemeral keys in software outside the FIPS device, shared secret entered via OtherInfo • Two years (?): NIST issues guidance allowing OtherInfo to be obtained using non-Approved security mechanisms; FIPS- approved devices, running in FIPS Approved Mode, can carry out QSH • Five years (?): NIST approves quantum-safe algorithms: FIPS- approved devices can be in FIPS mode while only running quantum- safe algorithms Roadmap to quantum-safe devices running in FIPS Approved mode
  • 36. NIST Position on QSH and FIPS 140-2