Update draft-irtf-cfrg-det-sigs-with-noise.md

draft-irtf-cfrg-det-sigs-with-noise.md

@@ -424,15 +424,15 @@ Side-channel Attack on EdDSA"
 
 --- abstract
 
-Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security do not depend on a source of high-quality randomness. Recent research has however found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their determinism. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend constructions with additional randomness for deployments where side-channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators.
+Deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized ECDSA as their security do not depend on a source of high-quality randomness. Recent research, however, has found that implementations of these signature algorithms may be vulnerable to certain side-channel and fault injection attacks due to their deterministic nature. One countermeasure to such attacks is hedged signatures where the calculation of the per-message secret number includes both fresh randomness and the message. This document updates RFC 6979 and RFC 8032 to recommend constructions with additional randomness for deployments where side-channel attacks and fault injection attacks are a concern. The updates are invisible to the validator of the signature and compatible with existing ECDSA and EdDSA validators.
 
 --- middle
 
 # Introduction
 
 In Elliptic-Curve Cryptography (ECC) signature algorithms, the per-message secret number has traditionally been generated from a random number generator (RNG). The security of such algorithms depends on the cryptographic quality of the random number generation and biases in the randomness may have catastrophic effects such as compromising private keys (see e.g., {{Bernstein19}}). Repeated per-message secret numbers have caused several severe security accidents in practice. As stated in {{RFC6979}}, the need for a cryptographically secure source of randomness is also a hindrance to deployment of randomized ECDSA {{FIPS-186-5}} in architectures where secure random number generation is challenging, in particular, embedded IoT systems and smartcards. {{ABFJLM17}} does however state that smartcards typically have a high-quality RNG on board, which makes it significantly easier and faster to use the RNG instead of doing a hash computation.
 
-In deterministic ECC signatures schemes such as Deterministic Elliptic Curve Digital Signature Algorithm (ECDSA) {{RFC6979}}{{FIPS-186-5}} and Edwards-curve Digital Signature Algorithm (EdDSA) {{RFC8032}}, the per-message secret number is instead generated in a fully deterministic way as a function of the message and the private key. Except for key generation, the security of such deterministic signatures does not depend on a source of high-quality randomness. This makes verification of implementations easier. As they are presumed to be safer, deterministic signatures have gained popularity and are referenced and recommended by a large number of recent RFCs {{RFC8037}} {{RFC8080}} {{RFC8225}} {{RFC8387}} {{RFC8410}} {{RFC8411}} {{RFC8419}} {{RFC8420}} {{RFC8422}} {{RFC8446}} {{RFC8463}} {{RFC8550}} {{RFC8591}} {{RFC8608}} {{RFC8624}} {{RFC9053}}.
+In deterministic ECC signatures schemes such as Deterministic Elliptic Curve Digital Signature Algorithm (ECDSA) {{RFC6979}}{{FIPS-186-5}} and Edwards-curve Digital Signature Algorithm (EdDSA) {{RFC8032}}, the per-message secret number is instead generated in a fully deterministic way as a function of the message and the private key. Except for key generation, the security of such deterministic signatures does not rely on a source of high-quality randomness. This makes verification of implementations easier. As they are presumed to be safer, deterministic signatures have gained popularity and are referenced and recommended by a large number of recent RFCs {{RFC8037}} {{RFC8080}} {{RFC8225}} {{RFC8387}} {{RFC8410}} {{RFC8411}} {{RFC8419}} {{RFC8420}} {{RFC8422}} {{RFC8446}} {{RFC8463}} {{RFC8550}} {{RFC8591}} {{RFC8608}} {{RFC8624}} {{RFC9053}}.
 
 Side-channel attacks are potential attack vectors for implementations of cryptographic algorithms. Side-Channel attacks can in general be classified along three orthogonal axes: passive vs. active, physical vs. logical, and local vs. remote {{SideChannel}}. It has been demonstrated how side-channel attacks such as power analysis {{BCPST14}} and timing attacks {{Minerva19}} {{TPM-Fail19}} allow for practical recovery of the private key in some existing implementations of randomized ECDSA. {{BSI}} summarizes minimum requirements for evaluating side-channel attacks of elliptic curve implementations and writes that deterministic ECDSA and EdDSA requires extra care. The deterministic ECDSA specification {{RFC6979}} notes that the deterministic generation of per-message secret numbers may be useful to an attacker in some forms of side-channel attacks and as stated in {{Minerva19}}, deterministic signatures like {{RFC6979}} and {{RFC8032}} might help an attacker to reduce the noise in the side-channel when the same message it signed multiple times. Recent research {{SH16}} {{BP16}} {{RP17}} {{ABFJLM17}} {{SBBDS17}} {{PSSLR17}} {{SB18}} {{WPB19}} {{AOTZ19}} {{FG19}} have theoretically and experimentally analyzed the resistance of deterministic ECC signature algorithms against side-channel and fault injection attacks. The conclusions are that deterministic signature algorithms have theoretical weaknesses against certain instances of these types of attacks and that the attacks are practically feasibly in some environments. These types of attacks may be of particular concern for hardware implementations such as embedded IoT devices and smartcards where the adversary can be assumed to have access to the device to induce faults and measure its side-channels such as timing information, power consumption, electromagnetic leaks, or sound with low signal-to-noise ratio. A good summary of fault attacks in given by {{Cao20}}. See also the discussions and references in {{Comments-186-5}}.
 
@@ -518,15 +518,15 @@ In new deployments, where side-channel and fault injection attacks are a concern
 
 # Security Considerations
 
-The constructions in this document follows the high-level approach in {{XEdDSA}} to calculate the per-message secret number from the hash of the private key and the message, but add additional randomness into the calculation for greater resilience. This does not re-introduce the strong security requirement of randomness needed by randomized ECDSA {{FIPS-186-5}}. The randomness of Z does not need to be perfect but SHALL be generated by a cryptographically secure pseudo random number generator (PRNG) and SHALL be secret. Even if the same random number Z is used to sign two different messages, the security will be the same as deterministic ECDSA and EdDSA and an attacker will not be able to compromise the private key with algebraic means as in fully randomized ECDSA {{FIPS-186-5}}. With the construction specified in this document, two signatures over two equal messages are different which prevents information leakage in use cases where signatures but not messages are public. The construction in this document place the additional randomness before the message to align with randomized hashing methods.
+The constructions in this document follows the high-level approach in {{XEdDSA}} to calculate the per-message secret number from the hash of the private key and the message, but add additional randomness into the calculation for greater resilience. This does not re-introduce the strong security requirement of randomness needed by randomized ECDSA {{FIPS-186-5}}. The randomness of Z need not be perfect but SHALL be generated by a cryptographically secure pseudo random number generator (CSPRNG) and SHALL be secret. Even if the same random number Z is used to sign two different messages, the security will be the same as deterministic ECDSA and EdDSA and an attacker will not be able to compromise the private key with algebraic means as in fully randomized ECDSA {{FIPS-186-5}}. With the construction specified in this document, two signatures over two equal messages are different which prevents information leakage in use cases where signatures but not messages are public. The construction in this document place the additional randomness before the message to align with randomized hashing methods.
 
 {{SBBDS17}} states that {{XEdDSA}} would not prevent their attack due to insufficient mixing of the hashed private key with the additional randomness. The construction in this document aims to mitigate fault injection attacks that leverage determinism in deterministic ECDSA and EdDSA signatures (see e.g., {{ABFJLM17}}), by randomizing nonce generation. Fault injection attacks that achieve instruction skipping as in e.g., Section 3.4 of {{ABFJLM17}} are not necessarily stopped. It seems to be possible to, at the same time, also mitigate attacks that use first order differential power analysis (DPA) against the hash computation of deterministic nonces in EdDSA and ECDSA (see e.g., {{ABFJLM17}}{{SBBDS17}}). The mitigation in this document agrees with one mentioned in {{ABFJLM17}} and appears to be as effective against the referenced first order DPA attacks as the one in {{SBBDS17}}.
 
 Another countermeasure to fault attacks is to force the signer to verify the signature in the last step of the signature generation or to calculate the signature twice and compare the results. These countermeasure would catch a single fault but would not protect against attackers that are able to precisely inject faults several times {{RP17}} {{PSSLR17}} {{SB18}}. Adding an additional sign or verification operation would also significantly affect performance, especially verification which is a heavier operation than signing in ECDSA and EdDSA.
 
 {{ABFJLM17}} suggests using both additional randomness and a counter, which makes the signature generation stateful. While most used signatures have traditionally been stateless, stateful signatures like XMSS {{RFC8391}} and LMS {{RFC8554}} have now been standardized and deployed. {{RFC8937}} specifies a PRNG construction with a random seed, a secret key, a context string, and a nonce, which makes the random number generation stateful. The generation of the per-message secret number in this document is not stateful, but it can be used with a stateful PRNG. The exact construction in {{RFC8937}} is however not recommended in deployments where side-channel and fault injection attacks are a concern as it relies on deterministic signatures.
 
-With the construction in this document, the repetition of the same per-message secret number for two different messages is highly unlikely even with an imperfect random number generator, but not impossible. As an extreme countermeasure, previously used secret numbers can be tracked to ensure their uniqueness for a given key, and a different random number can be used if a collision is detected. This document does not mandate nor stop an implementation from taking such a precaution.
+With the construction in this document, the repetition of the same per-message secret number for two different messages is highly unlikely even with an imperfect random number generator, but not impossible. As an extreme countermeasure, previously used secret numbers can be tracked to ensure their uniqueness for a given key, and a different random number can be used if a collision is detected. This document neither mandates nor prohibits implementations from taking such precautions.
 
 Implementations need to follow best practices on how to protect against all side-channel attacks, not just attacks that exploit determinism, see for example {{BSI}}.