PROJECT DESCRIPTION

MIGRATION TO
POST-QUANTUM
CRYPTOGRAPHY
William Barker

Dakota Consulting

Murugiah Souppaya

National Institute of Standards and Technology

DRAFT

June 2021

[email protected]
 1 The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of
2 Standards and Technology (NIST), is a collaborative hub where industry organizations,
3 government agencies, and academic institutions work together to address businesses’ most
4 pressing cybersecurity challenges. Through this collaboration, the NCCoE develops modular,
5 adaptable example cybersecurity solutions demonstrating how to apply standards and best
6 practices by using commercially available technology. To learn more about the NCCoE, visit
7 https://www.nccoe.nist.gov/. To learn more about NIST, visit http://www.nist.gov.
8 This document describes challenges associated with migration from current public-key
9 cryptographic algorithms to quantum-resistant algorithms, and approaches to facilitating that
10 migration.

11 ABSTRACT
12 The NIST National Cybersecurity Center of Excellence (NCCoE) is initiating the development of
13 practices to ease the migration from the current set of public-key cryptographic algorithms to
14 replacement algorithms that are resistant to quantum computer-based attacks. These practices
15 will take the form of white papers, playbooks, and demonstrable implementations for
16 organizations. In particular, the audience for these practices is intended to include organizations
17 that provide cryptographic standards and protocols and enterprises that develop, acquire,
18 implement, and service cryptographic products. This effort complements the NIST post-
19 quantum cryptography (PQC) standardization activities.

20 ACKNOWLEDGMENTS
21 This project description was developed from the presentations and discussions that occurred at
22 the NCCoE-hosted Virtual Workshop on Considerations in Migrating to Post-Quantum
23 Cryptographic Algorithms. NCCoE thanks Dustin Moody, Lidong Chen, and Matthew Scholl for
24 contributing to the development of this project description.

25 KEYWORDS
26 algorithm; cryptographic hardware; cryptographic module; cryptography; encryption; identity
27 management; key establishment and management; post-quantum cryptography; public-key
28 cryptography

29 DISCLAIMER
30 Certain commercial entities, equipment, products, or materials may be identified in this
31 document in order to describe an experimental procedure or concept adequately. Such
32 identification is not intended to imply recommendation or endorsement by NIST or NCCoE, nor
33 is it intended to imply that the entities, equipment, products, or materials are necessarily the
34 best available for the purpose.

35 COMMENTS ON NCCOE DOCUMENTS

36 Organizations are encouraged to review all draft publications during public comment periods
37 and provide feedback. All publications from NIST’s National Cybersecurity Center of Excellence
38 are available at https://www.nccoe.nist.gov/.
39 Comments on this publication may be submitted to [email protected].
40 Public comment period: June 4, 2021 to July 7, 2021
 DRAFT

41 TABLE OF CONTENTS
42 1 Executive Summary..........................................................................................................3
43 Purpose ..................................................................................................................................... 3
44 Scope ......................................................................................................................................... 3
45 Assumptions & Challenges........................................................................................................ 5
46 Background ............................................................................................................................... 6
47 2 Demonstration Scenarios .................................................................................................8
48 Scenario 1: FIPS-140 validated hardware and software modules that employ quantum-
49 vulnerable public-key cryptography ......................................................................................... 8
50 Scenario 2: Cryptographic libraries that include quantum-vulnerable public-key
51 cryptography ............................................................................................................................ 8
52 Scenario 3: Cryptographic applications and cryptographic support applications that include
53 or are focused on quantum-vulnerable public-key cryptography ............................................ 9
54 Scenario 4: Embedded quantum-vulnerable cryptographic code in computing platforms ... 10
55 Scenario 5: Communication protocols widely deployed in different industry sectors that
56 leverage quantum-vulnerable cryptographic algorithms ....................................................... 11
57 3 High-Level Architecture ..................................................................................................11
58 Component List ....................................................................................................................... 12
59 Desired Security Characteristics and Properties..................................................................... 12
60 4 Relevant Standards and Guidance ..................................................................................12
61 Appendix A References.......................................................................................................14
62 Appendix B Acronyms ........................................................................................................15

Project Description: Migration to Post-Quantum Cryptography 2

 DRAFT

63 1 EXECUTIVE SUMMARY
64 Purpose
65 As reflected in National Institute of Standards and Technology (NIST) Interagency or Internal
66 Report (NISTIR) 8105, Report on Post-Quantum Cryptography [1] and NISTIR 8309, Status Report
67 on the Second Round of the NIST Post-Quantum Cryptography Standardization Process [2], work
68 on the development of quantum-resistant public-key cryptographic standards is underway, and
69 the algorithm selection process is well in-hand, with algorithm selection expected to be
70 completed in the next one to two years (https://csrc.nist.gov/projects/post-quantum-
71 cryptography).
72 To complement the ongoing effort, the National Cybersecurity Center of Excellence (NCCoE) has
73 initiated a campaign to bring awareness to the issues involved in migrating to post-quantum
74 algorithms, which will include developing white papers, playbooks, and proof-of-concept
75 implementations. NIST has developed and posted a cybersecurity white paper, Getting Ready
76 for Post-Quantum Cryptography [3] to start the discussion.
77 In addition, the NCCoE is forming a Cryptographic Applications community of interest in
78 coordination with the NIST Post-Quantum Cryptography standardization team and the
79 Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA)
80 team. The community of interest will work on a migration playbook that would address the
81 challenges previously described and provide recommended practices to prepare for a smooth
82 cryptographic migration.
83 Finally, the NCCoE has developed this project description for practical demonstration of
84 technology and tools that can support a head start on executing a migration roadmap in
85 collaboration with this community of interest.
86 Scope
87 There is currently no inventory that can guide updates to standards, guidelines, regulations,
88 hardware, firmware, operating systems, communication protocols, cryptographic libraries, and
89 applications that employ cryptography that meets the need to accelerate migration to quantum-
90 resistant cryptography. As a starting point for expeditiously discovering where updates to
91 quantum-resistant cryptography will be required, NIST is planning:
92 • discovery of all instances where NIST Federal Information Processing Standards (FIPS),
93 800-series Special Publications (SPs), and other guidance will need to be updated or
94 replaced;
95 • discovery of which standards from the International Organization for
96 Standardization/International Electrotechnical Commission (ISO/IEC), Institute of
97 Electrical and Electronics Engineers (IEEE), industry groups like the Trusted Computing
98 Group, and other standards developing organizations will need to be updated or
99 replaced; and
100 • discovery of which Internet Engineering Task Force (IETF) Request for Comments (RFCs)
101 and other networking protocol standards will need to be updated or replaced.
102 Implementation of quantum-safe algorithms requires identifying hardware and software
103 modules, libraries, and embedded code currently used in an enterprise to support cryptographic
104 key establishment and management underlying the security of cryptographically-protected

Project Description: Migration to Post-Quantum Cryptography 3

 DRAFT

105 information and access management processes, as well as provide the source and content
106 integrity of data at rest, in transit, and in use.
107 The initial scope of this project is to demonstrate the discovery tools that can provide
108 automation assistance in identifying where and how public-key cryptography is being used in
109 hardware, firmware, operating systems, communication protocols, cryptographic libraries, and
110 applications employed in data centers on-premises or in the cloud and distributed compute,
111 storage, and network infrastructures. The recommended project will engage industry in
112 demonstrating use of automated discovery tools to identify all instances of public-key algorithm
113 use in an example network infrastructure’s computer and communications hardware, operating
114 systems, application programs, communications protocols, key infrastructures, and access
115 control mechanisms. The algorithm employed and the use for which the algorithm is employed
116 would be identified for each affected infrastructure component.
117 Once the public-key cryptography components and associated assets in the enterprise are
118 identified, the next element of the scope of the project is to prioritize those components that
119 need to be considered first in the migration using a risk management methodology informed by
120 “Mosca’s Theorem” and other recommended practices.
121 Michele Mosca’s theorem in Cybersecurity in an era with quantum computers: will we be ready?
122 (https://eprint.iacr.org/2015/1075) says that we need to start worrying about the impact of
123 quantum computers when the amount of time that we wish our data to be secure for (X),
124 added to the time it will take for our computer systems to transition from classical to post-
125 quantum (Y), is greater than the time it will take for quantum computers to start breaking
126 existing quantum-susceptible encryption protocols—or when X + Y > Z.
127 Finally, the project will provide systematic approaches for migrating from vulnerable algorithms
128 to quantum-resistant algorithms across the different types of assets and supporting underlying
129 technology. For example:
130 • Each enterprise that produces, supports, or uses public-key cryptography might conduct
131 an inventory to determine what systems and components use public-key cryptography
132 and how the cryptography is used to protect the confidentiality or integrity of
133 information being exchanged, stored, or used to control processes (both information
134 technology and operational technology processes.) Examples include code signing
135 platforms, public-key infrastructure, and data security systems.
136 • At the same time, quantum-vulnerable information stored and/or exchanged within the
137 enterprise and with customers and partners might be categorized with respect to
138 criticality, disclosure sensitivity, and the consequences of unauthorized and undetected
139 modification.
140 • Enterprises might also work with government and industry to identify emerging
141 quantum-resistant cryptographic standards and products, their technical and
142 operational characteristics, and their anticipated timeframe for availability to replace
143 quantum-vulnerable systems and components.
144 • Enterprises might work with public and private sector experts and providers to
145 implement the emerging quantum-resistant crypto algorithms into protocols and
146 technology.

Project Description: Migration to Post-Quantum Cryptography 4

 DRAFT

147 • Enterprises might then work with public and private sector experts and providers to
148 identify any technical constraints that their cryptographically dependent systems
149 impose on replacement systems and components, and to resolve any incompatibilities.
150 • Enterprises should also work with service providers, partners, and customers to
151 coordinate adoption of technical solutions as necessary to maintain interoperability and
152 to satisfy existing agreements regarding the security of information content and
153 continuity of information distribution.
154 • Enterprises might then be able to work with their technology suppliers to establish a
155 procurement process consistent with enterprise priorities and plans.
156 Assumptions & Challenges
157 The discovery of new cryptographic weaknesses or advances in the technologies supporting
158 cryptanalysis often lead to the need to replace a legacy cryptographic algorithm. The advent of
159 quantum computing technology will compromise many of the current cryptographic algorithms,
160 especially public-key cryptography, which is widely used to protect digital information. Most
161 algorithms on which we depend are used worldwide in components of many different
162 communications, processing, and storage systems.
163 Many information systems lack crypto agility. That is, they are not designed to encourage
164 support of rapid adaptations of new cryptographic primitives and algorithms without making
165 significant changes to the system's infrastructure. As a result, an organization may not possess
166 complete control over its cryptographic mechanisms and processes so that they can make
167 accurate alterations to them without involving intense manual effort.
168 The replacement of algorithms generally requires the following first steps:
169 • identifying the presence of the legacy algorithms
170 • understanding the data formats and application programming interfaces of
171 cryptographic libraries to support necessary changes and replacements
172 • discovering the hardware that implements or accelerates algorithm performance
173 • determining operating system and application code that uses the algorithm
174 • identifying all communications devices with vulnerable protocols
175 • identifying cryptographic protocol dependencies on algorithm characteristics
176 Once an enterprise has discovered where and for what it is employing public-key cryptography,
177 the organization can determine the use characteristics, such as:
178 • current key sizes and hardware/software limits on future key sizes and signature sizes
179 • latency and throughput thresholds
180 • processes and protocols used for crypto negotiation
181 • current key establishment handshake protocols
182 • where each cryptographic process is taking place in the stack
183 • how each cryptographic process is invoked (e.g., by a call to a crypto library, using a
184 process embedded in the operating system, by calling to an application, using
185 cryptography as a service)
186 • whether the implementation supports the notion of crypto agility
187 • whether the implementation may be updated through software

Project Description: Migration to Post-Quantum Cryptography 5

 DRAFT

188 • supplier(s) and owner(s) of each cryptographic hardware/software/process

189 • source(s) of keys and certificates
190 • contractual and legal conditions imposed by and on the supplier
191 • whether the use of the implementation requires validation under the Cryptographic
192 Module Validation Program
193 • the support lifetime or expected end-of-life of the implementation, if stated by the
194 vendor
195 • intellectual property impacts of the migration
196 • sensitivity of the information that is being protected
197 The new algorithms will likely not be drop-in replacements. They may not have the same
198 performance or reliability characteristics as legacy algorithms due to differences in key size,
199 signature size, error handling properties, number of execution steps required to perform the
200 algorithm, key establishment process complexity, etc.
201 Once the replacement algorithms are selected, other operational considerations to accelerate
202 adoption and implementation across the organization include:
203 • developing a risk-based approach that takes into consideration security requirements,
204 business operations, and mission impact
205 • developing implementation validation tools
206 • identifying cases where interim (e.g., hybrid) implementations are necessary to
207 maintaining interoperability during migration.
208 • updating the processes and procedures of developers, implementers, and users
209 • establishing a communication plan to be used both within the organization and with
210 external customers and partners
211 • identifying a migration timeline and the necessary resources
212 • updating or replacing security standards, procedures, and recommended practice
213 documentation
214 • specifying procurement requirements to acquire quantum-safe technology
215 • providing installation, configuration, and administration documentation
216 • testing and validating the new processes and procedures
217 Background
218 Cryptographic technologies are used throughout government and industry to authenticate the
219 source and protect the confidentiality and integrity of information that we communicate and
220 store. Cryptographic technologies include a broad range of protocols, schemes, and
221 infrastructures, but they rely on a relatively small collection of cryptographic algorithms.
222 Cryptographic algorithms are the information transformation engines at the heart of these
223 cryptographic technologies.
224 Cryptographic algorithms are mathematical functions that transform data, generally using a
225 variable, or key, to protect information. The protection of these key variables is essential to the
226 continued security of the protected data. In the case of symmetric cryptographic algorithms, the
227 same key is used by both the originator and recipient of cryptographically protected
228 information. Symmetric keys must remain secret to maintain confidentiality; anyone with the

Project Description: Migration to Post-Quantum Cryptography 6

 DRAFT

229 key can recover the unprotected data. Asymmetric algorithms require the originator to use one
230 key and the recipient to use a different but related key. One of these asymmetric keys (the
231 private key) must be kept secret, but the other key (the public key) can be made public without
232 degrading the security of the cryptographic process. These asymmetric algorithms are
233 commonly called public-key algorithms.
234 Symmetric algorithms offer efficient processing for confidentiality and integrity, but key
235 management (establishing and maintaining secrets known only to the communicating parties)
236 poses a challenge. Symmetric algorithms offer weak proofs of origin since either party to an
237 exchange can calculate the transformation. Asymmetric algorithms generally require more
238 processing operations and time than are practical for providing confidentiality protection for
239 more than very small volumes of data. However, use of these algorithms is feasible for
240 cryptographic key establishment and digital signature processes. In the case of public-key
241 cryptography, one of the keys in a pair can be made public and distribution of private keys is not
242 needed. Asymmetric key algorithms can be used to establish pairwise keys and authenticate an
243 entity and/or data source in many-to-many communications without demanding a secret
244 channel for key distribution. As a result, most cryptographic entity or data source authentication
245 and key establishment functions use public-key cryptography.
246 From time to time, the discovery of a cryptographic weakness, constraints imposed by
247 dependent technologies, or advances in the technologies that support cryptanalysis make it
248 necessary to replace a legacy cryptographic algorithm. Most algorithms on which we depend are
249 used worldwide in components of many different communications, processing, and storage
250 systems. While some components of some systems tend to be replaced by improved
251 components on a relatively frequent basis (e.g., cell phones), other components are expected to
252 remain in place for a decade or more (e.g., components in electricity generation and distribution
253 systems). Communications interoperability and records archiving requirements introduce
254 additional constraints on system components. As a general rule, cryptographic algorithms
255 cannot be replaced until all components of a system are prepared to process the replacement.
256 Updates to protocols, schemes, and infrastructures must often be implemented when
257 introducing new cryptographic algorithms. Consequently, algorithm replacement can be
258 extremely disruptive and often takes decades to complete.
259 Continued progress in the development of quantum computing, a technology required to
260 support cryptanalysis using Shor’s algorithm, foreshadows a particularly disruptive
261 cryptographic transition. All widely used public-key cryptographic algorithms are vulnerable to
262 attacks based on Shor’s algorithm, but the algorithm depends upon operations that can only be
263 achieved by a large-scale quantum computer. Practical quantum computing, when available to
264 cyber adversaries, will break the security of nearly all modern public-key cryptographic systems.
265 Consequently, all secret symmetric keys and private asymmetric keys that are now protected
266 using current public-key algorithms and the information protected under those keys will be
267 subject to exposure. This includes all recorded communications and other stored information
268 protected by those public-key algorithms. Any information still considered to be private or
269 otherwise sensitive will be vulnerable to exposure. The same is true with respect to an
270 undetected modification of the information.
271 Once exploitation of Shor’s algorithm becomes practical, protecting stored keys and data will
272 require re-encrypting them with a quantum-resistant algorithm and deleting or physically
273 securing “old” copies (e.g., backups). Integrity and sources of information will become unreliable
274 unless they are processed or encapsulated (e.g., re-signed or timestamped) using a mechanism

Project Description: Migration to Post-Quantum Cryptography 7

 DRAFT

275 that is not vulnerable to quantum computing-based attacks. Nothing can be done to protect the
276 confidentiality of encrypted material that was stored by an adversary before re-processing.
277 We refer to algorithms that are vulnerable to exploitation by quantum computing mechanisms
278 as quantum-vulnerable.

279 2 DEMONSTRATION SCENARIOS

280 The quantum-safe cryptography discovery project will demonstrate tools for discovery of
281 quantum-vulnerable cryptographic code or dependencies on such code for several
282 implementation scenarios. Each of the scenarios involves discovery of quantum-vulnerable
283 cryptographic code or dependencies on quantum-vulnerable cryptographic code. Each scenario
284 also addresses some aspect of prioritization for replacement of quantum-vulnerable
285 cryptographic code or elimination of dependencies on quantum-vulnerable cryptographic code.
286 Finally, the scenarios address aspects of remediating deficiencies based on security control
287 dependence on quantum-vulnerable cryptography.
288 Scenario 1: FIPS-140 validated hardware and software modules that employ quantum-
289 vulnerable public-key cryptography
290 • The first step in this scenario involves discovery of FIPS-140 validated hardware and
291 software modules present in the enterprise that employ quantum-vulnerable public-key
292 cryptography.
293 • This step would be followed by determining the uses of each module (e.g., symmetric
294 key wrapping, digital signature).
295 • Where the module is used to protect specific data sets or processes, an assessment of
296 the criticality of the protected information or process should follow. Based on the
297 purposes for which the module is used and what it protects, prioritize the identified
298 modules for replacement.
299 • Since not all modules will be able to be replaced within the same timeframe due to
300 availability, validation status, or other considerations, a replacement availability
301 schedule will be developed that accommodates a staged or multiple step replacement
302 process. Not all replacements should necessarily be made using new public-key
303 algorithms. In some cases, use of a keyed hash, for example, may accomplish the same
304 purpose with a module that is both applicable and available sooner. In other cases, high-
305 priority components will not have near-term replacements, or the replacements may
306 have interface or performance characteristics that conflict with system requirements. In
307 such cases, compensating controls may be considered.
308 • The result of this scenario will be an identified set of quantum-vulnerable components,
309 identification of priorities for replacement based on the documented risk assessment,
310 and the migration/compensation strategy identified for each component (with
311 estimated timeline).
312 Scenario 2: Cryptographic libraries that include quantum-vulnerable public-key cryptography
313 • This scenario has as its initial step identifying a set of cryptographic libraries that are
314 commonly used in development of cryptographic software.
315 • This representative set of libraries will then be reviewed to identify the presence of calls
316 to routines associated with quantum-vulnerable public-key algorithms.

Project Description: Migration to Post-Quantum Cryptography 8

 DRAFT

317 • The libraries will also be reviewed to determine whether they also include algorithms or
318 supporting components for quantum-resistant algorithms that were selected for
319 standardization by the NIST post-quantum cryptography standardization process.
320 • Where a library does not include support for a NIST-selected algorithm, the library will
321 be identified as such and a recommendation will be made regarding inclusion of one or
322 more NIST-selected algorithms that fulfill one or more functions of the quantum-
323 vulnerable routines that are included in the library.
324 • Where a library does include support for a NIST-selected algorithm, a recommendation
325 will be made to determine that the algorithm or algorithmic element supports a correct
326 implementation of the NIST-selected algorithm.
327 • Based on collaborator input, an attempt will be made to identify the most commonly
328 called libraries.
329 • The result of this scenario will be identification of commonly employed cryptographic
330 libraries that support only quantum-vulnerable algorithms, identification of
331 cryptographic libraries that support one or more NIST-selected algorithms, and notes
332 identifying algorithms/modes selected, issues associated with correct support for the
333 quantum-resistant algorithms, and flagging of those libraries that have known malware
334 or other security-relevant coding flaws.
335 Scenario 3: Cryptographic applications and cryptographic support applications that include or
336 are focused on quantum-vulnerable public-key cryptography
337 • The initial step in this scenario is identification and selection of example cryptographic
338 applications and cryptographic support applications that include or are focused on
339 quantum-vulnerable public-key cryptography. Applications supporting information
340 exchange protocols such as Transport Layer Security (TLS) will be included, as well as
341 those supporting critical operating system and infrastructure processes including
342 financial systems and infrastructure control systems.
343 • Second, the team will identify the cryptographic function or functions supported by the
344 quantum-vulnerable algorithm(s) in each cryptographic application and cryptographic
345 support application (e.g., key agreement, key wrapping, digital signature,
346 authentication). As part of this step, the team will flag system security dependencies on
347 the availability of each cryptographic application and cryptographic support application
348 (e.g., subject identification, access authorization, confidentiality of data in transit and/or
349 at rest).
350 • The third step will be to identify any information exchange and processing protocols
351 that are dependent on each cryptographic application and cryptographic support
352 application being examined.
353 • Fourth, the team will identify the information technology or operational technology
354 environment in which each cryptographic application and cryptographic support
355 application is being used and will categorize the FIPS 199 [4] risk associated with the
356 failure of or unavailability of the application. The team will identify any compensating
357 controls that might be used to provide the needed control in lieu of an unavailable or
358 non-functional application.
359 • The team will next identify algorithm characteristics required by or limited by each
360 cryptographic or cryptographic support application examined (e.g., key size, block size,
361 mode of operation supported, error tolerance, latency, throughput).

Project Description: Migration to Post-Quantum Cryptography 9

 DRAFT

362 • The team will then, based on the algorithms remaining under consideration by the NIST
363 post-quantum standardization process, identify which, if any, candidate algorithms
364 meet the algorithm characteristics requirement for each application and flag those
365 applications for which no candidate algorithm can meet a requirement.
366 • Finally, the result of the scenario will be a listing of the applications prioritized by risk
367 category, functional criticality, and the number/scope of dependent systems and
368 processes. For each application, candidate replacement algorithms and/or
369 compensating controls will be identified. Those cases where no suitable algorithm or
370 compensating control can be identified will be flagged.
371 Scenario 4: Embedded quantum-vulnerable cryptographic code in computing platforms
372 • The initial step in this scenario will be to identify one or more operating system
373 environments (e.g., Microsoft Windows, Red Hat Enterprise Linux, macOS, iOS, Android)
374 for which quantum-vulnerable cryptography is embedded in operating system code,
375 access control utility code, cryptographic integrity applications and mechanisms, and
376 code embedded in identity and access management systems and applications.
377 • For each operating system environment, determine and document how widely it is used
378 and cite examples of dependent enterprises and infrastructures.
379 • For each operating system environment identified, the team will employ automated
380 tools to identify the quantum-vulnerable cryptographic code.
381 • For each instance identified, the team will assess the criticality of the code for the ability
382 of the system to function (e.g., are there settings that don’t require the code instance,
383 what is the security consequence of not invoking the code).
384 • For each instance of quantum-vulnerable cryptographic code, the team will identify
385 algorithm characteristics that are required by or limited by the code (key size, block size,
386 mode of operation supported, error tolerance, latency, throughput, etc.).
387 • The team will then, based on the algorithms remaining under consideration by the NIST
388 post-quantum algorithm standardization process, identify which, if any, candidate
389 algorithms meet the algorithm characteristics requirement for each code instance and
390 flag those instances for which no candidate algorithm can meet a requirement.
391 • The result of this scenario will be a list of all quantum-vulnerable public-key
392 cryptographic code identified, and for each code instance, the following information will
393 be provided:
394 o location and purpose of the code
395 o candidate NIST algorithms that were identified as suitable for replacing the
396 quantum-vulnerable code and projected impact of the replacement on
397 performance of the intended system functionality (include replacements’
398 characteristics such as rounds, key size, block size, etc.)
399 o consequence of simply deleting the code and any mitigation approach that
400 might be recommended
401 o priority of the recommended replacement or other mitigation
402 o flagging cases where neither replacement nor deletion appears to be practical,
403 and failure to do either will impair operating system functionality and/or
404 security

Project Description: Migration to Post-Quantum Cryptography 10

 DRAFT

405 Scenario 5: Communication protocols widely deployed in different industry sectors that
406 leverage quantum-vulnerable cryptographic algorithms
407 • The team will conduct a search for references to quantum-vulnerable public-key
408 algorithms in communications and network standards used by U.S.-based service
409 providers and representative enterprises in the financial, healthcare, energy,
410 transportation, and other sectors. Instances will be documented.
411 • The team will characterize how widespread use of the referenced protocol is and the
412 applications that it supports.
413 • For each documented reference, the team will identify any limitations or specifications
414 respecting key size, block size, or latency/throughput constraints.
415 • For each documented reference, the team will then, based on the algorithms remaining
416 under consideration by the NIST post-quantum standardization process, identify which,
417 if any, candidate algorithms satisfy the limitations and specifications and flag those
418 instances for which no candidate algorithm can meet a requirement.
419 • The result of the scenario will be a list of protocols. The list will be prioritized based on
420 how widespread its application is (the approximate number, size, and impact of users).
421 For each protocol, the following information will be provided:
422 o protocol identification
423 o organization responsible for maintaining the protocol
424 o protocol applications space (by whom it is used, and for what purpose)
425 o quantum-vulnerable algorithm(s) referenced by the protocol
426 • NIST quantum-resistant algorithm candidates potentially suitable to replace the
427 referenced quantum-vulnerable algorithm(s) will be identified
428 • Flag where no NIST quantum-resistant candidate is potentially suitable to replace the
429 referenced quantum-vulnerable algorithm(s)
430 All scenarios will address enterprise data center environments which include on-premises data
431 center and hybrid cloud deployment hosted by a third-party data center or a public cloud
432 provider.

433 3 HIGH-LEVEL ARCHITECTURE

434 The high-level architecture consists of a typical enterprise environment that connects the NCCoE
435 PQC laboratory hosted in Rockville, Maryland to external sites and cloud resources hosted by
436 the collaborators via the internet. This will enable the collaborators to install discovery tools in
437 the NCCoE laboratory and operate them remotely via virtual private network. Conversely, it will
438 enable staff in the NCCoE laboratory to use tools installed in the laboratory to discover
439 quantum-vulnerable software in remote sites either directly or using cloud services. The NCCoE
440 environment will be able to host physical, virtualized, and containerized workloads. It will
441 provide core infrastructure services like routing, naming, etc.; a set of typical application
442 services like directory, web servers, etc.; and core security services like firewalls. Various typical
443 endpoints will be available to host client-side operating systems, protocols, and applications.

Project Description: Migration to Post-Quantum Cryptography 11

 DRAFT

444 Component List

445 • General IT components:
446 o compute, storage, and network resources necessary to running cryptographic
447 code detection tools
448 o cloud services
449 • Functional security components:
450 o the data security component
451 o the endpoint security component
452 o the identity and access management component
453 o the security analytics component
454 • Devices and network infrastructure components:
455 o assets including the devices/endpoints
456 o core enterprise resources such as applications/services
457 o network infrastructure components
458 • Approaches and tools for discovering public-key cryptography components in:
459 o operating systems
460 o application code
461 o hardware implementing, controlling, or accelerating crypto functionality
462 • Approaches and tools for discovering algorithm migration impacts on:
463 o communications and network protocols
464 o key management protocols, processes, and procedures
465 o network management protocols, processes, and procedures
466 o business processes and procedures
467 Desired Security Characteristics and Properties
468 All candidate quantum-resistant replacements for quantum-vulnerable public-key algorithms
469 should have a security strength at least equivalent to that possessed by the quantum-vulnerable
470 algorithm being replaced, where the security strength of the algorithm being replaced is
471 measured in the absence of quantum computing.
472 Any suggestion for replacement of a quantum-vulnerable public-key algorithm by a
473 compensating control(s) should be accompanied by an explanation of how the compensating
474 control provides relevant confidentiality and integrity protection commensurate with that
475 currently being provided in the absence of quantum computing.
476 Any projected performance degradation resulting from a suggested replacement of a quantum-
477 vulnerable public-key algorithm by a NIST candidate quantum-resistant algorithm should be
478 characterized in the project findings.

479 4 RELEVANT STANDARDS AND GUIDANCE

480 Here is a list of existing relevant standards and guidance documents.

Project Description: Migration to Post-Quantum Cryptography 12

 DRAFT

481 • Federal Information Processing Standard (FIPS) 140-3, Security Requirements for
482 Cryptographic Modules
483 https://doi.org/10.6028/NIST.FIPS.140-3
484 • FIPS 199, Standards for Security Categorization of Federal Information and Information
485 Systems
486 https://doi.org/10.6028/NIST.FIPS.199
487 • Framework For Improving Critical Infrastructure Cybersecurity, Version 1.1
488 https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
489 • Getting Ready for Post-Quantum Cryptography: Exploring Challenges Associated with
490 Adopting and Using Post-Quantum Cryptographic Algorithms
491 https://doi.org/10.6028/NIST.CSWP.04282021
492 • NIST Internal Report (NISTIR) 8105, Report on Post-Quantum Cryptography
493 https://doi.org/10.6028/NIST.IR.8105
494 • NISTIR 8309, Status Report on the Second Round of the NIST Post-Quantum
495 Cryptography Standardization Process
496 https://doi.org/10.6028/NIST.IR.8309
497 • NIST Privacy Framework: A Tool For Improving Privacy Through Enterprise Risk
498 Management, Version 1.0
499 https://doi.org/10.6028/NIST.CSWP.01162020
500 • NIST Special Publication (SP) 800-53 Revision 5, Security and Privacy Controls for
501 Information Systems and Organizations
502 https://doi.org/10.6028/NIST.SP.800-53r5

Project Description: Migration to Post-Quantum Cryptography 13

 DRAFT

503 APPENDIX A REFERENCES

504 [1] L. Chen et al., Report on Post-Quantum Cryptography, National Institute of Standards and
505 Technology Internal Report (NISTIR) 8105, Gaithersburg, Md., April 2016, 15 pp. Available:
506 https://doi.org/10.6028/NIST.IR.8105

507 [2] G. Alagic et al., Status Report on the Second Round of the NIST Post-Quantum Cryptography
508 Standardization Process, NIST Interagency or Internal Report (NISTIR) 8309, Gaithersburg,
509 Md., July 2020, 39 pp. Available: https://doi.org/10.6028/NIST.IR.8309

510 [3] W. Barker, W. Polk, and M. Souppaya, Getting Ready for Post-Quantum Cryptography:
511 Exploring Challenges Associated with Adopting and Using Post-Quantum Cryptographic
512 Algorithms, NIST Cybersecurity White Paper, Gaithersburg, Md., April 2021, 10 pp. Available:
513 https://doi.org/10.6028/NIST.CSWP.04282021

514 [4] NIST, Standards for Security Categorization of Federal Information and Information Systems,
515 Federal Information Processing Standard (FIPS) 199, Gaithersburg, Md., February 2004, 13
516 pp. Available: https://doi.org/10.6028/NIST.FIPS.199

Project Description: Migration to Post-Quantum Cryptography 14

 DRAFT

517 APPENDIX B ACRONYMS

CISA Cybersecurity and Infrastructure Security Agency

DHS Department of Homeland Security
FIPS Federal Information Processing Standard
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IR (NIST) Interagency or Internal Report
ISO International Organization for Standardization
NCCoE National Cybersecurity Center of Excellence
NIST National Institute of Standards and Technology
NISTIR NIST Interagency or Internal Report
PQC Post-Quantum Cryptography
RFC Request for Comments
SP Special Publication
TLS Transport Layer Security

Project Description: Migration to Post-Quantum Cryptography 15