idnits 2.17.1 draft-kaimindermann-securecryptoconfig-00.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 56 instances of too long lines in the document, the longest one being 48 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 (18 October 2020) is 1279 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2743' is defined on line 1470, but no explicit reference was found in the text == Unused Reference: 'RFC5116' is defined on line 1475, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 1479, but no explicit reference was found in the text == Unused Reference: 'RFC5698' is defined on line 1483, but no explicit reference was found in the text == Unused Reference: 'RFC6916' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: 'RFC7696' is defined on line 1498, 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 April 2021 18 October 2020 7 Secure Crypto Config 8 draft-kaimindermann-securecryptoconfig-00 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 April 2021. 50 Copyright Notice 52 Copyright (c) 2020 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 . . . . . . . . 22 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 Interface . . . . . . . . . . . . . . . 24 110 6.1. Semantic Versioning . . . . . . . . . . . . . . . . . . . 24 111 6.2. Deployment of (custom) Secure Crypto Config with 112 Interface . . . . . . . . . . . . . . . . . . . . . . . . 24 113 6.2.1. Delivery of Secure Crypto Config with Interface . . . 26 114 6.2.2. Using a custom Secure Crypto Config Repository . . . 26 115 6.2.3. Integrity Check . . . . . . . . . . . . . . . . . . . 26 116 6.3. Application Programming Interface (API) . . . . . . . . . 27 117 6.3.1. Methods and Parameters . . . . . . . . . . . . . . . 27 118 6.3.2. Automatic Parameter Tuning . . . . . . . . . . . . . 27 119 6.3.3. Output of readable Secure Crypto Config . . . . . . . 28 120 6.4. TODOs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 121 7. Cryptography Library Implementation Specification . . . . . . 28 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 . . . . . . . . . . . . . . . . . 31 137 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 32 138 A.1. JSON Secure Crypto Config . . . . . . . . . . . . . . . . 32 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 regular 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 more easy to maintain, more 198 compatible to 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 Beside 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 * RSA 315 * RSAES-OAEP w/ SHA-512,-42,RSAES-OAEP w/ SHA-512 317 1.3.2.3. Hashing 319 Hashing is an important cryptographic primitives and is often needed 320 as a part of many other cryptographic use cases e.g. password 321 derivation. 323 The only expected input parameters by cryptography users: 325 * plaintext 327 Expected output: hash. 329 Possible secure usage: 331 * SHA-512 (TEMPORARY - registered 2019-08-13, expires 332 2020-08-13);-44;SHA-2 512-bit Hash 334 * SHAKE256 (TEMPORARY - registered 2019-08-13, expires 335 2020-08-13);-45;256-bit SHAKE 337 1.3.2.4. Password Hashing 339 The secure storage of passwords requires hashing. Yet, password 340 hashing requires that the hashing can not be performed very fast to 341 prevent attackers from guessing/brute-forcing passwords from leaks or 342 against the live system. E.g. it is totally fine for users if the 343 login takes 0.1 seconds instead of microseconds. This results in 344 special families of hash algorithms which offer additional tuning 345 parameters. 347 The only expected input parameters by cryptography users: 349 * plaintext 351 * hash-algorithm 353 Expected output: hash. 355 Possible secure usage: 357 * Argon2id 359 1.3.2.5. Key Generation 361 * [ ] TODO should key generation be considered? (Symmetric/ 362 Asymmetric) 364 A key is necessary for many cryptographic use cases e.g. symmetric 365 and asymmetric encryption. Therefore, key generation is an important 366 part while implementing cryptographic code. 368 The only expected input is the intended use case. 370 Expected output: key. 372 Possible secure generation: 374 * Use of CSPRNG 376 * Keys derived via derivation function from passwords/other keys 378 1.3.2.6. Digital Signatures 380 Signing is an important and often needed cryptographic use case. It 381 is based on the principle of asymmetrical encryption. 383 The only expected input parameters for signing: 385 * plaintext 387 * private key 389 Expected output: signature. 391 The only expected input parameters for verifying the signature: 393 * signature 395 * public key 397 Expected output: valid/not-valid. 399 Possible secure usage: 401 * ECDSA 403 * ES512;-36;ECDSA w/ SHA-512 405 2. Requirements and Assumptions 407 2.1. Requirements 409 In the following all requirements are listed that regard the Secure 410 Crypto Config or the Secure Crypto Config Interface. 412 * Security Level Requirements: The Secure Crypto Config should 413 define different security levels. E.g. information has different 414 classification levels and longevity. Additionally, cryptography 415 operations could not or much slower perform on constrained 416 devices, which should also be handled with the security levels. 417 For each security level the consensus finding process and entities 418 shall publish a distinct secure crypto config. 420 * Consensus Finding Process and entities: 422 - The Secure Crypto Config must be renewed regularly. 424 - The Secure Crypto Config must be renewable on-demand. 426 - There must be a guideline on which entities must agree to 427 publish a new Secure Crypto Config. 429 - There must be a guideline on which entities may participate in 430 the consensus finding process and how they may do so. 432 - There must be a guideline on how to determine broad 433 availability of both cryptography algorithms and chosen 434 parameters. 436 * Publication Format and Distribution Requirements: 438 - General: 440 o The Secure Crypto Config must be easily publishable by the 441 committee. 443 o Standardized unique and distinct names for (1) cryptography 444 algorithms (2) their parameters and (3) the combination of 445 the algorithm with set parameters. Otherwise ambiguity 446 would make it harder for developers and cryptography 447 implementors to make correct and secure choices. 449 o There must be a versioning that allows to distinguish 450 between Secure Crypto Configurations and what is the latest 451 Secure Crypto Config. 453 o There must be a deprecation process that ensures usage of 454 outdated/insecure Crypto Configurations ceases. 456 o There must be an official source where this Secure Crypto 457 Config is maintained and can be obtained from (e.g. via the 458 WWW). 460 o The official source format of the Secure Crypto Config must 461 be cryptographically protected to ensure its integrity and 462 authenticity. 464 o Other published formats derived from the source format (e.g. 465 for human readability on a webpage) do not have to be 466 cryptographically protected but should be generated 467 automatically from the source format. 469 o The official source should also provide information about 470 the Secure Crypto Config Interface that should be utilized 471 for the application of the Secure Crypto Config. 473 o The Secure Crypto Config must specify how it can be extended 474 (e.g. more security levels) and how derivatives work. 476 - Human readable 478 o The Secure Crypto Config must have a human readable format. 480 o The Secure Crypto Config must allow non-experts to find 481 secure cryptography algorithms and appropriate parameters 482 for common cryptography use cases. 484 o The Secure Crypto Config human readable publication format 485 should only use easy to comprehend data structures like two- 486 dimensional tables. 488 - Machine readable 490 o Cryptography libraries, regardless of the programming 491 language, should be able to directly map (without extensive 492 parsing) the Secure Crypto Config to their implementation 494 o Must be easy to verify which Secure Crypto Config is used / 495 was used (e.g. in Continuous Integration platforms) 497 o Must be easy to verify the authenticity of the Secure Crypto 498 Config (e.g. is this really what the CFRG has published) 500 * Cryptography library integration requirements: 502 - Easy to integrate by cryptography libraries 504 - Experts should still be able to use/access the unaltered output 505 of cryptographic primitives 507 - Recommendation what should be the default Secure Crypto Config 508 for a cryptography library (e.g. should it be the one with the 509 highest security level or _only_ a weaker one?) 511 - Recommendation what should a cryptography library do if it can 512 not support the parameters specified in the latest Secure 513 Crypto Config. (E.g. key size for RSA would be n*2 and the 514 library supports only n) 516 - Recommendation on how a cryptography library should integrate 517 the Secure Crypto Config so that it is up to date as soon as 518 possible after a new Secure Crypto Config has been published 520 * General Requirements: 522 - Interoperability with other standards/formats (e.g. [RFC8152]) 524 - The Secure Crypto Config should cover most common cryptography 525 primitives and their currently broadly available and secure 526 algorithms. 528 - The Secure Crypto Config should be protected against attackers 529 as defined in Section 3.6.5 531 - The Secure Crypto Config should prevent non-experts to 532 configure cryptography primitives in an insecure way. 534 - The Secure Crypto Config should not prevent experts from using 535 or changing all parameters of cryptography primitives provided 536 by a cryptography library/API. 538 2.2. Assumptions 540 The Secure Crypto Config assumes that both the proposed algorithms 541 and the implementations (cryptography libraries) for the cryptography 542 primitives are secure. This also means that side-channel attacks are 543 not considered explicitly. It is also assumed that programmers, 544 software engineers and other humans are going to use cryptography. 545 They are going to make implementation choices without being able to 546 consult cryptography and security experts and without understanding 547 cryptography related documentation fully. This also means that it is 548 not considered best practice to assume or propose that only 549 cryptography experts (should) use cryptography (primitives/ 550 libraries). 552 3. Security Levels 554 The Secure Crypto Config must be able to provide a secure parameter 555 set for different security levels. These security levels depend on 556 the following security constraints: *Information classification 557 (Secret, Confidential), Longevity (less than one day, more than a 558 day), Constrained devices (constrained, not constrained)*. They are 559 defined in Section 3.6 below. The Secure Crypto Config provides 5 560 common security levels for which official algorithm/parameter choices 561 are published. 563 3.1. Security Level 1 - Low 565 Confidential information, regardless of the other two constraints 567 3.2. Security Level 2 569 Secret information, less than one day longevity, constrained device 571 3.3. Security Level 3 573 Secret information, less than one day longevity, non-constrained 574 device 576 3.4. Security Level 4 578 Secret information, more than a day longevity, constrained device 580 3.5. Security Level 5 - High 582 Secret information, more than a day longevity, non-constrained device 584 3.6. Security Level Constraints 586 3.6.1. Information classification 588 Information classification within this document is about the 589 confidentiality of the information. Not all information is equally 590 confidential, e.g. it can be classified into different classes of 591 information. For governmental institutions usually three classes are 592 used: Confidential, Secret, or Top Secret. The Secure Crypto Config 593 considers only *Confidential* and *Secret* for its standardized 594 security levels. Further levels with other classifications can be 595 added by other organizations. Additionally, in common (non- 596 governmental) use cases data is not labelled with an information 597 class. Hence, often only one class is chosen for the cryptography 598 processing of all data. 600 The Secure Crypto Config does not endorse a definition of the 601 information classes, yet *Secret* information is to be considered to 602 have higher confidentiality requirements than *Confidential* 603 information. 605 3.6.2. Longevity 607 The time how long information has to be kept confidential can 608 influence cryptography parameters a lot. Usually what you talked 609 about with your friends should be kept confidential for a life time. 610 Yet, a public trade transaction must only be confidential until the 611 trade was executed which can happen in milliseconds. It directly 612 influences a very important attacker resource: The time an attacker 613 has to try to gain access to the confidential information. The 614 Secure Crypto Config considers only two ranges of longevity for its 615 standardized security levels: *short longevity* of less than one day 616 and *long longevity* of a day or more than a day. Further levels 617 with other longevity levels can be added by other organizations. 619 3.6.3. Constrained Devices 621 For cryptography often complex computations have to be executed. 622 Yet, not all environments have the same hardware resources available. 623 E.g. it is not always the case that the used processors have 624 dedicated cryptography hardware or even specialized execution units 625 or instruction sets like [AESNI]. Detailed discussion and 626 definitions can be found in [RFC7228]. Yet, their definitions are 627 too concrete to be used in the Secure Crypto Config's standardized 628 security levels. Therefore, the Secure Crypto Config uses defines 629 constraint devices not based on concrete processing power (e.g. 100k 630 instructions per second): 632 A device is constrained when it has *multiple orders of magnitudes* 633 less resources than a current (not a new one, but broadly in use at 634 the time of publication of a Secure Crypto Config!) standard personal 635 computer. 637 For example if a current standard personal computer can encrypt with 638 1 GiB/s, a constrained device would be all devices that can only 639 perform the same cryptography operation with less than 10 MiB/s. 640 Resources can be everything important for cryptography like dedicated 641 cryptography hardware, instruction sets, memory, power consumption, 642 storage space, communication bandwidth, latency etc. The Secure 643 Crypto Config considers only *constrained* and *non-constrained* for 644 its standardized security levels. Further levels with other 645 constrained resource definitions can be added by other organizations. 647 3.6.4. n-Bit-Security 649 n-Bit Security Level: 651 A cryptographic mechanism achieves a security level of n bits if 652 costs which are equivalent to 2^n calculations of the encryption 653 function of an efficient block cipher (e.g. AES) are tied to each 654 attack against the mechanism which breaks the security objective 655 of the mechanism with a high probability of success. BSI 657 3.6.5. Attacker Resources and Capabilities 659 The Secure Crypto Config considers only the following same attacker 660 resources and capabilities for all standardized security levels: 662 * The attacker knows all used algorithms and parameters except 663 secrets according to Kerckhoffs's principle. 665 * The attacker has access to the system used for cryptography 666 operations and can utilize its cryptography operations apart from 667 obtaining secrets. 669 * The attacker can utilize very high-performance computing resources 670 such as super computers and distributed computing (e.g. this 671 includes very high memory, storage, processing and networking 672 performance) 674 Further security levels with other attacker definitions can be added 675 by other organizations. 677 4. Consensus Finding Process and entities 679 To provide a Secure Crypto Config it is necessary to agree upon a 680 secure and appropriate cryptographic parameter set for each security 681 level (see Section 3). This must happen in a common consensus 682 finding process which takes place during a regular intervals. The 683 consensuns finding process is based on the established RFC process 684 during which the Secure Crypto Config Working Group decides in 685 cooperation with the Crypto Forum Research Group (CFRG) and other 686 institutions like the Bundesamt fuer Sicherheit in der 687 Informationstechnik (BSI) or the National Institute of Standards and 688 Technology (NIST) for a set of secure parameters. After the 689 successful decision the agreed on parameters can be added in the 690 defined pulibcation data structures (see Section 5.4) and provided on 691 the repository platform. 693 4.1. Consensus Finding 695 Consensus must be found two years after the last consensus was found. 696 This ensures that there is a new Secure Crypto Config every two 697 years, even if the configuration itself has not changed. There is a 698 regular process and an emergency process to release Secure Crypto 699 Configurations. 701 4.1.1. Regular Process 703 The process has three phases that MUST be finalized within 2 years: 705 * (1) One year *Proposal phase* during which all participating 706 entities must propose at least two cryptography algorithms and 707 parameters per cryptography use case per security level. 709 * (2) Six months *Consensus finding phase* during which all 710 participating entities must agree on a common Secure Crypto 711 Config. 713 * (3) Six months *Publication phase* ensures the publication of the 714 final Secure Crypto Config AND allows the Secure Crypto Config 715 Interface and other cryptography implementations to integrate the 716 necessary changes. 718 During the Proposal phase the proposed algorithms and all necessary 719 parameters should be submitted in table form for each security level 720 and defined cryptographic use case like proposed. This table format 721 is simply structured and is easy to read by human as the Consensus 722 finding phase can only be done manually. It is important that the 723 parameters for each cryptographic use case depending on its security 724 level can be found easily by the participants of the consensus 725 finding process such that it is possible to get to an agreement 726 faster. 728 4.1.2. Emergency Process 730 * [ ] TODO How can the Working Group alter the Secure Crypto Config 731 IANA registry / or use the RFC Errata process? 733 In cases when a regularly still valid Secure Crypto Config would 734 become insecure regarding either a proposed algorithm or a proposed 735 parameter choice it must be revised with the following process: 737 1. Determine the insecure configuration. 739 2. Remove the insecure configuration. 741 3. Publish the revised Secure Crypto Config with a new patch 742 version. 744 4. Mark the old (unrevised) Secure Crypto Config as deprecated. 746 Examples for emergency cases are drastically better brute force 747 algorithms or brute force performance (e.g. quantum computers/ 748 algorithms), drastically discovered flaws in proposed algorithms and 749 their configurations. 751 An applied emergency process results in the problem that currently 752 used Secure Crypto Config Interface versions are no longer up-to- 753 date, because they are still supporting the no longer secure 754 algorithms. Therefore the corresponding algorithms need to be marked 755 as insecure. If e.g. an proposed algorithm gets insecure this can be 756 marked inside the corresponding Secure Crypto Config IANA registry 757 entry as no longer proposed to make the users aware of its 758 insecurity. The Working Group itself can decide when to alter the 759 Secure Crypto Config IANA registry. 761 4.1.3. Requirements for Selection of Cryptography Algorithm and 762 Parameters 764 The Secure Crypto Config MUST only propose cryptography algorithms 765 and parameters that fulfill the following requirements: 767 * Cryptography algorithms and parameters have stable implementations 768 in at least two different programming languages. 770 * Cryptography algorithms and parameters have a defined standard to 771 store the algorithm and parameter identification alongside the 772 result (e.g. like [RFC8152]). This is required to ensure 773 cryptography operation results can be processed even if the 774 default parameters have been changed or the information has been 775 processed with a previous version of the Secure Crypto Config. 777 * Cryptography algorithms that support parametrization to adapt to 778 increased brute force performance and to allow longevity of the 779 algorithm especially for hardware optimized implementations. 781 The Secure Crypto Config SHOULD only propose cryptography algorithms 782 and parameters that fulfill the following requirements: 784 * Cryptography algorithms and parameters are defined in a globally 785 accepted standard which was suspect to a standardization process. 787 * Cryptography algorithms and parameters are licensed under a 788 license that allows free distribution. 790 4.2. Entities 792 Entities that participate in the proposal phase SHOULD have 793 significant cryptography expertise. Entities that participate in the 794 consensus finding phase MUST have significant cryptography expertise. 795 Cryptographic expertise is defined by the Secure Crypto Config 796 Working Group or the CFRG. 798 5. Publication Format and Distribution 800 In general the Secure Crypto Config is published via JSON-files in an 801 official repository. The Secure Crypto Config also utilizes IANA 802 registries. 804 5.1. Versioning 806 The Secure Crypto Config Format is regularly published in a specific 807 year. Therefore, the Secure Crypto Config format MUST use the 808 following versioning format: *YYYY-PATCH*. YYYY is a positive integer 809 describing the year (using the Gregorian calendar, and considering 810 the year that has not ended in all time zones, cf. Anywhere on Earth 811 Time) this specific Secure Crypto Config was published. PATCH is a 812 positive integer starting at 0 and only increasing for emergency 813 releases. 815 5.2. Naming 817 Naming of official released SCCs must follow this format: 819 "SCC_**Version**_LEVEL_**Security Level Number**" 821 E.g. a Secure Crypto Config for Security Level 5 release in 2020 the 822 first time (so no patch version) would be named: 823 "SCC_2020-00_LEVEL_5" 825 Naming of files is not regulated, only the content is standards 826 relevant. Yet, the Secure Crypto Config Files should use the 827 mentioned naming convention as well adding a suffix (file type 828 ending) ".json" to prevent ambiguity and remove implementation 829 choices: 831 "SCC_**Version**_LEVEL_**Security Level Number.json**" 833 5.3. Secure Crypto Config IANA Registry 835 *NOT NEEDED?, as the Secure Crypto Config uses other registries, e.g. 836 COSE. No final decision, yet.* 838 * [ ] TODO Naming convention. Specification depending on crypto use 839 case? 841 * [ ] TODO dash character "-" not possible in enum! 843 The Secure Crypto Config requires one IANA Registry with the 844 following columns: 846 * Secure Crypto Config release version: *YYYY-PATCH* 848 * Distinct *Algorithm-Parameter-Identifier* that uniquely identifies 849 a cryptography algorithm and the parameters 851 * Distinct and *constantly available reference* where all parameters 852 are unambiguously defined 854 * (Optional) Short Description of the parameters 856 Algorithm-Parameter-Identifier: MUST only consist of uppercase 857 alphanumeric characters and underscores. Depending on the use case 858 the Algorithm Parameter Identifier can be constructed differently. 859 We propose the following schemes: 861 * For symmetric encryption the name should look like 862 *AlgorithmName_Mode_Padding_KeyLength_TagLength_NonceLength* (e.g. 863 AES_GCM_NoPadding_256_128_128). 865 * For hashing as *HashAlgorithmName_KeyLength* (e.g. SHA3_256). 867 * For asymmetric encryption and digital signatures 868 *AlgorithmName_AuxiliaryAlgorithm_Padding_KeyLength* (e.g. 869 RSA_ECB_OAEP_4096). 871 5.3.1. Example for Secure Crypto Config IANA Registry 873 +=========+=====================+===========+==================+ 874 | SCC | AlgParam Identifier | Reference | Description | 875 | Version | | | | 876 +=========+=====================+===========+==================+ 877 | 2020-01 | AES_GCM_256_128_128 | [RFC8152] | AES 256 with GCM | 878 | | | | and 128 bit tag | 879 | | | | and random nonce | 880 +---------+---------------------+-----------+------------------+ 882 Table 1 884 5.3.2. Utilized Algorithm Registries 886 The Secure Crypto Config can only propose cryptography algorithms and 887 parameters that have been standardized. Therefore it refers to the 888 following IANA registries: 890 * CBOR Object Signing and Encryption (COSE) 891 (https://www.iana.org/assignments/cose/cose.xhtml) 893 * AEAD Algorithms (https://www.iana.org/assignments/aead-parameters/ 894 aead-parameters.xhtml) 896 * Named Information Hash Registry (https://www.iana.org/assignments/ 897 named-information/named-information.xhtml#hash-alg) 899 Used registries must define all required parameters for an algorithm 900 to implement it without ambiguity. E.g. implementations must not be 901 able to choose other parameter values for a cryptography algorithm 902 and parameter combination. 904 5.4. Data Structures 906 For each defined security level a distinct JSON-file must be 907 provided. These files must adhere to the common schema and shown in 908 Figure 1 and described in the following. 910 { 911 "PolicyName": "SCC_SecurityLevel_Security Level Number", 912 "Publisher": [ 913 { 914 "name": "Publisher name", 915 "URL": "URL corresponding to publisher" 916 } 917 ], 918 "SecurityLevel" : "Security Level Number", 919 "Version": "YYYY-Patch", 920 "PolicyIssueDate": "YYYY-MM-DD", 921 "Expiry": "YYYY-MM-DD", 922 "Usage": { 923 "SymmetricEncryption": [ 924 "Algorithm 1", 925 "Algorithm 2" 926 ], 927 "AsymmetricEncryption": [ 928 "Algorithm 1", 929 "Algorithm 2" 930 ], 931 "Hashing": [ 932 "Algorithm 1", 933 "Algorithm 2" 934 ], 935 "PasswordHashing": [ 936 "Algorithm 1", 937 "Algorithm 2" 938 ], 939 "Signing": [ 940 "Algorithm 1", 941 "Algorithm 2" 942 ] 943 } 944 } 946 Figure 1: General JSON format 948 * SecurityLevel: Contains the number of the corresponding Security 949 Level of the Secure Crypto Config 951 * PolicyName: Contains the name of the corresponding Secure Crypto 952 Config according to the naming schema defined in Section 5.2 954 * Publisher: Contains an array of all parties that participated in 955 the consensus finding process 957 - name: Name of the participating party 959 - URL: Put in the official URL of the named publisher 961 * Version: Contains version in the format defined in Section 5.1 963 * PolicyIssueDate: Date at which the Secure Crypto Config was 964 published in the format: YYYY-MM-DD 966 * Expiry: Date at which the Secure Crypto Config expires in the 967 format: YYYY-MM-DD 969 * Usage: Contains an array of objects for each cryptographic use 970 case defined in Section 1.3.2. 972 - For each cryptographic use case, at least two agreed upon 973 algorithms (see Section 4) with necessary parameters are 974 included. Each of these algorithms with its parameters is 975 specified with its unique identification name defined in a IANA 976 registry used by the Secure Crypto Config. 978 This format allows custom algorithm/parameter definitions both by 979 overwriting use cases completely or by adding only specific algorithm 980 identifiers via custom configurations. 982 5.5. Human readable format 984 The Secure Crypto Config can not only be used in an automatic way, 985 but also provide the cryptography algorithms and parameters for 986 humans. The human readable format must be derived from the JSON- 987 files both to protect from copy-paste-errors and to validate the 988 cryptographic signatures. Yet, the human readable format or 989 publication page itself must not be cryptographically protected. 990 There should be one accessible resource, e.g. a webpage, where the 991 source format (JSON-files) are automatically used for displaying them 992 in appropriate ways (e.g. tables with various sorting and searching 993 options). 995 5.6. Official Secure Crypto Config Repository 997 5.6.1. Location of Secure Crypto Config Repository 999 The needed Secure Crypto Config files should be published at an 1000 official Github repository. There all current versions will be 1001 provided during the interval of the Publication phase (see 1002 Section 4.1.1). Additionally all previously published files are 1003 still stored at this location even if new versions are published. 1005 5.6.2. Format of Secure Crypto Config Repository 1007 scc-repo 1008 - configs 1009 - 2020 1010 - 00 1011 - SCC_2020-00_LEVEL_1.json 1012 - SCC_2020-00_LEVEL_1.signature1 1013 - SCC_2020-00_LEVEL_1.signature2 1014 - SCC_2020-00_LEVEL_2.json 1015 - SCC_2020-00_LEVEL_2.signature1 1016 - SCC_2020-00_LEVEL_2.signature2 1017 - SCC_2020-00_LEVEL_3.json 1018 - SCC_2020-00_LEVEL_3.signature1 1019 - SCC_2020-00_LEVEL_3.signature2 1020 - SCC_2020-00_LEVEL_4.json 1021 - SCC_2020-00_LEVEL_4.signature1 1022 - SCC_2020-00_LEVEL_4.signature2 1023 - SCC_2020-00_LEVEL_5.json 1024 - SCC_2020-00_LEVEL_5.signature1 1025 - SCC_2020-00_LEVEL_5.signature2 1026 - 01 1027 - 02 1028 - 2021 1029 - 2022 1030 - 2023 1031 - 2024 1033 Figure 2: Example for Secure Crypto Config Repository content 1035 scc-repo 1036 - configs 1037 - a 1038 - b 1039 - 0c1 1040 - ReallySecure 1041 - 0x1111 1042 - SCC_2020-00_LEVEL_1.json 1043 - SCC_2020-00_LEVEL_1.signature1 1044 - SCC_2020-00_LEVEL_1.signature2 1045 - SCC_2020-00_LEVEL_2.json 1046 - SCC_2020-00_LEVEL_2.signature1 1047 - SCC_2020-00_LEVEL_2.signature2 1048 - SCC_2020-00_LEVEL_3.json 1049 - SCC_2020-00_LEVEL_3.signature1 1050 - SCC_2020-00_LEVEL_3.signature2 1051 - SCC_2020-00_LEVEL_4.json 1052 - SCC_2020-00_LEVEL_4.signature1 1053 - SCC_2020-00_LEVEL_4.signature2 1054 - SCC_2020-00_LEVEL_5.json 1055 - SCC_2020-00_LEVEL_5.signature1 1056 - SCC_2020-00_LEVEL_5.signature2 1057 - asdf 1058 - afd 1059 - af 1061 Figure 3: Example for Secure Crypto Config Repository content 1062 with custom naming scheme 1064 The Secure Crypto Config configuration files are expected to be in 1065 any folder hierarchy below the folder "configs"-folder. Each JSON 1066 file should be accompanied by corresponding signature files that have 1067 the same filename without extension as the JSON file, suffixed by 1068 "-signatureX" where "X" is a counter starting at 1. 1070 5.6.3. Integrity/Signing process 1072 * [ ] TODO what kind of signing process should be used? 1074 - [ ] GPG? 1076 - [ ] openssl? 1078 - [ ] Git GPG signed commits? 1080 - [ ] Use an SCC recommended signing algorithm/format 1082 * [ ] Can two signatures be put in one signature file? Should they 1083 be put in the same file? 1085 * [ ] Public Key distribution?! (In Github repo?) 1087 Each JSON-file should be accompanied by at least two signatures. 1088 Both signatures are stored in different files on the same level as 1089 their corresponding Secure Crypto Config file to reduce the parsing 1090 effort. The signatures should be generated by entities defined by 1091 the Secure Crypto Config Working Group. They are responsible to 1092 publish and renew the used public keys. For signing of the 1093 corresponding Secure Crypto Config JSON files _openssl_ could be 1094 used. The public keys needed for validation are published in the 1095 official repository of the Secure Crypto Config. 1097 6. Secure Crypto Config Interface 1099 This section describes the programming interface that provides the 1100 Secure Crypto Config. The Secure Crypto Config Interface is generic 1101 and describes the API that should to be used by each programming 1102 language. 1104 6.1. Semantic Versioning 1106 The implementation of the Secure Crypto Config Interface MUST follow 1107 Semantic Versioning (https://semver.org/), which specifies a version 1108 format of *X.Y.Z* (Major.Minor.Patch) and semantics when to increase 1109 which version part. It would be beneficial if the release of a new 1110 Interface version gets synchronized with the publication of a new 1111 Secure Crypto Config. It should be possible to support the newly 1112 defined parameters of Secure Crypto Config in the interface as soon 1113 as possible. 1115 6.2. Deployment of (custom) Secure Crypto Config with Interface 1117 There are two different possibilities to work with the Secure Crypto 1118 Config: - The preferred option is to use the Secure Crypto Configs 1119 that will be delivered within the Interface. In each new Interface 1120 version the current Secure Crypto Configs will be added such that 1121 always the newest Secure Crypto Configs at the time of the Interface 1122 release will be supported. Previous Secure Crypto Configs will 1123 remain inside the Interface such that also older ones can still be 1124 used. - Another option is to define a specific path to your own/ 1125 derived versions of the Secure Crypto Configs with the same structure 1126 of the files as described in Section 5.4 but with other values than 1127 in the official ones. 1129 The Interface will process the Secure Crypto Configs as follows: 1131 1. Check if the path to the Secure Crypto Configs is a valid one. 1133 2. Check if the "configs" folder exists. 1135 3. For each folder following "configs" in the hierarchy look inside 1136 that folder and check the existence of JSON files that need to be 1137 considered. This check will happen recursively for all folders 1138 inside the hierarchy. 1140 4. For every JSON file found, look if there exists a signature. If 1141 one is given, check if the signature is valid for the 1142 corresponding file. 1144 5. Every files with a valid signature will be parsed and further 1145 processed. 1147 The parsing of each valid JSON file must be done as follows: 1149 1. Readout all informations of all JSON files that need to be 1150 considered. The information of each file is stored in a 1151 correspoding object. With this procedure all JSON files need to 1152 be read only once which will contribute to the performance. 1154 2. Parsing of security level: Check if it is a positive integer. 1155 All files not containing an (positive) integer number as security 1156 level value will be discarded. 1158 3. Parsing of algorithm identifiers: Only the algorithm identifiers 1159 that are supported by the Interface will be considered and stored 1160 inside the corresponding object. The supported algorithms are 1161 specified inside the interface (e.g. with an enmum). 1163 4. Parsing of the version of all files: All files with values in the 1164 wrong format (see Section 5.1) will be excluded from further 1165 processing. Find the latest (according to version) Secure Crypto 1166 Config file with the highest appearing security level (determined 1167 in previous step). The path to this file will be used as default 1168 path used for each cryptographic use case if nothing else is 1169 specified by the user. If two or more files with identical 1170 levels and version number are found, only the first one will be 1171 used, others are discarded. 1173 5. The unique algorithm identifiers for the execution of a specific 1174 cryptographic use case will be fetched from the corresponding 1175 object (representing the JSON file determined beforehand) at the 1176 time the users invokes a method for a specific cryptographic use 1177 case. The Interface will also provide a possibility to choose a 1178 specific algorithm (out of the supported ones) for executing the 1179 desired use case. In this case the specified algorithm is used. 1180 The identifiers will be compared with the supported ones in order 1181 of their occurrence inside the file. If one matching identifier 1182 is found it will be used for execution. If it is not a matching 1183 one the value will be skipped and the next one will be compared. 1184 If none of the algorithms inside the selected Secure Crypto 1185 Config can be found an error will occur. 1187 6.2.1. Delivery of Secure Crypto Config with Interface 1189 Each Secure Crypto Config Interface must be published in such a way 1190 that it uses (a copy of) the recent Secure Crypto Config repository. 1192 The Secure Crypto Config will be stored inside the subfolder "scc- 1193 configs" which should be located in the Interface's "src"-folder if 1194 existent. The structure of the "scc-configs" folder will be the same 1195 as in the described hierarchy of the Github repository. In any new 1196 version of the Interface the latest published Secure Crypto Config 1197 and its signatures must be used. 1199 If new Secure Crypto Configs will be published for which no published 1200 version of the Interface is available, the custom repository approach 1201 can be used as described in the following. 1203 6.2.2. Using a custom Secure Crypto Config Repository 1205 It is also possible to use a different path to the Secure Crypto 1206 Configs. As also derived versions of the Secure Crypto Config for 1207 specific needs should be supported it will also be feasible to define 1208 a path to own or derived files which differentiate from the default 1209 "src/scc-configs/configs" folder. For this case a method for setting 1210 and using a specific path must be provided by the Interface. 1212 6.2.3. Integrity Check 1214 * [ ] TODO which public keys should be used? (See above Integrity/ 1215 Signing process Public Key distribution?!) 1217 The check for valid signature of the Secure Crypto Configs is always 1218 made before every actual usage of the Interface functionalities. In 1219 this way it is possible to guarantee that the entity using the 1220 Interface only works with valid Secure Crypto Configs and circumvents 1221 the risk of forged file contents. The public key needed for validity 1222 can be found in the official Github repository. If own derived 1223 Secure Crypto Configs are created than it can be possible that no 1224 validation process is needed for these files. 1226 6.3. Application Programming Interface (API) 1228 6.3.1. Methods and Parameters 1230 Intended methods and parameters included in the Java interface are 1231 described in Figure 5. 1233 6.3.1.1. Supported Algorithm Parameter Types 1235 * [ ] TODO What is with parameters that have to be chosen during 1236 runtime? (e.g. the length of the nonce can be specified but not 1237 its content?) Maybe refer to how the PHC String Format 1238 (https://github.com/P-H-C/phc-string-format/blob/master/phc-sf- 1239 spec.md) describes how parameters must be defined and only allow 1240 constants and csprng generated content? 1242 Cryptography algorithms require different parameters. The Secure 1243 Crypto Config Interface considers the following types of parameters: 1245 * Parameter Size (e.g. key length in bit) 1247 * Parameter Counter Content (e.g. nonce) 1249 * Parameter Secure Random Content (e.g. nonce) 1251 * Parameter User Automatic Tunable Content (e.g. memory consumption 1252 for Argon2 password hashing algorithm) 1254 * Parameter User Defined Content (e.g. plaintext and key for 1255 symmetric encryption) 1257 * Parameter Compound Parameter Content (e.g. counter + random = 1258 nonce) 1260 6.3.2. Automatic Parameter Tuning 1262 * [ ] TODO is it possible to define new algorithm/parameter 1263 combinations on the fly (in extensions/derivations) or are only 1264 SCC IANA registry identifiers allowed/usable? 1266 It should be possible to have user specified parameters such as the 1267 key/nonce length explicitly given by the user, but also a performance 1268 mode which makes an evaluation for each configuration and give back a 1269 prioritized list for each configuration. In this way it is possible 1270 to select parameters depending on systems properties. Such a 1271 parameter choice would be beneficial e.g. in the case of Argon2 1272 (https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03) in which one 1273 parameter for the memory usage must be given. This choice should be 1274 chosen on the base of the corresponding system. That kind of 1275 parameter selection can be seen e.g. in Libpasta Tuning 1276 (https://libpasta.github.io/advanced/tuning/), which returns a secure 1277 parameter set depending on executed evaluations. 1279 6.3.3. Output of readable Secure Crypto Config 1281 A Secure Crypto Config Interface must offer the following additional 1282 methods regarding the configuration - A method that returns a human 1283 readable version of the currently used Secure Crypto Config - A 1284 method that returns the currently used cryptography algorithm and 1285 parameters for a given use case - A method that validates the content 1286 of a Secure Crypto Config JSON file and one or more signatures 1288 6.4. TODOs 1290 * The SCC could be provided on a suitable platform (?) and is 1291 accessible over the network (adversaries? e.g. http connection) 1293 - [ ] e.g. should there be constants like "SCC_TOP_SECRET_LATEST" 1294 and "SCC_TOP_SECRET_LATEST". 1296 - [ ] And like "SCC_TOP_SECRET_LATEST.AES" which points always to 1297 the latest Secure Crypto Config definition for AES parameters. 1299 * [ ] TODO how should cryptography implementations, that implement/ 1300 support SCC, generate the parameters? 1302 * [x] What kind of parameters can be chosen based on the Secure 1303 Crypto Config? => E.g. Should be all except the plaintext and the 1304 key for encryption algorithms. Also many parameters can be 1305 generated based on cryptographically secure random numbers. 1307 * [x] TODO The Secure Crypto Config Interface should include a 1308 performance evaluation mode which evaluates the performance of 1309 each configuration and returns a prioritized list for each 1310 configuration. E.g. cf. Libpasta Tuning 1311 (https://libpasta.github.io/advanced/tuning/) 1313 7. Cryptography Library Implementation Specification 1315 Cryptography libraries should provide the above mentioned Secure 1316 Crypto Config Interface. Until a common cryptography library 1317 provides the Secure Crypto Config Interface itself, there should be 1318 wrapper implementations that provide the Secure Crypto Config 1319 Interface and make use of the programming languages' standard 1320 cryptography library. 1322 8. Cryptography Algorithm Standards Recommendation 1324 When new cryptography algorithm and/or parameter/mode/etc standards 1325 are created, they should contain a section mentioning the creating of 1326 the proposed secure parameter sets in the above mentioned IANA 1327 registries. This ensures that new cryptography algorithms and 1328 parameter sets are available faster for the Secure Crypto Config 1329 Interface implementations to use. 1331 9. Security Considerations 1333 * [x] TODO are some of the listed common issues relevant?: 1334 TypicalSECAreaIssues (https://trac.ietf.org/trac/sec/wiki/ 1335 TypicalSECAreaIssues) 1337 * [x] TODO check if security considerations of TLS 1.2 are relevant, 1338 especially appendix D, E and F (https://tools.ietf.org/html/ 1339 rfc5246#appendix-D) 1341 * [ ] TODO Are these appropriate security considerations? 1343 9.1. Consensus Finding 1345 * Only trustworthy and cryptographic specialized entities should 1346 participate in the publication process of the Secure Crypto 1347 Config. Otherwise a Secure Crypto Config with a weak and insecure 1348 parameter set could be provided. 1350 9.2. Publication Format 1352 * The operators of the Secure Crypto Config must ensure that 1353 potential unauthorized parties are not able to manipulate the 1354 parameters of the published Secure Crypto Config. Countermeasures 1355 to this are in place by utilizing git's gpg signatures and 1356 integrity as well as signatures for the published Secure Crypto 1357 Config files as well. 1359 9.3. Cryptography library implementation 1361 * Integrity must be ensured if potential users want to fetch the 1362 provided Secure Crypto Config from the corresponding platform over 1363 the network e.g. by using a signatures. 1365 * Users should only trust Secure Crypto Config issued from the 1366 original publisher with the associated signature. Users are 1367 responsible to verify the provided signatures. 1369 9.4. General Security Considerations 1371 9.4.1. Special Use Cases and (Non-)Security Experts 1373 The Secure Crypto Config does not apply to all use cases for 1374 cryptography and usage of cryptography primitives. It is meant to 1375 provide secure defaults for the most common use cases and for non- 1376 expert programmers. Additionally, non-experts may still implement 1377 vulnerable code by using the Secure Crypto Config. Yet, it should 1378 reduce the vulnerabilities from making the wrong choices about 1379 parameters for cryptography primitives. 1381 9.5. Security of Cryptography primitives and implementations 1383 * The Secure Crypto Config assumes that both the proposed algorithms 1384 and the implementations (cryptography libraries) for the 1385 cryptography primitives are secure as long as they are used with 1386 the correct parameters, states and orders of function calls. 1388 9.5.1. Security Guarantees 1390 The Secure Crypto Config makes a best effort to be as up-to-date with 1391 recent discoveries, research and developments in cryptography 1392 algorithms as possible. Following this it strives to publish 1393 cryptography algorithms and corresponding parameter choices for 1394 common use cases. 1396 Yet, the Secure Crypto Config and the involved parties working on and 1397 publishing it doe not guarantee security for the proposed parameter 1398 configurations or any entity making use of it. E.g. a new algorithm 1399 that can do brute-force attacks exponentially faster could be 1400 existing or published right after the publication of the most recent 1401 Secure Crypto Config was published itself. 1403 9.5.2. Threat Model / Adversaries 1405 There are different possibilities in which a potential adversary 1406 could intervene during the creation as well as after the publication 1407 of the Secure Crypto Config. These attack scenarios must be 1408 considered and prevented. 1410 * *Process:* During the creation process, it is necessary for 1411 selected institutions to agree on a secure parameter set. It 1412 could be possible that one party wants to influence this process 1413 in a bad way. As a result, it could be agreed on weaker parameter 1414 sets than originally intended. 1416 * *Publication:* After the publication of the Secure Crypto Config a 1417 potential attacker could gain access to the provided files on the 1418 corresponding platform and change the content to an insecure 1419 parameter set. 1421 * *Content:* Depending on the distribution method of the Secure 1422 Crypto Config, it is also possible that an attacker could change 1423 the content of the Secure Crypto Config as man-in-the-middle. 1424 Especially if a http connection is used to obtain the Secure 1425 Crypto Config, this will be a serious problem. 1427 10. IANA Considerations 1429 * [] TODO Are there IANA Considerations? 1431 * [] TODO May add reference to own registry 1433 The data structure (see Section 5.4) defined in this document uses 1434 the JSON format as defined in [RFC8259]. 1436 11. References 1438 11.1. Normative References 1440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1441 Requirement Levels", BCP 14, RFC 2119, 1442 DOI 10.17487/RFC2119, March 1997, 1443 . 1445 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1446 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1447 . 1449 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1450 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1451 . 1453 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1454 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1455 May 2017, . 1457 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1458 Interchange Format", STD 90, RFC 8259, 1459 DOI 10.17487/RFC8259, December 2017, 1460 . 1462 11.2. Informative References 1464 [AESNI] Gueron, S., "Intel Advanced Encryption Standard (AES) 1465 Instruction Set White Paper", 2010, 1466 . 1470 [RFC2743] Linn, J., "Generic Security Service Application Program 1471 Interface Version 2, Update 1", RFC 2743, 1472 DOI 10.17487/RFC2743, January 2000, 1473 . 1475 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 1476 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 1477 . 1479 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1480 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1481 . 1483 [RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure 1484 for the Security Suitability of Cryptographic Algorithms 1485 (DSSC)", RFC 5698, DOI 10.17487/RFC5698, November 2009, 1486 . 1488 [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility 1489 Procedure for the Resource Public Key Infrastructure 1490 (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 1491 2013, . 1493 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1494 Constrained-Node Networks", RFC 7228, 1495 DOI 10.17487/RFC7228, May 2014, 1496 . 1498 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 1499 Agility and Selecting Mandatory-to-Implement Algorithms", 1500 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 1501 . 1503 Appendix A. Examples 1505 A.1. JSON Secure Crypto Config 1506 { 1507 "PolicyName" : "SCC_SecurityLevel_5", 1508 "Publisher" : [ 1509 { 1510 "name" : "Crypto Forum Research Group", 1511 "URL" : "https://irtf.org/cfrg" 1512 }, 1513 { 1514 "name" : "BSI", 1515 "URL" : "https://BSI" 1516 } 1517 ], 1518 "SecurityLevel" : "5", 1519 "Version" : "2020-0", 1520 "PolicyIssueDate" : "2020-04-20", 1521 "Expiry" : "2023-04-21", 1522 "Usage" : { 1523 "SymmetricEncryption" : [ 1524 "AES_GCM_256_96", 1525 "AES_GCM_192_96" 1526 ], 1527 "AsymmetricEncryption" : [ 1528 "RSA_SHA_512", 1529 "RSA_SHA_256" 1530 ], 1531 "Hashing" : [ 1532 "SHA3_512", 1533 "SHA_512" 1534 ], 1535 "Signing" : [ 1536 "ECDSA_512", 1537 "ECDSA_384" 1538 ], 1539 "PasswordHashing" : [ 1540 "PBKDF_SHA_512", 1541 "SHA_512_64" 1542 ] 1543 } 1544 } 1546 Figure 4: Example for JSON format 1548 Appendix B. Example Java Interface using Secure Crypto Config 1549 package org.securecryptoconfig; 1551 import java.nio.charset.Charset; 1552 import java.security.InvalidKeyException; 1553 import org.securecryptoconfig.SCCKey.KeyType; 1554 import org.securecryptoconfig.SCCKey.KeyUseCase; 1556 import COSE.CoseException; 1558 public abstract interface SecureCryptoConfigInterface { 1560 //Symmetric 1562 public AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key, PlaintextContainerInterface plaintext) 1563 throws CoseException, InvalidKeyException, SCCException; 1565 public AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key, byte[] plaintext) 1566 throws CoseException, InvalidKeyException, SCCException; 1568 public AbstractSCCCiphertext reEncryptSymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext) 1569 throws CoseException, InvalidKeyException, SCCException; 1571 public PlaintextContainerInterface decryptSymmetric(AbstractSCCKey key, AbstractSCCCiphertext sccciphertext) 1572 throws CoseException, InvalidKeyException; 1574 // Asymmetric 1576 public AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key, PlaintextContainerInterface plaintext) 1577 throws CoseException, InvalidKeyException, SCCException; 1579 public AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key, byte[] plaintext) 1580 throws CoseException, InvalidKeyException, SCCException; 1582 public AbstractSCCCiphertext reEncryptAsymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext) 1583 throws CoseException, InvalidKeyException, SCCException; 1585 public PlaintextContainerInterface decryptAsymmetric(AbstractSCCKey key, AbstractSCCCiphertext ciphertext) 1586 throws CoseException, InvalidKeyException, SCCException; 1588 // Hashing 1590 public AbstractSCCHash hash(PlaintextContainerInterface plaintext) throws CoseException, SCCException; 1591 public AbstractSCCHash hash(byte[] plaintext) throws CoseException, SCCException; 1593 public AbstractSCCHash updateHash(PlaintextContainerInterface plaintext, AbstractSCCHash hash) 1594 throws CoseException, SCCException; 1596 public AbstractSCCHash updateHash(byte[] plaintext, AbstractSCCHash hash) throws CoseException, SCCException; 1598 public boolean validateHash(PlaintextContainerInterface plaintext, AbstractSCCHash hash) 1599 throws CoseException, SCCException; 1601 public boolean validateHash(byte[] plaintext, AbstractSCCHash hash) throws CoseException, SCCException; 1603 // Digital Signature 1605 public AbstractSCCSignature sign(AbstractSCCKey key, PlaintextContainerInterface plaintext) 1606 throws CoseException, InvalidKeyException, SCCException; 1608 public AbstractSCCSignature sign(AbstractSCCKey key, byte[] plaintext) 1609 throws CoseException, InvalidKeyException, SCCException; 1611 public AbstractSCCSignature updateSignature(AbstractSCCKey key, PlaintextContainerInterface plaintext) 1612 throws CoseException, InvalidKeyException, SCCException; 1614 public AbstractSCCSignature updateSignature(AbstractSCCKey key, byte[] plaintext) 1615 throws CoseException, InvalidKeyException, SCCException; 1617 public boolean validateSignature(AbstractSCCKey key, AbstractSCCSignature signature) 1618 throws InvalidKeyException, SCCException; 1620 public boolean validateSignature(AbstractSCCKey key, byte[] signature) throws InvalidKeyException, SCCException; 1622 // Password Hashing 1624 public AbstractSCCPasswordHash passwordHash(PlaintextContainerInterface password) 1625 throws CoseException, SCCException; 1627 public AbstractSCCPasswordHash passwordHash(byte[] password) throws CoseException, SCCException; 1628 public boolean validatePasswordHash(PlaintextContainerInterface password, AbstractSCCPasswordHash passwordhash) 1629 throws CoseException, SCCException; 1631 public boolean validatePasswordHash(byte[] password, AbstractSCCPasswordHash passwordhash) 1632 throws CoseException, SCCException; 1633 } 1635 abstract interface PlaintextContainerInterface { 1637 public abstract byte[] toBytes(); 1639 public abstract String toString(Charset c); 1641 @Override 1642 public abstract String toString(); 1644 public abstract boolean validateHash(AbstractSCCHash hash) throws SCCException; 1646 public abstract boolean validatePasswordHash(AbstractSCCPasswordHash passwordHash) throws SCCException; 1648 public abstract AbstractSCCCiphertext encryptSymmetric(AbstractSCCKey key) throws SCCException; 1650 public abstract AbstractSCCCiphertext encryptAsymmetric(AbstractSCCKey key) throws SCCException; 1652 public abstract AbstractSCCSignature sign(AbstractSCCKey key) throws SCCException; 1654 public abstract AbstractSCCHash hash() throws SCCException; 1656 public abstract AbstractSCCPasswordHash passwordHash() throws SCCException; 1658 } 1660 abstract class AbstractSCCCiphertext { 1662 byte[] msg; 1663 protected AbstractSCCCiphertext(byte[] msg) { 1664 this.msg = msg; 1665 } 1667 public abstract byte[] toBytes(); 1669 @Override 1670 public abstract String toString(); 1672 public abstract PlaintextContainerInterface decryptSymmetric(AbstractSCCKey key) throws SCCException; 1674 public abstract PlaintextContainerInterface decryptAsymmetric(AbstractSCCKey key) throws SCCException; 1676 public abstract AbstractSCCCiphertext reEncryptSymmetric(AbstractSCCKey key) throws SCCException; 1678 public abstract AbstractSCCCiphertext reEncryptAsymmetric(AbstractSCCKey key) throws SCCException; 1680 } 1682 abstract class AbstractSCCKey { 1684 KeyType type; 1685 byte[] privateKey, publicKey; 1686 String algorithm; 1688 protected AbstractSCCKey(KeyType type, byte[] publicKey, byte[] privateKey, String algorithm) { 1689 this.type = type; 1690 this.publicKey = publicKey; 1691 this.privateKey = privateKey; 1692 this.algorithm = algorithm; 1694 } 1696 public abstract byte[] toBytes() throws InvalidKeyException; 1698 public abstract byte[] getPublicKeyBytes() throws InvalidKeyException; 1700 public abstract byte[] getPrivateKeyBytes() throws InvalidKeyException; 1701 public abstract KeyType getKeyType(); 1703 public abstract String getAlgorithm(); 1705 } 1707 abstract class AbstractSCCHash { 1709 byte[] hashMsg; 1711 protected AbstractSCCHash(byte[] hashMsg) { 1712 this.hashMsg = hashMsg; 1713 } 1715 public abstract byte[] toBytes(); 1717 @Override 1718 public abstract String toString(); 1720 public abstract boolean validateHash(PlaintextContainerInterface plaintext) throws SCCException; 1722 public abstract boolean validateHash(byte[] plaintext) throws SCCException; 1724 public abstract AbstractSCCHash updateHash(PlaintextContainerInterface plaintext) throws SCCException; 1726 public abstract AbstractSCCHash updateHash(byte[] plaintext) throws SCCException; 1728 } 1730 abstract class AbstractSCCPasswordHash { 1732 byte[] hashMsg; 1734 protected AbstractSCCPasswordHash(byte[] hashMsg) { 1735 this.hashMsg = hashMsg; 1736 } 1737 public abstract byte[] toBytes(); 1739 @Override 1740 public abstract String toString(); 1742 public abstract boolean validatePasswordHash(PlaintextContainerInterface password) throws SCCException; 1744 public abstract boolean validatePasswordHash(byte[] password) throws SCCException; 1746 } 1748 abstract class AbstractSCCSignature { 1749 byte[] signatureMsg; 1751 protected AbstractSCCSignature(byte[] signatureMasg) { 1752 this.signatureMsg = signatureMasg; 1753 } 1755 public abstract byte[] toBytes(); 1757 @Override 1758 public abstract String toString(); 1760 public abstract boolean validateSignature(AbstractSCCKey key) throws SCCException; 1762 public abstract AbstractSCCSignature updateSignature(PlaintextContainerInterface plaintext, AbstractSCCKey key) 1763 throws SCCException; 1765 } 1767 Figure 5: Example for a JAVA SCC API 1769 Acknowledgments 1771 * [ ] TODO acknowledge. 1773 Authors' Addresses 1774 Kai Mindermann 1775 iC Consult GmbH 1777 Email: kai.mindermann@ic-consult.com 1779 Lisa Teis 1781 Email: lisateis102@gmail.com