idnits 2.17.1 draft-mattsson-cfrg-det-sigs-with-noise-04.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 February 2022) is 793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-irtf-cfrg-frost-02 -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) -- Obsolete informational reference (is this intentional?): RFC 8208 (Obsoleted by RFC 8608) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Preuß Mattsson 3 Internet-Draft E. Thormarker 4 Updates: 6979, 8032 (if approved) S. Ruohomaa 5 Intended status: Informational Ericsson 6 Expires: 19 August 2022 15 February 2022 8 Deterministic ECDSA and EdDSA Signatures with Additional Randomness 9 draft-mattsson-cfrg-det-sigs-with-noise-04 11 Abstract 13 Deterministic elliptic-curve signatures such as deterministic ECDSA 14 and EdDSA have gained popularity over randomized ECDSA as their 15 security do not depend on a source of high-quality randomness. 16 Recent research has however found that implementations of these 17 signature algorithms may be vulnerable to certain side-channel and 18 fault injection attacks due to their determinism. One countermeasure 19 to such attacks is to re-add randomness to the otherwise 20 deterministic calculation of the per-message secret number. This 21 document updates RFC 6979 and RFC 8032 to recommend constructions 22 with additional randomness for deployments where side-channel attacks 23 and fault injection attacks are a concern. The updates are invisible 24 to the validator of the signature and compatible with existing ECDSA 25 and EdDSA validators. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 19 August 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 62 3. Updates to RFC 8032 (EdDSA) . . . . . . . . . . . . . . . . . 5 63 4. Updates to RFC 6979 (Deterministic ECDSA) . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. For discussion (to be removed in the future) . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 7.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 In Elliptic-Curve Cryptography (ECC) signature algorithms, the per- 75 message secret number has traditionally been generated from a random 76 number generator (RNG). The security of such algorithms depends on 77 the cryptographic quality of the random number generation and biases 78 in the randomness may have catastrophic effects such as compromising 79 private keys (see e.g., [Bernstein19]). Repeated per-message secret 80 numbers have caused several severe security accidents in practice. 81 As stated in [RFC6979], the need for a cryptographically secure 82 source of randomness is also a hindrance to deployment of randomized 83 ECDSA [FIPS-186-4] in architectures where secure random number 84 generation is challenging, in particular, embedded IoT systems and 85 smartcards. [ABFJLM17] does however state that smartcards typically 86 have a high-quality RNG on board, which makes it significantly easier 87 and faster to use the RNG instead of doing a hash computation. 89 In deterministic ECC signatures schemes such as Deterministic 90 Elliptic Curve Digital Signature Algorithm (ECDSA) [RFC6979] and 91 Edwards-curve Digital Signature Algorithm (EdDSA) [RFC8032], the per- 92 message secret number is instead generated in a fully deterministic 93 way as a function of the message and the private key. Except for key 94 generation, the security of such deterministic signatures does not 95 depend on a source of high-quality randomness. This makes 96 verification of implementations easier. As they are presumed to be 97 safer, deterministic signatures have gained popularity and are 98 referenced and recommended by a large number of recent RFCs [RFC8037] 99 [RFC8080] [RFC8152] [RFC8225] [RFC8387] [RFC8410] [RFC8411] [RFC8419] 100 [RFC8420] [RFC8422] [RFC8446] [RFC8463] [RFC8550] [RFC8591] [RFC8624] 101 [RFC8208] [RFC8608]. 103 Side-channel attacks are potential attack vectors for implementations 104 of cryptographic algorithms. Side-Channel attacks can in general be 105 classified along three orthogonal axes: passive vs. active, physical 106 vs. logical, and local vs. remote [SideChannel]. It has been 107 demonstrated how side-channel attacks such as power analysis 108 [BCPST14] and timing attacks [Minerva19] [TPM-Fail19] allow for 109 practical recovery of the private key in some existing 110 implementations of randomized ECDSA. [BSI] summarizes minimum 111 requirements for evaluating side-channel attacks of elliptic curve 112 implementations and writes that deterministic ECDSA and EdDSA 113 requires extra care. The deterministic ECDSA specification [RFC6979] 114 notes that the deterministic generation of per-message secret numbers 115 may be useful to an attacker in some forms of side-channel attacks 116 and as stated in [Minerva19], deterministic signatures like [RFC6979] 117 and [RFC8032] might help an attacker to reduce the noise in the side- 118 channel when the same message it signed multiple times. Recent 119 research [SH16] [BP16] [RP17] [ABFJLM17] [SBBDS17] [PSSLR17] [SB18] 120 [WPB19] [AOTZ19] [FG19] have theoretically and experimentally 121 analyzed the resistance of deterministic ECC signature algorithms 122 against side-channel and fault injection attacks. The conclusions 123 are that deterministic signature algorithms have theoretical 124 weaknesses against certain instances of these types of attacks and 125 that the attacks are practically feasibly in some environments. 126 These types of attacks may be of particular concern for hardware 127 implementations such as embedded IoT devices and smartcards where the 128 adversary can be assumed to have access to the device to induce 129 faults and measure its side-channels such as timing information, 130 power consumption, electromagnetic leaks, or sound with low signal- 131 to-noise ratio. A good summary of fault attacks in given by [Cao20]. 132 See also the discussions and references in [Comments-186-5]. 134 Fault attacks may also be possible without physical access to the 135 device. RowHammer [RowHammer14] showed how an attacker to induce 136 DRAM bit-flips in memory areas the attacker should not have access 137 to. Plundervolt [Plundervolt19] showed how an attacker with root 138 access can use frequency and voltage scaling interfaces to induce 139 faults that bypass even secure execution technologies. RowHammer can 140 e.g., be used in operating systems with several processes or cloud 141 scenarios with virtualized servers. Protocols like TLS, SSH, and 142 IKEv2 that adds a random number to the message to be signed mitigate 143 some types of attacks [PSSLR17]. 145 Government agencies are clearly concerned about these attacks. In 146 [Notice-186-5] and [Draft-186-5], NIST warns about side-channel and 147 fault injection attacks, but states that deterministic ECDSA may be 148 desirable for devices that lack good randomness. BSI has published 149 [BSI] and researchers from BSI have co-authored two research papers 150 [ABFJLM17] [PSSLR17] on attacks on deterministic signatures. For 151 many industries it is important to be compliant with both RFCs and 152 government publications, alignment between IETF, NIST, and BSI 153 recommendations would be preferable. 155 Note that deriving per-message secret number deterministically, is 156 also insecure in a multi-party signature setting 157 [I-D.irtf-cfrg-frost]. 159 One countermeasure to entropy failures, side-channel attacks, and 160 fault injection attacks recommended by [Langley13] [RP17] [ABFJLM17] 161 [SBBDS17] [PSSLR17] [SB18] [AOTZ19] [FG19] and implemented in 162 [OpenSSL13a] [OpenSSL13b] [XEdDSA] [libSodium] [libHydrogen] is to 163 generate the per-message secret number from a random string, a secret 164 key, and the message. This combines the security benefits of fully 165 randomized per-message secret numbers with the security benefits of 166 fully deterministic secret numbers. Such a construction protects 167 against key compromise due to weak random number generation, but 168 still effectively prevents many side-channel and fault injection 169 attacks that exploit determinism. Such a construction require minor 170 changes to the implementation and does not increase the number of 171 elliptic curve point multiplications and is therefore suitable for 172 constrained IoT. Adding randomness to EdDSA is not compliant with 173 [RFC8032]. [Kampanakis16] describes an alternative [FIPS-186-4] 174 compliant approach where message specific pseudo-random information 175 is used as an additional input to the random number generation to 176 create per-message secret number. [Bernstein14] states that 177 generation of the per-message secret number from a subset of a random 178 string, a secret key, the message, and a message counter is common in 179 DSA/ECDSA implementations. 181 This document updates [RFC6979] and [RFC8032] to recommend 182 constructions with additional randomness for deployments where side- 183 channel and fault injection attacks are a concern. The updates are 184 invisible to the validator of the signature. Produced signatures 185 remain fully compatible with unmodified ECDSA and EdDSA verifiers and 186 existing key pairs can continue to be used. As the precise use of 187 the noise is specified, test vectors can still be produced and 188 implementations can be tested against them. 190 2. Conventions Used in This Document 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 3. Updates to RFC 8032 (EdDSA) 200 For Ed25519ph, Ed25519ctx, and Ed25519: In deployments where side- 201 channel and fault injection attacks are a concern, the following step 202 is RECOMMENDED instead of step (2) in Section 5.1.6 of [RFC8032]: 204 2. Compute SHA-512(dom2(F, C) || Z || prefix || 000... || PH(M)), 205 where M is the message to be signed, Z is 32 octets of random 206 data, the number of zeroes 000... is chosen so that the length 207 of (dom2(F, C) || Z || prefix || 000...) is a multiple of 128 208 octets. Interpret the 64-octet digest as a little-endian 209 integer r. 211 For Ed448ph and Ed448: In deployments where side-channel and fault 212 injection attacks are a concern, the following step is RECOMMENDED 213 instead of step (2) in Section 5.3.6 of [RFC8032]: 215 2. Compute SHAKE256(dom4(F, C) || Z || prefix || 000... || PH(M), 216 114), where M is the message to be signed, and Z is 57 octets 217 of random data, the number of zeroes 000... is chosen so that 218 the length of (dom4(F, C) || Z || prefix || 000...) is a 219 multiple of 136 octets. F is 1 for Ed448ph, 0 for Ed448, and C 220 is the context to use. Interpret the 114-octet digest as a 221 little-endian integer r. 223 4. Updates to RFC 6979 (Deterministic ECDSA) 225 For Deterministic ECDSA: In existing ECDSA deployments where side- 226 channel and fault injection attacks are a concern, the following 227 steps are RECOMMENDED instead of steps (d) and (f) in Section 3.2 of 228 [RFC6979]: 230 d. Set: 232 K = HMAC_K(V || 0x00 || Z || int2octets(x) || 000... || 233 bits2octets(h1)) where '||' denotes concatenation. In other 234 words, we compute HMAC with key K, over the concatenation of 235 the following, in order: the current value of V, a sequence of 236 eight bits of value 0, random data Z (of the same length as 237 int2octets(x)), the encoding of the (EC)DSA private key x, a 238 sequence of zero bits 000... chosen so that the length of 239 (V || 0x00 || Z || int2octets(x) || 000...) is equal to the 240 block size of the hash function, and the hashed message 241 (possibly truncated and extended as specified by the 242 bits2octets transform). The HMAC result is the new value of K. 243 Note that the private key x is in the [1, q-1] range, hence a 244 proper input for int2octets, yielding rlen bits of output, 245 i.e., an integral number of octets (rlen is a multiple of 8). 247 f. Set: 249 K = HMAC_K(V || 0x01 || Z || int2octets(x) || 000... || 250 bits2octets(h1)) 252 When ECDSA is used with SHAKE [SHA3] the HMAC construction above MAY 253 be used but it is RECOMMENDED to use the more efficient KMAC 254 construction [KMAC]. SHAKE is a variable-length hash function 255 defined as SHAKE(M, d) where the output is a d-bits-long digest of 256 message M. When ECDSA is used with SHAKE128(M, d), it is RECOMMENDED 257 to replace HMAC(K, M) with KMAC128(K, M, d, ""). When ECDSA is used 258 with SHAKE256(M, d), it is RECOMMENDED to replace HMAC(K, M) with 259 KMAC256(K, M, d, ""). [RFC8692] and [Draft-186-5] define the use of 260 SHAKE128 with an output length of 256 bits and SHAKE256 with an 261 output length or 512 bits. 263 In new deployments, where side-channel and fault injection attacks 264 are a concern, EdDSA with additional randomness as specified in 265 Section 3 is RECOMMENDED. 267 5. Security Considerations 269 The constructions in this document follows the high-level approach in 270 [XEdDSA] to calculate the per-message secret number from the hash of 271 the private key and the message, but add additional randomness into 272 the calculation for greater resilience. This does not re-introduce 273 the strong security requirement of randomness needed by randomized 274 ECDSA [FIPS-186-4]. The randomness of Z does not need to be perfect, 275 but SHALL be generated by a cryptographically secure pseudo random 276 number generator (PRNG) and SHALL be secret. Even if the same random 277 number Z is used to sign two different messages, the security will be 278 the same as deterministic ECDSA and EdDSA and an attacker will not be 279 able to compromise the private key with algebraic means as in fully 280 randomized ECDSA [FIPS-186-4]. With the construction specified in 281 this document, two signatures over two equal messages are different 282 which prevents information leakage in use cases where signatures but 283 not messages are public. The construction in this document place the 284 additional randomness before the message to align with randomized 285 hashing methods. 287 [SBBDS17] states that [XEdDSA] would not prevent their attack due to 288 insufficient mixing of the hashed private key with the additional 289 randomness. [SBBDS17] suggest a construction where the randomness is 290 padded with zeroes so that the first 1024-bit SHA-512 block is 291 composed only of the hashed private key and the random value, but not 292 the message. The construction in this document follows this 293 recommendation and pads with zeroes so that the first block is 294 composed only of the hashed private key and the random value, but not 295 the message. 297 Another countermeasure to fault attacks is to force the signer to 298 verify the signature in the last step of the signature generation or 299 to calculate the signature twice and compare the results. These 300 countermeasure would catch a single fault but would not protect 301 against attackers that are able to precisely inject faults several 302 times [RP17] [PSSLR17] [SB18]. Adding an additional sign or 303 verification operation would also significantly affect performance, 304 especially verification which is a heavier operation than signing in 305 ECDSA and EdDSA. 307 [ABFJLM17] suggests using both additional randomness and a counter, 308 which makes the signature generation stateful. While most used 309 signatures have traditionally been stateless, stateful signatures 310 like XMSS [RFC8391] and LMS [RFC8554] have now been standardized and 311 deployed. [RFC8937] specifies a PRNG construction with a random 312 seed, a secret key, a context string, and a nonce, which makes the 313 random number generation stateful. The generation of the per-message 314 secret number in this document is not stateful, but it can be used 315 with a stateful PRNG. The exact construction in [RFC8937] is however 316 not recommended in deployments where side-channel and fault injection 317 attacks are a concern as it relies on deterministic signatures. 319 With the construction in this document, the repetition of the same 320 per-message secret number for two different messages is highly 321 unlikely even with an imperfect random number generator, but not 322 impossible. As an extreme countermeasure, previously used secret 323 numbers can be tracked to ensure their uniqueness for a given key, 324 and a different random number can be used if a collision is detected. 325 This document does not mandate nor stop an implementation from taking 326 such a precaution. 328 Implementations need to follow best practices on how to protect 329 against all side-channel attacks, not just attacks that exploit 330 determinism, see for example [BSI]. 332 6. For discussion (to be removed in the future) 334 * removal of "noise" from filename. Will be done if/when the draft 335 is uploaded as adopted (draft-irtf-....) 337 * Strong consensus to change the name "Deterministic ECDSA and EdDSA 338 Signatures with Additional Randomness". The signatures are 339 obliously not deteministic anymore. Several suggestions for new 340 names: "message-dependent", "message-keyed", "entropy stealing", 341 "entropy combining", "whitening", "keyed entropy whitening", 342 "hedged", "noise". 344 * Ordering of the parameters in "dom2(F, C) || Z || prefix || 345 000... || PH(M)" in Ed25519 and similar in Ed448 and ECDSA. There 346 has also been sugestion to use a larger Z and to use several 347 paddings 000.... 349 * Ilari Liusvaara pointed out attacks using the context that needs 350 to be considered. Some statements "first block is composed only 351 of the hashed private key and the random value" in the document 352 are not true for Ed25519ctx and Ed448ctx. 354 * Jim Schaad: Is there any advantage to stealing one of the zeros 355 from the end padding and using it to pad between 'Z' and 'x' in 356 the construction? I would assume that it should use the '0'/'1' 357 construction between steps d and f. 359 * Jim Schaad: Is there any advantage to padding with 0x01 in step f 360 rather than 0x00? 362 * Rene Stuik: MUST instead of RECOMMENDED. 364 7. References 366 7.1. Normative References 368 [FIPS-186-4] 369 Department of Commerce, N. S., "Digital Signature Standard 370 (DSS)", NIST FIPS PUB 186-4 , July 2013, 371 . 374 [KMAC] National Institute of Standards and Technology (NIST), 375 "SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and 376 ParallelHash", NIST SP 800-185 , December 2016, 377 . 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, 382 DOI 10.17487/RFC2119, March 1997, 383 . 385 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 386 Algorithm (DSA) and Elliptic Curve Digital Signature 387 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 388 2013, . 390 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 391 Signature Algorithm (EdDSA)", RFC 8032, 392 DOI 10.17487/RFC8032, January 2017, 393 . 395 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 396 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 397 May 2017, . 399 [RFC8692] Kampanakis, P. and Q. Dang, "Internet X.509 Public Key 400 Infrastructure: Additional Algorithm Identifiers for 401 RSASSA-PSS and ECDSA Using SHAKEs", RFC 8692, 402 DOI 10.17487/RFC8692, December 2019, 403 . 405 [SHA3] National Institute of Standards and Technology (NIST), 406 "SHA-3 Standard: Permutation-Based Hash and Extendable- 407 Output Functions", NIST FIPS PUB 202 , August 2015, 408 . 411 7.2. Informative References 413 [ABFJLM17] Ambrose, C., Bos, J., Fay, B., Joye, M., Lochter, M., and 414 B. Murray, "Differential Attacks on Deterministic 415 Signatures", October 2017, 416 . 418 [AOTZ19] Aranha, D., Orlandi, C., Takahashi, A., and G. Zaverucha, 419 "Security of Hedged Fiat-Shamir Signatures under Fault 420 Attacks", September 2019, 421 . 423 [BCPST14] Batina, L., Chmielewski, L., Papachristodoulou, L., 424 Schwabe, P., and M. Tunstall, "Online Template Attacks", 425 December 2014, . 428 [Bernstein14] 429 Bernstein, D., "How to design an elliptic-curve signature 430 system", March 2014, 431 . 433 [Bernstein19] 434 Bernstein, D., "Why EdDSA held up better than ECDSA 435 against Minerva", October 2019, 436 . 438 [BP16] Barenghi, A. and G. Pelosi, "A Note on Fault Attacks 439 Against Deterministic Signature Schemes (Short Paper)", 440 September 2016, . 443 [BSI] Bundesamt für Sicherheit in der Informationstechnik, 444 "Minimum Requirements for Evaluating Side-Channel Attack 445 Resistance of Elliptic Curve Implementations", November 446 2016, 447 . 451 [Cao20] Weiqiong Cao, Hongsong Shi, Hua Chen, Jiazhe Chen, Limin 452 Fan, and Wenling Wu, "Lattice-based Fault Attacks on 453 Deterministic Signature Schemes of ECDSA and EdDSA", June 454 2020, . 456 [Comments-186-5] 457 "Public Comments Received on Draft FIPS 186-5: Digital 458 Signature Standards (DSS)", March 2021, 459 . 462 [Draft-186-5] 463 National Institute of Standards and Technology (NIST), 464 "FIPS PUB 186-5 (Draft)", October 2019, 465 . 468 [FG19] Fischlin, M. and F. Günther, "Modeling Memory Faults in 469 Signature and Encryption Schemes", September 2019, 470 . 472 [I-D.irtf-cfrg-frost] 473 Connolly, D., Komlo, C., Goldberg, I., and C. A. Wood, 474 "Two-Round Threshold Schnorr Signatures with FROST", Work 475 in Progress, Internet-Draft, draft-irtf-cfrg-frost-02, 12 476 February 2022, . 479 [Kampanakis16] 480 Kampanakis, P., "FIPS and Deterministic ECDSA: Achieving 481 robust security and conformance", December 2016, 482 . 485 [Langley13] 486 Langley, A., "Sudden Death Entropy Failures", June 2013, 487 . 490 [libHydrogen] 491 "The Hydrogen library", n.d., 492 . 494 [libSodium] 495 "The Sodium library", n.d., 496 . 498 [Minerva19] 499 Centre for Research on Cryptography and Security (CRoCS), 500 "Minerva", October 2019, 501 . 503 [Notice-186-5] 504 National Institute of Standards and Technology (NIST), 505 "Request for Comments on FIPS 186-5 and SP 800-186", 506 October 2019, . 510 [OpenSSL13a] 511 "Add secure DSA nonce flag", n.d., 512 . 515 [OpenSSL13b] 516 "Make `safe' (EC)DSA nonces the default", n.d., 517 . 520 [Plundervolt19] 521 Murdock, K., Oswald, D., Garcia, F., Van Bulck, J., Gruss, 522 D., and F. Piessens, "How a little bit of undervolting can 523 cause a lot of problems", December 2019, 524 . 526 [PSSLR17] Poddebniak, D., Somorovsky, J., Schinzel, S., Lochter, M., 527 and P. Rösler, "Attacking Deterministic Signature Schemes 528 using Fault Attacks", October 2017, 529 . 531 [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) 532 and Signatures in JSON Object Signing and Encryption 533 (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, 534 . 536 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 537 Algorithm (EdDSA) for DNSSEC", RFC 8080, 538 DOI 10.17487/RFC8080, February 2017, 539 . 541 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 542 RFC 8152, DOI 10.17487/RFC8152, July 2017, 543 . 545 [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 546 Formats, and Signature Formats", RFC 8208, 547 DOI 10.17487/RFC8208, September 2017, 548 . 550 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 551 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 552 . 554 [RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical 555 Considerations and Implementation Experiences in Securing 556 Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387, 557 May 2018, . 559 [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. 560 Mohaisen, "XMSS: eXtended Merkle Signature Scheme", 561 RFC 8391, DOI 10.17487/RFC8391, May 2018, 562 . 564 [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for 565 Ed25519, Ed448, X25519, and X448 for Use in the Internet 566 X.509 Public Key Infrastructure", RFC 8410, 567 DOI 10.17487/RFC8410, August 2018, 568 . 570 [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the 571 Cryptographic Algorithm Object Identifier Range", 572 RFC 8411, DOI 10.17487/RFC8411, August 2018, 573 . 575 [RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature 576 Algorithm (EdDSA) Signatures in the Cryptographic Message 577 Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 578 2018, . 580 [RFC8420] Nir, Y., "Using the Edwards-Curve Digital Signature 581 Algorithm (EdDSA) in the Internet Key Exchange Protocol 582 Version 2 (IKEv2)", RFC 8420, DOI 10.17487/RFC8420, August 583 2018, . 585 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic 586 Curve Cryptography (ECC) Cipher Suites for Transport Layer 587 Security (TLS) Versions 1.2 and Earlier", RFC 8422, 588 DOI 10.17487/RFC8422, August 2018, 589 . 591 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 592 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 593 . 595 [RFC8463] Levine, J., "A New Cryptographic Signature Method for 596 DomainKeys Identified Mail (DKIM)", RFC 8463, 597 DOI 10.17487/RFC8463, September 2018, 598 . 600 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 601 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 602 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, 603 April 2019, . 605 [RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali 606 Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, 607 April 2019, . 609 [RFC8591] Campbell, B. and R. Housley, "SIP-Based Messaging with S/ 610 MIME", RFC 8591, DOI 10.17487/RFC8591, April 2019, 611 . 613 [RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key 614 Formats, and Signature Formats", RFC 8608, 615 DOI 10.17487/RFC8608, June 2019, 616 . 618 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 619 Requirements and Usage Guidance for DNSSEC", RFC 8624, 620 DOI 10.17487/RFC8624, June 2019, 621 . 623 [RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 624 and C. Wood, "Randomness Improvements for Security 625 Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020, 626 . 628 [RowHammer14] 629 Kim, Y., Daly, R., Kim, J., Fallin, C., Lee, J., Lee, D., 630 Wilkerson, C., and K. Mutlu, "Flipping Bits in Memory 631 Without Accessing Them: An Experimental Study of DRAM 632 Disturbance Errors", June 2014, 633 . 636 [RP17] Romailler, Y. and S. Pelissier, "Practical fault attack 637 against the Ed25519 and EdDSA signature schemes", 638 September 2017, 639 . 641 [SB18] Samwel, N. and L. Batina, "Practical Fault Injection on 642 Deterministic Signatures: The Case of EdDSA", April 2018, 643 . 645 [SBBDS17] Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. 646 Susella, "Breaking Ed25519 in WolfSSL", October 2017, 647 . 649 [SH16] Seuschek, H., Heyszl, J., and F. De Santis, "A Cautionary 650 Note: Side-Channel Leakage Implications of Deterministic 651 Signature Schemes", January 2016, 652 . 655 [SideChannel] 656 Spreitzer, R., Moonsamy, V., Korak, T., and S. Mangard, 657 "Systematic Classification of Side-Channel Attacks: A Case 658 Study for Mobile Devices", December 2017, 659 . 661 [TPM-Fail19] 662 Moghimi, D., Sunar, B., Eisenbarth, T., and N. Heninge, 663 "TPM-FAIL: TPM meets Timing and Lattice Attacks", October 664 2019, . 666 [WPB19] Weissbart, L., Picek, S., and L. Batina, "One trace is all 667 it takes: Machine Learning-based Side-channel Attack on 668 EdDSA", July 2019, . 670 [XEdDSA] Signal, "The XEdDSA and VXEdDSA Signature Schemes", 671 October 2016, 672 . 674 Acknowledgments 676 The authors want to thank Tony Arcieri, Uri Blumenthal, Carsten 677 Bormann, Phillip Hallam-Baker, Chelsea Komlo, Quynh Dang, Janos 678 Follath, Ilari Liusvaara, Jim Schaad, and Ruggero Susella for their 679 valuable comments and feedback. 681 Authors' Addresses 683 John Preuß Mattsson 684 Ericsson 686 Email: john.mattsson@ericsson.com 688 Erik Thormarker 689 Ericsson 691 Email: erik.thormarker@ericsson.com 692 Sini Ruohomaa 693 Ericsson 695 Email: sini.ruohomaa@ericsson.com