idnits 2.17.1 draft-kaimindermann-securecryptoconfig-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 31 instances of too long lines in the document, the longest one being 39 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 April 2021) is 1074 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2743' is defined on line 1463, but no explicit reference was found in the text == Unused Reference: 'RFC5116' is defined on line 1468, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 1472, but no explicit reference was found in the text == Unused Reference: 'RFC5698' is defined on line 1476, but no explicit reference was found in the text == Unused Reference: 'RFC6916' is defined on line 1481, but no explicit reference was found in the text == Unused Reference: 'RFC7696' is defined on line 1491, but no explicit reference was found in the text ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 cfrg K. Mindermann 3 Internet-Draft iC Consult GmbH 4 Intended status: Informational L. Teis 5 Expires: 21 October 2021 19 April 2021 7 Secure Crypto Config 8 draft-kaimindermann-securecryptoconfig-01 10 Abstract 12 Choosing secure cryptography algorithms and their corresponding 13 parameters is difficult. Also, current cryptography APIs cannot 14 change their default configuration which renders them inherently 15 insecure. The Secure Crypto Config provides a method that allows 16 cryptography libraries to change the default cryptography algorithms 17 over time and at the same time stay compatible with previous 18 cryptography operations. This is achieved by combining three things 19 standardized by the Secure Crypto Config: (1) A process that is 20 repeated every two years, where a new set of default configurations 21 for standardized cryptography primitives is published in a specific 22 format. (2) A Secure Crypto Config Interface that describes a common 23 API to use cryptography primitives in software (3) using COSE to 24 derive the parameters from output of cryptography primitives, 25 otherwise future changes of the default configuration would change 26 existing applications behavior. 28 Note to Readers 30 Comments are solicited and should be addressed to the GitHub 31 repository issue tracker (https://github.com/secureCryptoConfig/ 32 secureCryptoConfig) and/or the author(s) 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 21 October 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2.1. Conventions and Definitions . . . . . . . . . . . . . 5 70 1.2.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 71 1.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.3.1. Secure Crypto Config Use Cases . . . . . . . . . . . 5 73 1.3.2. Cryptography Use Cases . . . . . . . . . . . . . . . 6 74 2. Requirements and Assumptions . . . . . . . . . . . . . . . . 9 75 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 76 2.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12 77 3. Security Levels . . . . . . . . . . . . . . . . . . . . . . . 12 78 3.1. Security Level 1 - Low . . . . . . . . . . . . . . . . . 12 79 3.2. Security Level 2 . . . . . . . . . . . . . . . . . . . . 12 80 3.3. Security Level 3 . . . . . . . . . . . . . . . . . . . . 12 81 3.4. Security Level 4 . . . . . . . . . . . . . . . . . . . . 13 82 3.5. Security Level 5 - High . . . . . . . . . . . . . . . . . 13 83 3.6. Security Level Constraints . . . . . . . . . . . . . . . 13 84 3.6.1. Information classification . . . . . . . . . . . . . 13 85 3.6.2. Longevity . . . . . . . . . . . . . . . . . . . . . . 13 86 3.6.3. Constrained Devices . . . . . . . . . . . . . . . . . 14 87 3.6.4. n-Bit-Security . . . . . . . . . . . . . . . . . . . 14 88 3.6.5. Attacker Resources and Capabilities . . . . . . . . . 14 89 4. Consensus Finding Process and entities . . . . . . . . . . . 15 90 4.1. Consensus Finding . . . . . . . . . . . . . . . . . . . . 15 91 4.1.1. Regular Process . . . . . . . . . . . . . . . . . . . 15 92 4.1.2. Emergency Process . . . . . . . . . . . . . . . . . . 16 93 4.1.3. Requirements for Selection of Cryptography Algorithm 94 and Parameters . . . . . . . . . . . . . . . . . . . 17 95 4.2. Entities . . . . . . . . . . . . . . . . . . . . . . . . 17 97 5. Publication Format and Distribution . . . . . . . . . . . . . 17 98 5.1. Versioning . . . . . . . . . . . . . . . . . . . . . . . 18 99 5.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 5.3. Secure Crypto Config IANA Registry . . . . . . . . . . . 18 101 5.3.1. Example for Secure Crypto Config IANA Registry . . . 19 102 5.3.2. Utilized Algorithm Registries . . . . . . . . . . . . 19 103 5.4. Data Structures . . . . . . . . . . . . . . . . . . . . . 20 104 5.5. Human readable format . . . . . . . . . . . . . . . . . . 21 105 5.6. Official Secure Crypto Config Repository . . . . . . . . 21 106 5.6.1. Location of Secure Crypto Config Repository . . . . . 22 107 5.6.2. Format of Secure Crypto Config Repository . . . . . . 22 108 5.6.3. Integrity/Signing process . . . . . . . . . . . . . . 23 109 6. Secure Crypto Config Application Programming Interface 110 (API) . . . . . . . . . . . . . . . . . . . . . . . . . . 24 111 6.1. Semantic Versioning . . . . . . . . . . . . . . . . . . . 24 112 6.2. Deployment of (custom) Secure Crypto Config with 113 Interface . . . . . . . . . . . . . . . . . . . . . . . . 24 114 6.2.1. Delivery of Secure Crypto Config with Interface . . . 26 115 6.2.2. Using a custom Secure Crypto Config Repository . . . 26 116 6.2.3. Integrity Check . . . . . . . . . . . . . . . . . . . 26 117 6.2.4. Methods and Parameters . . . . . . . . . . . . . . . 27 118 6.2.5. Automatic Parameter Tuning . . . . . . . . . . . . . 27 119 6.2.6. Output of readable Secure Crypto Config . . . . . . . 28 120 6.3. TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 121 7. Cryptography Library Implementation Specification . . . . . . 29 122 8. Cryptography Algorithm Standards Recommendation . . . . . . . 29 123 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 124 9.1. Consensus Finding . . . . . . . . . . . . . . . . . . . . 29 125 9.2. Publication Format . . . . . . . . . . . . . . . . . . . 29 126 9.3. Cryptography library implementation . . . . . . . . . . . 29 127 9.4. General Security Considerations . . . . . . . . . . . . . 30 128 9.4.1. Special Use Cases and (Non-)Security Experts . . . . 30 129 9.5. Security of Cryptography primitives and 130 implementations . . . . . . . . . . . . . . . . . . . . . 30 131 9.5.1. Security Guarantees . . . . . . . . . . . . . . . . . 30 132 9.5.2. Threat Model / Adversaries . . . . . . . . . . . . . 30 133 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 134 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 135 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 136 11.2. Informative References . . . . . . . . . . . . . . . . . 32 137 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 32 138 A.1. JSON Secure Crypto Config . . . . . . . . . . . . . . . . 33 139 Appendix B. Example Java Interface using Secure Crypto Config . 33 140 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 143 1. Introduction 144 1.1. Motivation 146 Cryptography needs standardization to work across various domains and 147 to be interoperable between different implementations. One domain 148 that is not covered sufficiently by cryptography standards is the 149 selection and maintenance of cryptography algorithms and their 150 parameters. Choosing an appropriate and secure cryptography 151 algorithm alone is difficult. Yet, even more difficult is the choice 152 of the required and matching parameters for that algorithm (e.g. 153 Argon2 has 10 input parameters (https://tools.ietf.org/html/draft- 154 irtf-cfrg-argon2-10#section-3.1)). After the choice has been made, 155 all involved parties need to use exactly this configuration. There 156 is no specification on how the chosen cryptography configuration 157 should be stored, distributed and retrieved. Furthermore, supporting 158 more than one configuration or being able to add future 159 configurations is not defined. That reduces software compatibility 160 and increases maintenance efforts. 162 Cryptography algorithm implementations, regardless of for one 163 algorithm or multiple ones, offer some kind of Application 164 Programming Interface for developers to use the algorithms. Yet, in 165 many cases these interfaces provide no abstraction from the 166 underlying algorithm but expose much of the internal states and 167 parameters. Also the more abstracting interfaces, usually found in 168 the standard libraries of programming languages, require users to 169 have much cryptography experience to use them correctly and securely. 170 Moreover, even approaches that tried to increase usability by 171 providing defaults, these defaults become quickly outdated but cannot 172 be changed in the interface anymore as applications using these 173 defaults rely on that functionality. 175 It sounds a lot like a problem for software engineering and not for 176 cryptography standardization. But software engineering alone cannot 177 provide a programming interface for cryptography algorithms that also 178 works for future algorithms and parameters and at the same time is 179 able to change the default implementation easily. Both the choice of 180 the algorithm/parameters and the default behavior must be automated 181 and standardized to remove this burden from developers and to make 182 cryptography work by default and in the intended secure way. 184 The Secure Crypto Config approaches this problem first by providing a 185 regularly updated list of secure cryptography algorithms and 186 corresponding parameters for common cryptography use cases. Second, 187 it provides a standardized Application Programming Interface which 188 provides the Secure Crypto Config in a misuse resistant way to 189 developers. Third, it leverages an already standardized format 190 ([RFC8152]) to store the used parameters alongside the results of 191 cryptography operations. That ensures that future implementations 192 can change their default cryptography algorithms but still parse the 193 used configuration from existing data and perform the required 194 cryptography operations on it. 196 Each of these approaches could be used on its own. Yet, the 197 combination of them allows software to be easier to maintain, more 198 compatible with other cryptography implementations and to future 199 security developments, and most importantly more secure. 201 The Secure Crypto Config makes common assumptions that are not true 202 for all possible scenarios. In cases where security experts are 203 indeed involved and more implementation choices have to be made, the 204 Secure Crypto Config still allows the usage of predefined or even 205 custom cryptography algorithms and parameters. 207 1.2. Terminology 209 1.2.1. Conventions and Definitions 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 213 "OPTIONAL" in this document are to be interpreted as described in BCP 214 14 [RFC2119] [RFC8174] when, and only when, they appear in all 215 capitals, as shown here. 217 1.2.2. Terms 219 The terms "API", "attack", "authenticity", "availability", "break", 220 "brute force", "cipher", "ciphertext", "classified", "classification 221 level", "confidentiality", "cryptographic hash", "encrypt", 222 "encryption", "initialization vector (IV)", "integrity", "key", 223 "mode", "nonce", "password", "plain text", "plaintext", "protocol", 224 "security", "security level", "threat", "trust", in this document are 225 to be interpreted as described in [RFC4949]. 227 The term "hash" is used as a synonym for "cryptographic hash". 229 The term "cryptographic primitive" is used in this document to 230 describe a generic building block used in the field of cryptography 231 e.g. Hashing, symmetric encryption. 233 1.3. Use Cases 235 1.3.1. Secure Crypto Config Use Cases 237 The Secure Crypto Config has the following main use cases: 239 * Centralized and regularly updated single source of truth for 240 secure algorithms and their parameters for most common 241 cryptography primitives and use cases. 243 * Both machine and human readable format to specify the above 244 mentioned cryptography algorithm/parameter configuration. The 245 format is also extensible to allow others (e.g. governmental or 246 commercial organizations) to define their own set of cryptography 247 configurations. 249 * Standardized cryptography API that not uses the Secure Crypto 250 Config for the selection of the most recent cryptography 251 configurations but also uses a standardized cryptography operation 252 output format to enclose the chosen parameters. 254 1.3.2. Cryptography Use Cases 256 The Secure Crypto Config covers cryptography algorithm and parameter 257 configurations for widely used cryptography use cases defined in the 258 following sections. 260 1.3.2.1. Symmetric Encryption 262 Symmetric Encryption is an important cryptographic primitive 263 especially as it is usually multiple magnitudes faster both for 264 encryption and decryption than asymmetric cryptography. Yet, the 265 secret has to be shared with all participants. 267 The only expected input parameters by cryptography users: 269 * plaintext 271 * secret key 273 Expected output: ciphertext. 275 Additional Parameters often required in practice: 277 * Algorithm 279 * Block-Mode 281 * IV 283 * Padding-Mode 285 * Authentication Tag size 286 Possible secure usage: 288 * A256GCM;3;AES-GCM mode w/ 256-bit key, 128-bit tag 290 * ChaCha20/Poly1305;24;ChaCha20/Poly1305 w/ 256-bit key, 128-bit tag 292 1.3.2.2. Asymmetric Encryption 294 Besides symmetric encryption is asymmetric encryption another 295 important cryptographic primitive to considered. 297 The only expected input parameters for encryption: 299 * plaintext 301 * public key 303 Expected output: ciphertext. 305 The only expected input parameters for decryption: 307 * ciphertext 309 * private key 311 Possible secure usage: 313 * RSAES-OAEP w/ SHA-512,-42,RSAES-OAEP w/ SHA-512 315 1.3.2.3. Hashing 317 Hashing is an important cryptographic primitive and is often needed 318 as a part of many other cryptographic use cases e.g. password 319 derivation. 321 The only expected input parameters by cryptography users: 323 * plaintext 325 Expected output: hash. 327 Possible secure usage: 329 * SHA-512 (TEMPORARY - registered 2019-08-13, expires 330 2020-08-13);-44;SHA-2 512-bit Hash 332 * SHAKE256 (TEMPORARY - registered 2019-08-13, expires 333 2020-08-13);-45;256-bit SHAKE 335 1.3.2.4. Password Hashing 337 The secure storage of passwords requires hashing. Yet, password 338 hashing requires that the hashing can not be performed very fast to 339 prevent attackers from guessing/brute-forcing passwords from leaks or 340 against the live system. E.g. it is totally fine for users if the 341 login takes 0.1 seconds instead of microseconds. This results in 342 special families of hash algorithms that offer additional tuning 343 parameters. 345 The only expected input parameters by cryptography users: 347 * plaintext 349 * hash-algorithm 351 Expected output: hash. 353 Possible secure usage: 355 * Argon2id (https://tools.ietf.org/html/draft-irtf-cfrg-argon2-13) 357 1.3.2.5. Key Generation 359 * [ ] TODO should key generation be considered? (Symmetric/ 360 Asymmetric) 362 A key is necessary for many cryptographic use cases e.g. symmetric 363 and asymmetric encryption. Therefore, key generation is an important 364 part while implementing cryptographic code. 366 The only expected input is the intended use case. 368 Expected output: key. 370 Possible secure generation: 372 * Use of CSPRNG 374 * Keys derived via derivation function from passwords/other keys 376 1.3.2.6. Digital Signatures 378 Signing is an important and often needed cryptographic use case. It 379 is based on the principle of asymmetrical encryption. 381 The only expected input parameters for signing: 383 * plaintext 385 * private key 387 Expected output: signature. 389 The only expected input parameters for verifying the signature: 391 * signature 393 * public key 395 Expected output: valid/not-valid. 397 Possible secure usage: 399 * ECDSA 401 * ES512;-36;ECDSA w/ SHA-512 403 2. Requirements and Assumptions 405 2.1. Requirements 407 In the following, all requirements are listed that regard the Secure 408 Crypto Config or the Secure Crypto Config Interface. 410 * Security Level Requirements: The Secure Crypto Config should 411 define different security levels. E.g. information has different 412 classification levels and longevity. Additionally, cryptography 413 operations could not or much slower perform on constrained 414 devices, which should also be handled with the security levels. 415 For each security level, the consensus finding process and 416 entities shall publish a distinct secure crypto config. 418 * Consensus Finding Process and entities: 420 - The Secure Crypto Config must be renewed regularly. 422 - The Secure Crypto Config must be renewable on-demand. 424 - There must be a guideline on which entities must agree to 425 publish a new Secure Crypto Config. 427 - There must be a guideline on which entities may participate in 428 the consensus finding process and how they may do so. 430 - There must be a guideline on how to determine broad 431 availability of both cryptography algorithms and chosen 432 parameters. 434 * Publication Format and Distribution Requirements: 436 - General: 438 o The Secure Crypto Config must be easily publishable by the 439 committee. 441 o Standardized unique and distinct names for (1) cryptography 442 algorithms (2) their parameters and (3) the combination of 443 the algorithm with set parameters. Otherwise, ambiguity 444 would make it harder for developers and cryptography 445 implementors to make correct and secure choices. 447 o There must be a versioning that allows to distinguish 448 between Secure Crypto Configurations and what is the latest 449 Secure Crypto Config. 451 o There must be a deprecation process that ensures usage of 452 outdated/insecure Crypto Configurations cases. 454 o There must be an official source where this Secure Crypto 455 Config is maintained and can be obtained from (e.g. via the 456 WWW). 458 o The official source format of the Secure Crypto Config must 459 be cryptographically protected to ensure its integrity and 460 authenticity. 462 o Other published formats derived from the source format (e.g. 463 for human readability on a webpage) do not have to be 464 cryptographically protected but should be generated 465 automatically from the source format. 467 o The official source should also provide information about 468 the Secure Crypto Config Interface that should be utilized 469 for the application of the Secure Crypto Config. 471 o The Secure Crypto Config must specify how it can be extended 472 (e.g. more security levels) and how derivatives work. 474 - Human readable 476 o The Secure Crypto Config must have a human readable format. 478 o The Secure Crypto Config must allow non-experts to find 479 secure cryptography algorithms and appropriate parameters 480 for common cryptography use cases. 482 o The Secure Crypto Config human readable publication format 483 should only use easy to comprehend data structures like two- 484 dimensional tables. 486 - Machine readable 488 o Cryptography libraries, regardless of the programming 489 language, should be able to directly map (without extensive 490 parsing) the Secure Crypto Config to their implementation 492 o Must be easy to verify which Secure Crypto Config is used / 493 was used (e.g. in Continuous Integration platforms) 495 o Must be easy to verify the authenticity of the Secure Crypto 496 Config (e.g. is this really what the CFRG has published?) 498 * Cryptography library integration requirements: 500 - Easy to integrate by cryptography libraries 502 - Experts should still be able to use/access the unaltered output 503 of cryptographic primitives 505 - Recommendation what should be the default Secure Crypto Config 506 for a cryptography library (e.g. should it be the one with the 507 highest security level or _only_ a weaker one?) 509 - Recommendation of what should a cryptography library do if it 510 can not support the parameters specified in the latest Secure 511 Crypto Config. (E.g. key size for RSA would be n*2 and the 512 library supports only n) 514 - Recommendation on how a cryptography library should integrate 515 the Secure Crypto Config so that it is up to date as soon as 516 possible after a new Secure Crypto Config has been published 518 * General Requirements: 520 - Interoperability with other standards/formats (e.g. [RFC8152]) 522 - The Secure Crypto Config should cover most common cryptography 523 primitives and their currently broadly available and secure 524 algorithms. 526 - The Secure Crypto Config should be protected against attackers 527 as defined in Section 3.6.5 529 - The Secure Crypto Config should prevent non-experts to 530 configure cryptography primitives in an insecure way. 532 - The Secure Crypto Config should not prevent experts from using 533 or changing all parameters of cryptography primitives provided 534 by a cryptography library/API. 536 2.2. Assumptions 538 The Secure Crypto Config assumes that both the proposed algorithms 539 and the implementations (cryptography libraries) for the cryptography 540 primitives are secure. This also means that side-channel attacks are 541 not considered explicitly. It is also assumed that programmers, 542 software engineers and other humans are going to use cryptography. 543 They are going to make implementation choices without being able to 544 consult cryptography and security experts and without understanding 545 cryptography related documentation fully. This also means that it is 546 not considered best practice to assume or propose that only 547 cryptography experts (should) use cryptography (primitives/ 548 libraries). 550 3. Security Levels 552 The Secure Crypto Config must be able to provide a secure parameter 553 set for different security levels. These security levels depend on 554 the following security constraints: *Information classification 555 (Secret, Confidential), Longevity (less than one day, more than a 556 day), Constrained devices (constrained, not constrained)*. They are 557 defined in Section 3.6 below. The Secure Crypto Config provides 5 558 common security levels for which official algorithm/parameter choices 559 are published. 561 3.1. Security Level 1 - Low 563 Confidential information, regardless of the other two constraints 565 3.2. Security Level 2 567 Secret information, less than one day longevity, constrained device 569 3.3. Security Level 3 571 Secret information, less than one day longevity, non-constrained 572 device 574 3.4. Security Level 4 576 Secret information, more than a day longevity, constrained device 578 3.5. Security Level 5 - High 580 Secret information, more than a day longevity, non-constrained device 582 3.6. Security Level Constraints 584 3.6.1. Information classification 586 Information classification within this document is about the 587 confidentiality of the information. Not all information is equally 588 confidential, e.g. it can be classified into different classes of 589 information. For governmental institutions usually three classes are 590 used: Confidential, Secret, or Top Secret. The Secure Crypto Config 591 considers only *Confidential* and *Secret* for its standardized 592 security levels. Further levels with other classifications can be 593 added by other organizations. Additionally, in common (non- 594 governmental) use cases data is not labeled with an information 595 class. Hence, often only one class is chosen for the cryptography 596 processing of all data. 598 The Secure Crypto Config does not endorse a definition of the 599 information classes, yet *Secret* information is to be considered to 600 have higher confidentiality requirements than *Confidential* 601 information. 603 3.6.2. Longevity 605 The time how long information has to be kept confidential can 606 influence cryptography parameters a lot. Usually what you talked 607 about with your friends should be kept confidential for a lifetime. 608 Yet, a public trade transaction must only be confidential until the 609 trade was executed which can happen in milliseconds. It directly 610 influences a very important attacker resource: The time an attacker 611 has to try to gain access to the confidential information. The 612 Secure Crypto Config considers only two ranges of longevity for its 613 standardized security levels: *short longevity* of less than one day 614 and *long longevity* of a day or more than a day. Further levels 615 with other longevity levels can be added by other organizations. 617 3.6.3. Constrained Devices 619 For cryptography often complex computations have to be executed. 620 Yet, not all environments have the same hardware resources available. 621 E.g. it is not always the case that the used processors have 622 dedicated cryptography hardware or even specialized execution units 623 or instruction sets like [AESNI]. Detailed discussion and 624 definitions can be found in [RFC7228]. Yet, their definitions are 625 too concrete to be used in the Secure Crypto Config's standardized 626 security levels. Therefore, the Secure Crypto Config defines 627 constraint devices not based on concrete processing power (e.g. 100k 628 instructions per second): 630 A device is constrained when it has *multiple orders of magnitudes* 631 fewer resources than a current (not a new one, but broadly in use at 632 the time of publication of a Secure Crypto Config!) standard personal 633 computer. 635 For example, if a current standard personal computer can encrypt with 636 1 GiB/s, a constrained device would be all devices that can only 637 perform the same cryptography operation with less than 10 MiB/s. 638 Resources can be everything important for cryptography like dedicated 639 cryptography hardware, instruction sets, memory, power consumption, 640 storage space, communication bandwidth, latency etc. The Secure 641 Crypto Config considers only *constrained* and *non-constrained* for 642 its standardized security levels. Further levels with other 643 constrained resource definitions can be added by other organizations. 645 3.6.4. n-Bit-Security 647 n-Bit Security Level: 649 A cryptographic mechanism achieves a security level of n bits if 650 costs which are equivalent to 2^n calculations of the encryption 651 function of an efficient block cipher (e.g. AES) are tied to each 652 attack against the mechanism which breaks the security objective 653 of the mechanism with a high probability of success. BSI 655 3.6.5. Attacker Resources and Capabilities 657 The Secure Crypto Config considers only the following same attacker 658 resources and capabilities for all standardized security levels: 660 * The attacker knows all used algorithms and parameters except 661 secrets according to Kerckhoffs's principle. 663 * The attacker has access to the system used for cryptography 664 operations and can utilize its cryptography operations apart from 665 obtaining secrets. 667 * The attacker can utilize very high-performance computing resources 668 such as supercomputers and distributed computing (e.g. this 669 includes very high memory, storage, processing and networking 670 performance) 672 Further security levels with other attacker definitions can be added 673 by other organizations. 675 4. Consensus Finding Process and entities 677 To provide a Secure Crypto Config, it is necessary to agree upon a 678 secure and appropriate cryptographic parameter set for each security 679 level (see Section 3). This must happen in a common consensus 680 finding process which takes place during regular intervals. The 681 consensus finding process is based on the established RFC process 682 during which the Secure Crypto Config Working Group decides in 683 cooperation with the Crypto Forum Research Group (CFRG) and other 684 institutions like the Bundesamt fuer Sicherheit in der 685 Informationstechnik (BSI) or the National Institute of Standards and 686 Technology (NIST) for a set of secure parameters. After the 687 successful decision, the agreed on parameters can be added in the 688 defined publication data structures (see Section 5.4) and provided on 689 the repository platform. 691 4.1. Consensus Finding 693 Consensus must be found two years after the last consensus was found. 694 This ensures that there is a new Secure Crypto Config every two 695 years, even if the configuration itself has not changed. There is a 696 regular process and an emergency process to release Secure Crypto 697 Configurations. 699 4.1.1. Regular Process 701 The process has three phases that MUST be finalized within 2 years: 703 * (1) One year *Proposal phase* during which all participating 704 entities must propose at least two cryptography algorithms and 705 parameters per cryptography use case per security level. 707 * (2) Six months *Consensus finding phase* during which all 708 participating entities must agree on a common Secure Crypto 709 Config. 711 * (3) Six months *Publication phase* ensures the publication of the 712 final Secure Crypto Config AND allows the Secure Crypto Config 713 Interface and other cryptography implementations to integrate the 714 necessary changes. 716 During the Proposal phase the proposed algorithms and all necessary 717 parameters should be submitted in table form for each security level 718 and defined cryptographic use case as proposed. This table format is 719 simply structured and is easy to read by humans as the Consensus 720 finding phase can only be done manually. It is important that the 721 parameters for each cryptographic use case depending on its security 722 level can be found easily by the participants of the consensus 723 finding process such that it is possible to get to an agreement 724 faster. 726 4.1.2. Emergency Process 728 * [ ] TODO How can the Working Group alter the Secure Crypto Config 729 IANA registry / or use the RFC Errata process? 731 In cases when a regularly still valid Secure Crypto Config would 732 become insecure regarding either a proposed algorithm or a proposed 733 parameter choice it must be revised with the following process: 735 1. Determine the insecure configuration. 737 2. Remove the insecure configuration. 739 3. Publish the revised Secure Crypto Config with a new patch 740 version. 742 4. Mark the old (unrevised) Secure Crypto Config as deprecated. 744 Examples for emergency cases are drastically better brute force 745 algorithms or brute force performance (e.g. quantum computers/ 746 algorithms), drastically discovered flaws in proposed algorithms and 747 their configurations. 749 An applied emergency process results in the problem that currently 750 used Secure Crypto Config Interface versions are no longer up-to- 751 date, because they are still supporting the no longer secure 752 algorithms. Therefore, the corresponding algorithms need to be 753 marked as insecure. If e.g. a proposed algorithm gets insecure this 754 can be marked inside the corresponding Secure Crypto Config IANA 755 registry entry as no longer proposed to make the users aware of its 756 insecurity. The Working Group itself can decide when to alter the 757 Secure Crypto Config IANA registry. 759 4.1.3. Requirements for Selection of Cryptography Algorithm and 760 Parameters 762 The Secure Crypto Config MUST only propose cryptography algorithms 763 and parameters that fulfill the following requirements: 765 * Cryptography algorithms and parameters have stable implementations 766 in at least two different programming languages. 768 * Cryptography algorithms and parameters have a defined standard to 769 store the algorithm and parameter identification alongside the 770 result (e.g. like [RFC8152]). This is required to ensure 771 cryptography operation results can be processed even if the 772 default parameters have been changed or the information has been 773 processed with a previous version of the Secure Crypto Config. 775 * Cryptography algorithms that support parametrization to adapt to 776 increased brute force performance and to allow longevity of the 777 algorithm especially for hardware optimized implementations. 779 The Secure Crypto Config SHOULD only propose cryptography algorithms 780 and parameters that fulfill the following requirements: 782 * Cryptography algorithms and parameters are defined in a globally 783 accepted standard which was suspect to a standardization process. 785 * Cryptography algorithms and parameters are licensed under a 786 license that allows free distribution. 788 4.2. Entities 790 Entities that participate in the proposal phase SHOULD have 791 significant cryptography expertise. Entities that participate in the 792 consensus finding phase MUST have significant cryptography expertise. 793 Cryptographic expertise is defined by the Secure Crypto Config 794 Working Group or the CFRG. 796 5. Publication Format and Distribution 798 In general the Secure Crypto Config is published via JSON [RFC8259] 799 files in an official repository. The Secure Crypto Config also 800 utilizes IANA registries, see {#IANA}. 802 5.1. Versioning 804 The Secure Crypto Config is regularly published in a specific year. 805 Therefore, the Secure Crypto Config format MUST use the following 806 versioning format: *YYYY-PATCH*. YYYY is a positive integer 807 describing the year (using the Gregorian calendar, and considering 808 the year that has not ended in all time zones, cf. Anywhere on Earth 809 Time) this specific Secure Crypto Config was published. PATCH is a 810 positive integer starting at 0 and only increasing for emergency 811 releases. 813 5.2. Naming 815 The naming of official released SCCs must follow this format: 817 "SCC_**Version**_LEVEL_**Security Level Number**" 819 E.g. a Secure Crypto Config for Security Level 5 release in 2020 the 820 first time (so no patch version) would be named: 821 "SCC_2020-00_LEVEL_5" 823 The naming of files is not regulated, only the content is standard 824 relevant. Yet, the Secure Crypto Config Files should use the 825 mentioned naming convention as well as adding a suffix (file type 826 ending) ".json" to prevent ambiguity and remove implementation 827 choices: 829 "SCC_**Version**_LEVEL_**Security Level Number.json**" 831 5.3. Secure Crypto Config IANA Registry 833 *NOT NEEDED?, as the Secure Crypto Config uses other registries, e.g. 834 COSE. No final decision, yet.* 836 * [ ] TODO Naming convention. Specification depending on crypto use 837 case? 839 * [ ] TODO dash character "-" not possible in enum! 841 The Secure Crypto Config requires one IANA Registry with the 842 following columns: 844 * Secure Crypto Config release version: *YYYY-PATCH* 846 * Distinct *Algorithm-Parameter-Identifier* that uniquely identifies 847 a cryptography algorithm and the parameters 849 * Distinct and *constantly available reference* where all parameters 850 are unambiguously defined 852 * (Optional) Short description of the parameters 854 Algorithm-Parameter-Identifier: MUST only consist of uppercase 855 alphanumeric characters and underscores. Depending on the use case 856 the Algorithm Parameter Identifier can be constructed differently. 857 We propose the following schemes: 859 * For symmetric encryption the name should look like 860 *AlgorithmName_Mode_Padding_KeyLength_TagLength_NonceLength* (e.g. 861 AES_GCM_NoPadding_256_128_128). 863 * For hashing as *HashAlgorithmName_KeyLength* (e.g. SHA3_256). 865 * For asymmetric encryption and digital signatures 866 *AlgorithmName_AuxiliaryAlgorithm_Padding_KeyLength* (e.g. 867 RSA_ECB_OAEP_4096). 869 5.3.1. Example for Secure Crypto Config IANA Registry 871 +=========+=====================+===========+==================+ 872 | SCC | AlgParam Identifier | Reference | Description | 873 | Version | | | | 874 +=========+=====================+===========+==================+ 875 | 2020-01 | AES_GCM_256_128_128 | [RFC8152] | AES 256 with GCM | 876 | | | | and 128 bit tag | 877 | | | | and random nonce | 878 +---------+---------------------+-----------+------------------+ 880 Table 1 882 5.3.2. Utilized Algorithm Registries 884 The Secure Crypto Config can only propose cryptography algorithms and 885 parameters that have been standardized. Therefore, it refers to the 886 following IANA registries: 888 * CBOR Object Signing and Encryption (COSE) 889 (https://www.iana.org/assignments/cose/cose.xhtml) 891 * AEAD Algorithms (https://www.iana.org/assignments/aead-parameters/ 892 aead-parameters.xhtml) 894 * Named Information Hash Registry (https://www.iana.org/assignments/ 895 named-information/named-information.xhtml#hash-alg) 897 Used registries must define all required parameters for an algorithm 898 to implement it without ambiguity. E.g. implementations must not be 899 able to choose other parameter values for these predefined 900 cryptography algorithm and parameter combinations. 902 5.4. Data Structures 904 For each defined security level, a distinct JSON file must be 905 provided. These files must adhere to the common schema and shown in 906 Figure 1 and described in the following. 908 { 909 "PolicyName": "SCC_SecurityLevel_Security Level Number", 910 "Publisher": [ 911 { 912 "name": "Publisher name", 913 "URL": "URL corresponding to publisher" 914 } 915 ], 916 "SecurityLevel" : "Security Level Number", 917 "Version": "YYYY-Patch", 918 "PolicyIssueDate": "YYYY-MM-DD", 919 "Expiry": "YYYY-MM-DD", 920 "Usage": { 921 "SymmetricEncryption": [ 922 "Algorithm 1", 923 "Algorithm 2" 924 ], 925 "AsymmetricEncryption": [ 926 "Algorithm 1", 927 "Algorithm 2" 928 ], 929 "Hashing": [ 930 "Algorithm 1", 931 "Algorithm 2" 932 ], 933 "PasswordHashing": [ 934 "Algorithm 1", 935 "Algorithm 2" 936 ], 937 "Signing": [ 938 "Algorithm 1", 939 "Algorithm 2" 940 ] 941 } 942 } 944 Figure 1: General JSON format 946 * SecurityLevel: Contains the number of the corresponding Security 947 Level of the Secure Crypto Config 949 * PolicyName: Contains the name of the corresponding Secure Crypto 950 Config according to the naming schema defined in Section 5.2 952 * Publisher: Contains an array of all parties that participated in 953 the consensus finding process 955 - name: Name of the participating party 957 - URL: Put in the official URL of the named publisher 959 * Version: Contains version in the format defined in Section 5.1 961 * PolicyIssueDate: Date at which the Secure Crypto Config was 962 published in the format: YYYY-MM-DD 964 * Expiry: Date at which the Secure Crypto Config expires in the 965 format: YYYY-MM-DD 967 * Usage: Contains an array of objects for each cryptographic use 968 case defined in Section 1.3.2. 970 - For each cryptographic use case, at least two agreed upon 971 algorithms (see Section 4) with necessary parameters are 972 included. Each of these algorithms with its parameters is 973 specified with its unique identification name defined in a IANA 974 registry used by the Secure Crypto Config. 976 This format allows custom algorithm/parameter definitions both by 977 overwriting use cases completely or by adding only specific algorithm 978 identifiers via custom configurations. 980 5.5. Human readable format 982 The Secure Crypto Config can not only be used automatically but also 983 provide the cryptography algorithms and parameters for humans. The 984 human readable format must be derived from the JSON files both to 985 protect from copy-paste-errors and to validate the cryptographic 986 signatures. Yet, the human readable format or publication page 987 itself must not be cryptographically protected. There should be one 988 accessible resource, e.g. a webpage, where the source format (JSON 989 files) are automatically used for displaying them in appropriate ways 990 (e.g. tables with various sorting and searching options). 992 5.6. Official Secure Crypto Config Repository 993 5.6.1. Location of Secure Crypto Config Repository 995 The needed Secure Crypto Config files should be published at an 996 official GitHub repository. There, all current versions will be 997 provided during the interval of the Publication phase (see 998 Section 4.1.1). Additionally, all previously published files are 999 still stored at this location even if new versions are published. 1001 5.6.2. Format of Secure Crypto Config Repository 1003 scc-repo 1004 - configs 1005 - 2020 1006 - 00 1007 - SCC_2020-00_LEVEL_1.json 1008 - SCC_2020-00_LEVEL_1.signature1 1009 - SCC_2020-00_LEVEL_1.signature2 1010 - SCC_2020-00_LEVEL_2.json 1011 - SCC_2020-00_LEVEL_2.signature1 1012 - SCC_2020-00_LEVEL_2.signature2 1013 - SCC_2020-00_LEVEL_3.json 1014 - SCC_2020-00_LEVEL_3.signature1 1015 - SCC_2020-00_LEVEL_3.signature2 1016 - SCC_2020-00_LEVEL_4.json 1017 - SCC_2020-00_LEVEL_4.signature1 1018 - SCC_2020-00_LEVEL_4.signature2 1019 - SCC_2020-00_LEVEL_5.json 1020 - SCC_2020-00_LEVEL_5.signature1 1021 - SCC_2020-00_LEVEL_5.signature2 1022 - 01 1023 - 02 1024 - 2021 1025 - 2022 1026 - 2023 1027 - 2024 1029 Figure 2: Example for Secure Crypto Config Repository content 1031 scc-repo 1032 - configs 1033 - a 1034 - b 1035 - 0c1 1036 - ReallySecure 1037 - 0x1111 1038 - SCC_2020-00_LEVEL_1.json 1039 - SCC_2020-00_LEVEL_1.signature1 1040 - SCC_2020-00_LEVEL_1.signature2 1041 - SCC_2020-00_LEVEL_2.json 1042 - SCC_2020-00_LEVEL_2.signature1 1043 - SCC_2020-00_LEVEL_2.signature2 1044 - SCC_2020-00_LEVEL_3.json 1045 - SCC_2020-00_LEVEL_3.signature1 1046 - SCC_2020-00_LEVEL_3.signature2 1047 - SCC_2020-00_LEVEL_4.json 1048 - SCC_2020-00_LEVEL_4.signature1 1049 - SCC_2020-00_LEVEL_4.signature2 1050 - SCC_2020-00_LEVEL_5.json 1051 - SCC_2020-00_LEVEL_5.signature1 1052 - SCC_2020-00_LEVEL_5.signature2 1053 - asdf 1054 - afd 1055 - af 1057 Figure 3: Example for Secure Crypto Config Repository content 1058 with custom naming scheme 1060 The Secure Crypto Config configuration files are expected to be in 1061 any folder hierarchy below the folder "configs"-folder. Each JSON 1062 file should be accompanied by corresponding signature files that have 1063 the same filename without extension as the JSON file, suffixed by 1064 "-signatureX" where "X" is a counter starting at 1. 1066 5.6.3. Integrity/Signing process 1068 * [ ] TODO what kind of signing process should be used? 1070 - [ ] GPG? 1072 - [ ] openssl? 1074 - [ ] Git GPG signed commits? 1076 - [ ] Use an SCC recommended signing algorithm/format 1078 * [ ] Can two signatures be put in one signature file? Should they 1079 be put in the same file? 1081 * [ ] Public Key distribution?! (In GitHub repo?) 1083 Each JSON file should be accompanied by at least two signatures. 1084 Both signatures are stored in different files on the same level as 1085 their corresponding Secure Crypto Config file to reduce the parsing 1086 effort. The signatures should be generated by entities defined by 1087 the Secure Crypto Config Working Group. They are responsible to 1088 publish and renew the used public keys. For signing of the 1089 corresponding Secure Crypto Config JSON files _openssl_ could be 1090 used. The public keys needed for validation are published in the 1091 official repository of the Secure Crypto Config. 1093 6. Secure Crypto Config Application Programming Interface (API) 1095 This section describes the application programming interface (API) 1096 that provides the Secure Crypto Config. The Secure Crypto Config 1097 Interface is generic and describes the API that should be used by 1098 each programming language. 1100 6.1. Semantic Versioning 1102 The implementation of the Secure Crypto Config Interface MUST follow 1103 Semantic Versioning (https://semver.org/), which specifies a version 1104 format of *X.Y.Z* (Major.Minor.Patch) and semantics when to increase 1105 which version part. It would be beneficial if the release of a new 1106 Interface version gets synchronized with the publication of a new 1107 Secure Crypto Config. It should be possible to support the newly 1108 defined parameters of Secure Crypto Config in the interface as soon 1109 as possible. 1111 6.2. Deployment of (custom) Secure Crypto Config with Interface 1113 There are two different possibilities to work with the Secure Crypto 1114 Config: - The preferred option is to use the Secure Crypto Configs 1115 that will be delivered within the Interface. In each new Interface 1116 version the current Secure Crypto Configs will be added such that 1117 always the latest Secure Crypto Configs at the time of the Interface 1118 release will be supported. Previous Secure Crypto Configs will 1119 remain inside the Interface such that also older ones can still be 1120 used. - Another option is to define a specific path to your own/ 1121 derived versions of the Secure Crypto Configs with the same structure 1122 of the files as described in Section 5.4 but with other values than 1123 in the official ones. 1125 The Interface will process the Secure Crypto Configs as follows: 1127 1. Check if the path to the Secure Crypto Configs is a valid one. 1129 2. Check if the "configs" folder exists. 1131 3. For each folder following "configs" in the hierarchy look inside 1132 that folder and check the existence of JSON files that need to be 1133 considered. This check will happen recursively for all folders 1134 inside the hierarchy. 1136 4. For every JSON file found, look if there exists a signature. If 1137 one is given, check if the signature is valid for the 1138 corresponding file. 1140 5. Every file with a valid signature will be parsed and further 1141 processed. 1143 The parsing of each valid JSON file must be done as follows: 1145 1. Read out all information of all JSON files that need to be 1146 considered. The information of each file is stored in a 1147 corresponding object. With this procedure all JSON files need to 1148 be read only once which will contribute to the performance. 1150 2. Parsing of security level: Check if it is a positive integer. 1151 All files not containing an (positive) integer number as security 1152 level value will be discarded. 1154 3. Parsing of algorithm identifiers: Only the algorithm identifiers 1155 that are supported by the Interface will be considered and stored 1156 inside the corresponding object. The supported algorithms are 1157 specified inside the interface (e.g. with an enmum). 1159 4. Parsing of the version of all files: All files with values in the 1160 wrong format (see Section 5.1) will be excluded from further 1161 processing. Find the latest (according to version) Secure Crypto 1162 Config file with the highest appearing security level (determined 1163 in previous step). The path to this file will be used as default 1164 path used for each cryptographic use case if nothing else is 1165 specified by the user. If two or more files with identical 1166 levels and version number are found, only the first one will be 1167 used, others are discarded. 1169 5. The unique algorithm identifiers for the execution of a specific 1170 cryptographic use case will be fetched from the corresponding 1171 object (representing the JSON file determined beforehand) at the 1172 time the users invoke a method for a specific cryptographic use 1173 case. The Interface will also provide a possibility to choose a 1174 specific algorithm (out of the supported ones) for executing the 1175 desired use case. In this case the specified algorithm is used. 1176 The identifiers will be compared with the supported ones in order 1177 of their occurrence inside the file. If one matching identifier 1178 is found it will be used for execution. If it is not a matching 1179 one the value will be skipped and the next one will be compared. 1180 If none of the algorithms inside the selected Secure Crypto 1181 Config can be found an error will occur. 1183 6.2.1. Delivery of Secure Crypto Config with Interface 1185 Each Secure Crypto Config Interface must be published in such a way 1186 that it uses (a copy of) the recent Secure Crypto Config repository. 1188 The Secure Crypto Config will be stored inside the subfolder "scc- 1189 configs" which should be located in the Interface "src"-folder if 1190 existent. The structure of the "scc-configs" folder will be the same 1191 as in the described hierarchy of the GitHub repository. In any new 1192 version of the Interface the latest published Secure Crypto Config 1193 and its signatures must be used. 1195 If new Secure Crypto Configs will be published for which no published 1196 version of the Interface is available, the custom repository approach 1197 can be used as described in the following. 1199 6.2.2. Using a custom Secure Crypto Config Repository 1201 It is also possible to use a different path to the Secure Crypto 1202 Configs. As also derived versions of the Secure Crypto Config for 1203 specific needs should be supported it will also be feasible to define 1204 a path to own or derived files that differentiate from the default 1205 "src/scc-configs/configs" folder. In this case, a method for setting 1206 and using a specific path must be provided by the Interface. 1208 6.2.3. Integrity Check 1210 * [ ] TODO which public keys should be used? (See above Integrity/ 1211 Signing process Public Key distribution?!) 1213 The check for valid signature of the Secure Crypto Configs is always 1214 made before every actual usage of the Interface functionalities. In 1215 this way, it is possible to guarantee that the entity using the 1216 Interface only works with valid Secure Crypto Configs and circumvents 1217 the risk of forged file contents. The public key needed for validity 1218 can be found in the official GitHub repository. If own derived 1219 Secure Crypto Configs are created than it can be possible that no 1220 validation process is needed for these files. 1222 6.2.4. Methods and Parameters 1224 Intended methods and parameters included in the Java interface are 1225 described in Figure 5. 1227 6.2.4.1. Supported Algorithm Parameter Types 1229 * [ ] TODO What is with parameters that have to be chosen during 1230 runtime? (e.g. the length of the nonce can be specified but not 1231 its content?) Maybe refer to how the PHC String Format 1232 (https://GitHub.com/P-H-C/phc-string-format/blob/master/phc-sf- 1233 spec.md) describes how parameters must be defined and only allow 1234 constants and csprng generated content? 1236 Cryptography algorithms require different parameters. The Secure 1237 Crypto Config Interface considers the following types of parameters: 1239 * Parameter Size (e.g. key length in bit) 1241 * Parameter Counter Content (e.g. nonce) 1243 * Parameter Secure Random Content (e.g. nonce) 1245 * Parameter User Automatic Tunable Content (e.g. memory consumption 1246 for Argon2 password hashing algorithm) 1248 * Parameter User Defined Content (e.g. plaintext and key for 1249 symmetric encryption) 1251 * Parameter Compound Parameter Content (e.g. counter + random = 1252 nonce) 1254 6.2.5. Automatic Parameter Tuning 1256 * [ ] TODO is it possible to define new algorithm/parameter 1257 combinations on the fly (in extensions/derivations) or are only 1258 SCC IANA registry identifiers allowed/usable? 1260 It should be possible to have user specified parameters such as the 1261 key/nonce length explicitly given by the user, but also a performance 1262 mode that evaluates for each configuration and gives back a 1263 prioritized list for each configuration. In this way, it is possible 1264 to select parameters depending on systems properties. Such a 1265 parameter choice would be beneficial e.g. in the case of Argon2 1266 (https://tools.ietf.org/html/draft-irtf-cfrg-argon2-13) in which one 1267 parameter for the memory usage must be given. This choice should be 1268 chosen based on the corresponding system. That kind of parameter 1269 selection can be seen e.g. in Libpasta Tuning 1270 (https://libpasta.github.io/advanced/tuning/), which returns a secure 1271 parameter set depending on executed evaluations. 1273 6.2.6. Output of readable Secure Crypto Config 1275 A Secure Crypto Config Interface must offer the following additional 1276 methods regarding the configuration - A method that returns a human 1277 readable version of the currently used Secure Crypto Config - A 1278 method that returns the currently used cryptography algorithm and 1279 parameters for a given use case - A method that validates the content 1280 of a Secure Crypto Config JSON file and one or more signatures 1282 6.3. TODOs 1284 * The SCC could be provided on a suitable platform (?) and is 1285 accessible over the network (adversaries? e.g. http connection) 1287 - [ ] e.g. should there be constants like "SCC_TOP_SECRET_LATEST" 1288 and "SCC_TOP_SECRET_LATEST". 1290 - [ ] And like "SCC_TOP_SECRET_LATEST.AES" which points always to 1291 the latest Secure Crypto Config definition for AES parameters. 1293 * [ ] TODO how should cryptography implementations, that implement/ 1294 support SCC, generate the parameters? 1296 * [x] What kind of parameters can be chosen based on the Secure 1297 Crypto Config? => E.g. Should be all except the plaintext and the 1298 key for encryption algorithms. Also, many parameters can be 1299 generated based on cryptographically secure random numbers. 1301 * [x] TODO The Secure Crypto Config Interface should include a 1302 performance evaluation mode which evaluates the performance of 1303 each configuration and returns a prioritized list for each 1304 configuration. E.g. cf. Libpasta Tuning 1305 (https://libpasta.github.io/advanced/tuning/) 1307 7. Cryptography Library Implementation Specification 1309 Cryptography libraries should provide the above mentioned Secure 1310 Crypto Config Interface. Until a common cryptography library 1311 provides the Secure Crypto Config Interface itself, there should be 1312 wrapper implementations that provide the Secure Crypto Config 1313 Interface and make use of the programming languages' standard 1314 cryptography library. 1316 8. Cryptography Algorithm Standards Recommendation 1318 When new cryptography algorithm and/or parameter/mode/etc standards 1319 are created, they should contain a section mentioning the creating of 1320 the proposed secure parameter sets in the above mentioned IANA 1321 registries. This ensures that new cryptography algorithms and 1322 parameter sets are available faster for the Secure Crypto Config 1323 Interface implementations to use. 1325 9. Security Considerations 1327 * [x] TODO are some of the listed common issues relevant?: 1328 TypicalSECAreaIssues (https://trac.ietf.org/trac/sec/wiki/ 1329 TypicalSECAreaIssues) 1331 * [x] TODO check if security considerations of TLS 1.2 are relevant, 1332 especially appendix D, E and F (https://tools.ietf.org/html/ 1333 rfc5246#appendix-D) 1335 * [ ] TODO Are these appropriate security considerations? 1337 9.1. Consensus Finding 1339 * Only trustworthy and cryptographic specialized entities should 1340 participate in the publication process of the Secure Crypto 1341 Config. Otherwise a Secure Crypto Config with a weak and insecure 1342 parameter set could be provided. 1344 9.2. Publication Format 1346 * The operators of the Secure Crypto Config must ensure that 1347 potential unauthorized parties are not able to manipulate the 1348 parameters of the published Secure Crypto Config. Countermeasures 1349 to this are in place by utilizing git's gpg signatures and 1350 integrity as well as signatures for the published Secure Crypto 1351 Config files as well. 1353 9.3. Cryptography library implementation 1354 * Integrity must be ensured if potential users want to fetch the 1355 provided Secure Crypto Config from the corresponding platform over 1356 the network e.g. by using a signatures. 1358 * Users should only trust Secure Crypto Config issued from the 1359 original publisher with the associated signature. Users are 1360 responsible to verify the provided signatures. 1362 9.4. General Security Considerations 1364 9.4.1. Special Use Cases and (Non-)Security Experts 1366 The Secure Crypto Config does not apply to all use cases for 1367 cryptography and usage of cryptography primitives. It is meant to 1368 provide secure defaults for the most common use cases and non-expert 1369 programmers. Additionally, non-experts may still implement 1370 vulnerable code by using the Secure Crypto Config. Yet, it should 1371 reduce the vulnerabilities from making the wrong choices about 1372 parameters for cryptography primitives. 1374 9.5. Security of Cryptography primitives and implementations 1376 * The Secure Crypto Config assumes that both the proposed algorithms 1377 and the implementations (cryptography libraries) for the 1378 cryptography primitives are secure as long as they are used with 1379 the correct parameters, states and orders of function calls. 1381 9.5.1. Security Guarantees 1383 The Secure Crypto Config makes the best effort to be as up-to-date 1384 with recent discoveries, research and developments in cryptography 1385 algorithms as possible. Following this, it strives to publish 1386 cryptography algorithms and corresponding parameter choices for 1387 common use cases. 1389 Yet, the Secure Crypto Config and the involved parties working on and 1390 publishing it do not guarantee security for the proposed parameter 1391 configurations or any entity making use of it. E.g. a new algorithm 1392 that can do brute-force attacks exponentially faster could be 1393 existing or published right after the publication of the most recent 1394 Secure Crypto Config was published itself. 1396 9.5.2. Threat Model / Adversaries 1398 There are different possibilities in which a potential adversary 1399 could intervene during the creation as well as after the publication 1400 of the Secure Crypto Config. These attack scenarios must be 1401 considered and prevented. 1403 * *Process:* During the creation process, it is necessary for 1404 selected institutions to agree on a secure parameter set. It 1405 could be possible that one party wants to influence this process 1406 in a bad way. As a result, it could be agreed on weaker parameter 1407 sets than originally intended. 1409 * *Publication:* After the publication of the Secure Crypto Config a 1410 potential attacker could gain access to the provided files on the 1411 corresponding platform and change the content to an insecure 1412 parameter set. 1414 * *Content:* Depending on the distribution method of the Secure 1415 Crypto Config, it is also possible that an attacker could change 1416 the content of the Secure Crypto Config as man-in-the-middle. 1417 Especially if an http connection is used to obtain the Secure 1418 Crypto Config, this will be a serious problem. 1420 10. IANA Considerations 1422 * [] TODO Are there IANA Considerations? 1424 * [] TODO May add reference to own registry 1426 The data structure (see Section 5.4) defined in this document uses 1427 the JSON format as defined in [RFC8259]. 1429 11. References 1431 11.1. Normative References 1433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1434 Requirement Levels", BCP 14, RFC 2119, 1435 DOI 10.17487/RFC2119, March 1997, 1436 . 1438 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1439 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1440 . 1442 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1443 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1444 . 1446 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1447 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1448 May 2017, . 1450 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1451 Interchange Format", STD 90, RFC 8259, 1452 DOI 10.17487/RFC8259, December 2017, 1453 . 1455 11.2. Informative References 1457 [AESNI] Gueron, S., "Intel Advanced Encryption Standard (AES) 1458 Instruction Set White Paper", 2010, 1459 . 1463 [RFC2743] Linn, J., "Generic Security Service Application Program 1464 Interface Version 2, Update 1", RFC 2743, 1465 DOI 10.17487/RFC2743, January 2000, 1466 . 1468 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1469 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1470 . 1472 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1473 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1474 . 1476 [RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure 1477 for the Security Suitability of Cryptographic Algorithms 1478 (DSSC)", RFC 5698, DOI 10.17487/RFC5698, November 2009, 1479 . 1481 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 1482 Procedure for the Resource Public Key Infrastructure 1483 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 1484 2013, . 1486 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1487 Constrained-Node Networks", RFC 7228, 1488 DOI 10.17487/RFC7228, May 2014, 1489 . 1491 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1492 Agility and Selecting Mandatory-to-Implement Algorithms", 1493 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1494 . 1496 Appendix A. Examples 1497 A.1. JSON Secure Crypto Config 1499 { 1500 "PolicyName" : "SCC_SecurityLevel_5", 1501 "Publisher" : [ 1502 { 1503 "name" : "Crypto Forum Research Group", 1504 "URL" : "https://irtf.org/cfrg" 1505 }, 1506 { 1507 "name" : "BSI", 1508 "URL" : "https://BSI" 1509 } 1510 ], 1511 "SecurityLevel" : "5", 1512 "Version" : "2020-0", 1513 "PolicyIssueDate" : "2020-04-20", 1514 "Expiry" : "2023-04-21", 1515 "Usage" : { 1516 "SymmetricEncryption" : [ 1517 "AES_GCM_256_96", 1518 "AES_GCM_192_96" 1519 ], 1520 "AsymmetricEncryption" : [ 1521 "RSA_SHA_512", 1522 "RSA_SHA_256" 1523 ], 1524 "Hashing" : [ 1525 "SHA3_512", 1526 "SHA_512" 1527 ], 1528 "Signing" : [ 1529 "ECDSA_512", 1530 "ECDSA_384" 1531 ], 1532 "PasswordHashing" : [ 1533 "PBKDF_SHA_512", 1534 "SHA_512_64" 1535 ] 1536 } 1537 } 1539 Figure 4: Example for JSON format 1541 Appendix B. Example Java Interface using Secure Crypto Config 1542 package org.securecryptoconfig; 1544 import java.nio.charset.Charset; 1545 import java.security.InvalidKeyException; 1546 import org.securecryptoconfig.SCCKey.KeyType; 1547 import org.securecryptoconfig.SCCKey.KeyUseCase; 1549 import COSE.CoseException; 1551 public abstract interface SecureCryptoConfigInterface { 1553 //Symmetric 1554 public AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key, PlaintextContainerInterface plaintext) 1555 throws SCCException; 1557 public AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key, byte[] plaintext) 1558 throws SCCException; 1560 public AbstractSCCCiphertext reEncryptSymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext) 1561 throws SCCException; 1563 public PlaintextContainerInterface decryptSymmetric(AbstractSCCKey key, AbstractSCCCiphertext sccciphertext) 1564 throws SCCException; 1566 // Asymmetric 1567 public AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key, PlaintextContainerInterface plaintext) 1568 throws SCCException; 1570 public AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key, byte[] plaintext) 1571 throws SCCException; 1573 public AbstractSCCCiphertext reEncryptAsymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext) 1574 throws SCCException; 1576 public PlaintextContainerInterface decryptAsymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext) 1577 throws SCCException; 1579 // Hashing 1580 public AbstractSCCHash hash(PlaintextContainerInterface plaintext) 1581 throws SCCException; 1583 public AbstractSCCHash hash(byte[] plaintext) 1584 throws SCCException; 1586 public AbstractSCCHash updateHash(PlaintextContainerInterface plaintext, AbstractSCCHash hash) 1587 throws SCCException; 1589 public AbstractSCCHash updateHash(byte[] plaintext, AbstractSCCHash hash) 1590 throws SCCException; 1592 public boolean validateHash(PlaintextContainerInterface plaintext, AbstractSCCHash hash) 1593 throws SCCException; 1595 public boolean validateHash(byte[] plaintext, AbstractSCCHash hash) 1596 throws SCCException; 1598 // Digital Signature 1599 public AbstractSCCSignature sign(AbstractSCCKey key, PlaintextContainerInterface plaintext) 1600 throws SCCException; 1602 public AbstractSCCSignature sign(AbstractSCCKey key, byte[] plaintext) 1603 throws SCCException; 1605 public AbstractSCCSignature updateSignature(AbstractSCCKey key, PlaintextContainerInterface plaintext) 1606 throws SCCException; 1608 public AbstractSCCSignature updateSignature(AbstractSCCKey key, byte[] plaintext) 1609 throws SCCException; 1611 public boolean validateSignature(AbstractSCCKey key, AbstractSCCSignature signature) 1612 throws SCCException; 1614 public boolean validateSignature(AbstractSCCKey key, byte[] signature) 1615 throws SCCException; 1617 // Password Hashing 1618 public AbstractSCCPasswordHash passwordHash(PlaintextContainerInterface password) 1619 throws SCCException; 1621 public AbstractSCCPasswordHash passwordHash(byte[] password) 1622 throws SCCException; 1624 public boolean validatePasswordHash(PlaintextContainerInterface password, AbstractSCCPasswordHash passwordhash) 1625 throws SCCException; 1627 public boolean validatePasswordHash(byte[] password, AbstractSCCPasswordHash passwordhash) 1628 throws SCCException; 1629 } 1631 abstract interface PlaintextContainerInterface { 1633 public abstract byte[] toBytes(); 1635 public abstract String toString(Charset c); 1637 @Override 1638 public abstract String toString(); 1640 public abstract boolean validateHash(AbstractSCCHash hash) 1641 throws SCCException; 1643 public abstract boolean validatePasswordHash(AbstractSCCPasswordHash passwordHash) 1644 throws SCCException; 1646 public abstract AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key) 1647 throws SCCException; 1649 public abstract AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key) 1650 throws SCCException; 1652 public abstract AbstractSCCSignature sign(AbstractSCCKey key) 1653 throws SCCException; 1655 public abstract boolean validateSignature (AbstractSCCSignature signature, AbstractSCCKey key) 1656 throws SCCException; 1658 public abstract AbstractSCCHash hash() 1659 throws SCCException; 1661 public abstract AbstractSCCPasswordHash passwordHash() 1662 throws SCCException; 1663 } 1665 abstract class AbstractSCCCiphertext { 1667 byte[] msg; 1669 protected AbstractSCCCiphertext(byte[] msg) { 1670 this.msg = msg; 1671 } 1673 public abstract byte[] toBytes(); 1675 @Override 1676 public abstract String toString(); 1678 public abstract PlaintextContainerInterface decryptSymmetric(AbstractSCCKey key) 1679 throws SCCException; 1681 public abstract PlaintextContainerInterface decryptAsymmetric(AbstractSCCKey key) 1682 throws SCCException; 1684 public abstract AbstractSCCCiphertext reEncryptSymmetric(AbstractSCCKey key) 1685 throws SCCException; 1687 public abstract AbstractSCCCiphertext reEncryptAsymmetric(AbstractSCCKey key) 1688 throws SCCException; 1689 } 1691 abstract class AbstractSCCKey { 1693 KeyType type; 1694 byte[] privateKey 1695 byte[] publicKey; 1696 String algorithm; 1698 protected AbstractSCCKey(KeyType type, byte[] publicKey, byte[] privateKey, String algorithm) { 1699 this.type = type; 1700 this.publicKey = publicKey; 1701 this.privateKey = privateKey; 1702 this.algorithm = algorithm; 1703 } 1705 public abstract byte[] toBytes() 1706 throws SCCException; 1708 public abstract byte[] getPublicKeyBytes() 1709 throws SCCException; 1711 public abstract byte[] getPrivateKeyBytes() 1712 throws SCCException; 1714 public abstract KeyType getKeyType(); 1716 public abstract String getAlgorithm(); 1717 } 1719 abstract class AbstractSCCHash { 1721 byte[] hashMsg; 1723 protected AbstractSCCHash(byte[] hashMsg) { 1725 this.hashMsg = hashMsg; 1726 } 1728 public abstract byte[] toBytes(); 1730 @Override 1731 public abstract String toString(); 1733 public abstract boolean validateHash(PlaintextContainerInterface plaintext) 1734 throws SCCException; 1736 public abstract boolean validateHash(byte[] plaintext) 1737 throws SCCException; 1739 public abstract AbstractSCCHash updateHash(PlaintextContainerInterface plaintext) 1740 throws SCCException; 1742 public abstract AbstractSCCHash updateHash(byte[] plaintext) 1743 throws SCCException; 1744 } 1746 abstract class AbstractSCCPasswordHash { 1748 byte[] hashMsg; 1750 protected AbstractSCCPasswordHash(byte[] hashMsg) { 1751 this.hashMsg = hashMsg; 1752 } 1754 public abstract byte[] toBytes(); 1756 @Override 1757 public abstract String toString(); 1759 public abstract boolean validatePasswordHash(PlaintextContainerInterface password) 1760 throws SCCException; 1762 public abstract boolean validatePasswordHash(byte[] password) 1763 throws SCCException; 1764 } 1766 abstract class AbstractSCCSignature { 1768 byte[] signatureMsg; 1770 protected AbstractSCCSignature(byte[] signatureMasg) { 1771 this.signatureMsg = signatureMasg; 1772 } 1774 public abstract byte[] toBytes(); 1776 @Override 1777 public abstract String toString(); 1779 public abstract boolean validateSignature(AbstractSCCKey key) 1780 throws SCCException; 1782 public abstract AbstractSCCSignature updateSignature(PlaintextContainerInterface plaintext, AbstractSCCKey key) 1783 throws SCCException; 1784 } 1786 Figure 5: Example for a JAVA SCC API 1788 Acknowledgments 1790 * [ ] TODO acknowledge. 1792 Authors' Addresses 1794 Kai Mindermann 1795 iC Consult GmbH 1797 Email: kai.mindermann@ic-consult.com 1799 Lisa Teis 1801 Email: lisateis102@gmail.com