Merge pull request #20 from sophieschmieg/patch-1

Author: emlun

draft-lundberg-cose-two-party-signing-algs.md

@@ -67,6 +67,21 @@ normative:
     title: "SEC 1: Elliptic Curve Cryptography"
 
 informative:
+  FALCON:
+    target: https://falcon-sign.info/
+    title: 'FALCON: Fast-Fourier Lattice-based Compact Signatures over NTRU'
+    author:
+    - fullname: Pierre-Alain Fouque
+    - fullname: Jeffrey Hoffstein
+    - fullname: Paul Kirchner
+    - fullname: Vadim Lyubashevsky
+    - fullname: Thomas Pornin
+    - fullname: Thomas Prest
+    - fullname: Thomas Ricosset
+    - fullname: Gregor Seiler
+    - fullname: William Whyte
+    - fullname: Zhenfei Zhang
+    date: 2017
   FIPS-201:
     target: https://doi.org/10.6028/NIST.SP.800-73pt2-5
     title: 'Interfaces for Personal Identity Verification: Part 2 – PIV Card Application Card Command Interface'
@@ -174,6 +189,7 @@ Since different signature algorithms digest the message in different ways
 and at different stages of the algorithm,
 it is not possible for a cryptographic API to specify that, for example, "the hash digest is computed by the caller"
 generically for all algorithms.
+Security considerations for this split may also differ between algorithms.
 Instead, the algorithm identifiers defined in this specification
 enable the parties of that cryptographic API to signal precisely, for each signature algorithm individually,
 which steps of the algorithm are performed by which party.
@@ -191,10 +207,13 @@ Some signature algorithms,
 such as PureEdDSA [RFC8032],
 by their design, cannot be split in this way, and therefore cannot be assigned split signing algorithm identifiers.
 However, if such a signature algorithm defines a "pre-hashed" variant,
-such as Ed25519ph [RFC8032],
 that "pre-hashed" algorithm can be assigned a split signing algorithm identifier,
 enabling the pre-hashing step to be performed by the _digester_
 and the remaining steps by the _signer_.
+For example, this specification defines Ed25519ph-split ({{eddsa-split}}) as a split variant of Ed25519ph [RFC8032].
+Note that Ed25519 and Ed25519ph have distinct verification algorithms,
+but Ed25519ph and Ed25519ph-split use the same verification algorithm.
+
 
 ## Requirements Notation and Conventions
 
@@ -379,14 +398,25 @@ and a key derived using `ARKG-P256` [I-D.bradleylundberg-ARKG]:
 
 This specification assumes that both the _digester_ and _signer_ roles
 described in {{split-algs}} are trusted and cooperate honestly.
-This is because these split signing procedures concern details
-that are considered implementation details from a verifier's perspective.
+This is because a similar division between "application" and "secure element"
+typically exists already:
+even if all steps of the signing algorithm are executed in a trusted secure element,
+the inputs to the secure element are provided by some outside component such as a software application.
+If the application can provide any input to be signed,
+then for all practical purposes it is trusted with possession of any private keys
+for as long as it is authorized to exercise the secure element.
+The application can in practice obtain a signature over any chosen message
+without needing to perform a forgery attack.
+The same relationship exists between _digester_ and _signer_.
+Applications that cannot trust an external _digester_ -
+for example a hardware security device with an integrated secure display of what data is about to be signed -
+by definition have no use for split signing algorithm identifiers.
+
+Similarly from a verifier's perspective,
+these split signing procedures are implementation details.
 When a signature is generated by a single party,
 that single party takes on both the _digester_ and the _signer_ roles,
 and obviously trusts itself to perform the _digester_ role honestly.
-This assumption is carried forward for the split signing use case:
-the _digester_ is assumed trusted,
-since it is part of the overall procedure of generating a signature over some input data.
 From the verifier's perspective,
 a malicious _digester_ in the split signing model would have the same powers
 as a malicious signature generator in a single-party signing model.
@@ -400,18 +430,26 @@ The reasoning in {{sec-cons-trusted-roles-protocol}} does not hold on the compon
 A _signer_ implementation MUST NOT assume that the _digester_ implementation
 it interoperates with is necessarily honest.
 Split signing algorithms MUST NOT be defined in a way
-that enables a malicious _digester_ with access to an honest _signer_
-to produce forgeries or extract secrets from the _signer_.
+that enables a malicious _digester_ with access to an honest _signer_ to produce forgeries -
+any that could not be produced by simply requesting a signature over the desired message -
+or extract secrets from the _signer_.
 
 For example, for ECDSA ({{ecdsa-split}}), a malicious _digester_ can choose _H_
 in such a way that the _signer_ will derive any _digester_-chosen value of _e_,
 including zero or other potentially problematic values.
 Fortunately, in this case, this does not enable the _digester_ to extract the signature nonce or private key.
-It also does not enable forgeries,
+It also does not make forgeries easier,
 since the _digester_ still needs to find a preimage of _e_ for the relevant hash function.
 Definitions of other algorithms need to ensure that similar chosen-input attacks
 do not enable extracting secrets or forging protocol-level messages.
 
+For example, a naively prehashed version of FALCON [FALCON] would allow such a key compromise:
+A FALCON signature is a value `s` such that both `s` and `s * h - hash(r || m)` are short,
+where `h` is the public key and `r` a randomizer.
+If the digester gets to query the signer for signatures of arbitrary stand-ins for `hash(r || m)`,
+they can extract the private key by for example asking for repeated signatures of 0.
+Therefore, definitions of split signing algorithms need to be reviewed and potentially have security proofs adjusted.
+
 
 ## Incorrect Use of Split Signing Algorithm Identifiers {#sec-cons-invalid-alg-use}
 
@@ -586,7 +624,8 @@ the Internet-Draft of ARKG [I-D.bradleylundberg-ARKG] extends this specification
 
 We would like to thank
 Ilari Liusvaara,
-Lucas Prabel
+Lucas Prabel,
+Sophie Schmieg
 and
 Falko Strenzke
 for their reviews of and contributions to this specification.
@@ -603,6 +642,10 @@ for their reviews of and contributions to this specification.
 * Added Security Considerations section "Incorrect Use of Split Signing Algorithm Identifiers".
 * Added Implementation Considerations section "Using Non-Split Signing Algorithm Identifiers in a Split Signing Protocol".
 * Added section "Defining Split Signing Algorithms" with guidance for handling domain separation tags in new definitions.
+* Clarified in introduction that Ed25519 and Ed25519ph(-split) have distinct verification algorithms.
+* Clarified in section "Protocol-Level Trusted Roles" why digester is necessarily trusted.
+* Clarified in section "Component-Level Trusted Roles" that redundant forgeries are acceptable,
+  and added example of key compromise concern for naively hashed FALCON.
 
 -04