4.4. Signature schemes

4.4Signature schemes

Signatures schemes are the digital counterparts to handwritten signatures. They can be used to provide data origin authentication, data integrity, and non-repudiation. Signature schemes are commonly used by trusted certification authorities to sign certificates that bind together an entity and its public key.

Definition 4.27 A signature scheme consists of four algorithms:

1.A domain parameter generation algorithm that generates a set D of domain parameters.

2.A key generation algorithm that takes as input a set D of domain parameters and generates key pairs (Q, d).

3.A signature generation algorithm that takes as input a set of domain parameters D, a private key d, and a message m, and produces a signature .

4.A signature verification algorithm that takes as input the domain parameters D, a public key Q, a message m, and a purported signature , and accepts or rejects the signature.

We assume that the domain parameters D are valid (see §4.2) and that the public key Q is valid and associated with D (see §4.3). The signature verification algorithm always accepts input (D, Q, m, ) if was indeed generated by the signature generation algorithm with input (D, d, m).

The following notion of security of a signature scheme is due to Goldwasser, Micali and Rivest (GMR).

Definition 4.28 A signature scheme is said to be secure (or GMR-secure) if it is existentially unforgeable by a computationally bounded adversary who can mount an adaptive chosen-message attack. In other words, an adversary who can obtain signatures of any messages of its choosing from the legitimate signer is unable to produce a valid signature of any new message (for which it has not already requested and obtained a signature).

This security definition is a very strong one—the adversary is afforded tremendous powers (access to a signing oracle) while its goals are very weak (obtain the signature of any message not previously presented to the signing oracle). It can be argued that this notion is too strong for some applications—perhaps adversaries are unable to obtain signatures of messages of their choice, or perhaps the messages whose signatures they are able to forge are meaningless (and therefore harmless) within the context of the application. However, it is impossible for the designer of a signature scheme intended for widespread use to predict the precise abilities of adversaries in all environments in which the signature scheme will be deployed. Furthermore, it is impossible for the designer to formulate general criteria to determine which messages will be considered

184 4. Cryptographic Protocols

“meaningful.” Therefore, it is prudent to design signature schemes that are secure under the strongest possible notion of security—GMR-security has gained acceptance as the “right” one.

Two standardized signature schemes are presented, ECDSA in §4.4.1, and ECKCDSA in §4.4.2.

4.4.1ECDSA

The Elliptic Curve Digital Signature Algorithm (ECDSA) is the elliptic curve analogue of the Digital Signature Algorithm (DSA). It is the most widely standardized elliptic curve-based signature scheme, appearing in the ANSI X9.62, FIPS 186-2, IEEE 13632000 and ISO/IEC 15946-2 standards as well as several draft standards.

In the following, H denotes a cryptographic hash function whose outputs have bitlength no more than that of n (if this condition is not satisfied, then the outputs of H can be truncated).

Algorithm 4.29 ECDSA signature generation

INPUT: Domain parameters D = (q, FR, S, a, b, P, n, h), private key d, message m. OUTPUT: Signature (r, s).

1.Select k R [1, n − 1].

2.Compute k P = (x1, y1) and convert x1 to an integer x1.

3.Compute r = x1 mod n. If r = 0 then go to step 1.

4.Compute e = H (m).

5.Compute s = k−1(e + dr ) mod n. If s = 0 then go to step 1.

6.Return(r, s).

Algorithm 4.30 ECDSA signature verification

INPUT: Domain parameters D = (q, FR, S, a, b, P, n, h), public key Q, message m, signature (r, s).

OUTPUT: Acceptance or rejection of the signature.

1.Verify that r and s are integers in the interval [1, n − 1]. If any verification fails then return(“Reject the signature”).

2.Compute e = H (m).

3.Compute w = s−1 mod n.

4.Compute u1 = ew mod n and u2 = r w mod n.

5.Compute X = u1 P + u2 Q.

6.If X = ∞ then return(“Reject the signature”);

7.Convert the x-coordinate x1 of X to an integer x1; compute v = x1 mod n.

8.If v = r then return(“Accept the signature”); Else return(“Reject the signature”).

Proof that signature verification works If a signature (r, s) on a message m was indeed generated by the legitimate signer, then s ≡ k−1(e + dr ) (mod n). Rearranging gives

Security notes

Note 4.31 (security proofs for ECDSA) In order for ECDSA to be GMR-secure, it is necessary that the ECDLP in P be intractable, and that the hash function H be cryptographically secure (preimage resistant and collision resistant). It has not been proven that these conditions are also sufficient for GMR-security. ECDSA has, however, been proven GMR-secure in the generic group model (where the group P is replaced by a generic group) and under reasonable and concrete assumptions about H . While a security proof in the generic group model does not imply security in the real world where a specific group such as an elliptic curve group is used, it arguably inspires some confidence in the security of ECDSA.

Note 4.32 (rationale for security requirements on the hash function) If H is not preimage resistant, then an adversary E may be able to forge signatures as follows. E selects an arbitrary integer l and computes r as the x-coordinate of Q + l P reduced modulo n. E sets s = r and computes e = rl mod n. If E can find a message m such that e = H (m), then (r, s) is a valid signature for m.

If H is not collision resistant, then E can forge signatures as follows. She first finds two different messages m and m such that H (m) = H (m ). She then asks A to sign m; the resulting signature is also valid for m .

Note 4.33 (rationale for the checks on r and s in signature verification) Step 1 of the ECDSA signature verification procedure checks that r and s are integers in the interval [1, n − 1]. These checks can be performed very efficiently, and are prudent measures in light of known attacks on related ElGamal signature schemes which do not perform these checks. The following is a plausible attack on ECDSA if the check r = 0 (and,

more generally, r ≡ 0 (mod n)) is not performed. Suppose that A is using the elliptic curve y2 = x3 + ax + b over a prime field F p, where√ b is a quadratic residue modulo p, and suppose that A uses a base point P = (0, b) of prime order n. (It is plausible that all entities may select a base point with zero x-coordinate in order to minimize the size of domain parameters.) An adversary can now forge A’s signature on any message m of its choice by computing e = H (m). It can readily be checked that (r = 0, s = e) is a valid signature for m.

186 4. Cryptographic Protocols

Note 4.34 (security requirements for per-message secrets) The per-message secrets k in ECDSA signature generation have the same security requirements as the private key d. If an adversary E learns a single per-message secret k that A used to generate a signature (r, s) on some message m, then E can recover A’s private key since

where e = H (m) (see step 5 of ECDSA signature generation). Furthermore, HowgraveGraham and Smart have shown that if an adversary somehow learns a few (e.g., five) consecutive bits of per-message secrets corresponding to several (e.g., 100) signed messages, then the adversary can easily compute the private key. These observations demonstrate that per-message secrets must be securely generated, securely stored, and securely destroyed after they have been used.

Note 4.35 (repeated use of per-message secrets) The per-message secrets k should be generated randomly. In particular, this ensures that per-message secrets never repeat, which is important because otherwise the private key d can be recovered. To see this,

suppose that the same per-message secret k was used to generate ECDSA signatures

(r, s1) and (r, s2) on two messages m1 and m2. Then s1 ≡ k−1(e1 + dr ) (mod n) and s2 ≡ k−1(e2 + dr ) (mod n), where e1 = H (m1) and e2 = H (m2). Then ks1 ≡ e1 + dr

(mod n) and ks2 ≡ e2 + dr (mod n). Subtraction gives k(s1 − s2) ≡ e1 − e2 (mod n). If s1 ≡ s2 (mod n), which occurs with overwhelming probability, then

k ≡ (s1 − s2)−1(e1 − e2) (mod n).

Thus an adversary can determine k, and then use (4.12) to recover d.

4.4.2EC-KCDSA

EC-KCDSA is the elliptic curve analogue of the Korean Certificate-based Digital Signature Algorithm (KCDSA). The description presented here is from the ISO/IEC 15946-2 standard.

In the following, H denotes a cryptographic hash function whose outputs are bit strings of length lH . The bitlength of the domain parameter n should be at least lH . hcert is the hash value of the signer’s certification data that should include the signer’s identifier, domain parameters, and public key. The signer’s private key is an integer d R [1, n], while her public key is Q = d−1 P (instead of d P which is the case with all other protocols presented in this book). This allows for the design of signature generation and verification procedures that do not require performing a modular inversion. In contrast, ECDSA signature generation and verification respectively require the computation of k−1 mod n and s−1 mod n.

Algorithm 4.36 EC-KCDSA signature generation

INPUT: Domain parameters D = (q, FR, S, a, b, P, n, h), private key d, hashed certification data hcert, message m.

OUTPUT: Signature (r, s).

1.Select k R [1, n − 1].

2.Compute k P = (x1, y1).

3.Compute r = H (x1).

4.Compute e = H (hcert, m).

5.Compute w = r e and convert w to an integer w.

6.If w ≥ n then w ← w − n.

7.Compute s = d(k − w) mod n. If s = 0 then go to step 1.

8.Return(r, s).

Algorithm 4.37 EC-KCDSA signature verification

INPUT: Domain parameters D = (q, FR, S, a, b, P, n, h), public key Q, hashed certification data hcert, message m, signature (r, s).

OUTPUT: Acceptance or rejection of the signature.

1.Verify that the bitlength of r is at most lH and that s is an integer in the interval [1, n − 1]. If any verification fails then return(“Reject the signature”).

2.Compute e = H (hcert, m).

3.Compute w = r e and convert w to an integer w.

4.If w ≥ n then w ← w − n.

5.Compute X = s Q + w P.

6.Compute v = H (x1) where x1 is the x-coordinate of X.

7.If v = r then return(“Accept the signature”); Else return(“Reject the signature”).

Proof that signature verification works If a signature (r, s) on a message m was

indeed generated by the legitimate signer, then s ≡ d(k − w) (mod n). Rearranging gives k ≡ sd−1 + w (mod n). Thus X = s Q + w P = (sd−1 + w) P = k P, and so v = r

as required.

Note 4.38 (use of hcert) In practice, hcert can be defined to be the hash of the signer’s public-key certificate that should include the signer’s identity, domain parameters, and public key. Prepending hcert to the message m prior to hashing (i.e., when computing e = H (hcert, m)) can provide resistance to attacks based on manipulation of domain parameters.

Note 4.39 (security proofs for EC-KCDSA) KCDSA, which operates in a prime-order subgroup S of the multiplicative group of a finite field, has been proven GMR-secure under the assumptions that the discrete logarithm problem in S is intractable and that the hash function H is a random function. Actually, if different hash functions H1

188 4. Cryptographic Protocols

and H2 are used in steps 3 and 4, respectively, of the signature generation procedure, then the security proof assumes that H1 is a random function and makes the weaker assumption that H2 is collision resistant.

A security proof for a protocol that makes the assumption that hash functions employed are random functions is said to hold in the random oracle model. Such proofs do not imply that the protocol is secure in the real world where the hash function is not a random function. Nonetheless, such security proofs do offer the assurance that the protocol is secure unless an adversary can exploit properties of the hash functions that distinguish them from random functions.

The security proof for KCDSA extends to the case of EC-KCDSA if the operation in step 3 of signature generation is replaced by r = H (x1, y1).

4.5Public-key encryption

Public-key encryption schemes can be used to provide confidentiality. Since they are considerably slower than their symmetric-key counterparts, they are typically used only to encrypt small data items such as credit card numbers and PINs, and to transport session keys which are subsequently used with faster symmetric-key algorithms for bulk encryption or message authentication.

Definition 4.40 A public-key encryption scheme consists of four algorithms:

1.A domain parameter generation algorithm that generates a set D of domain parameters.

2.A key generation algorithm that takes as input a set D of domain parameters and generates key pairs (Q, d).

3.An encryption algorithm that takes as input a set of domain parameters D, a public key Q, a plaintext message m, and produces a ciphertext c.

4.A decryption algorithm that takes as input the domain parameters D, a private key d, a ciphertext c, and either rejects c as invalid or produces a plaintext m.

We assume D is valid (see §4.2) and that Q is valid and associated with D (see §4.3). The decryption algorithm always accepts (D, d, c) and outputs m if c was indeed generated by the encryption algorithm on input (D, Q, m).

The following notion of security of a public-key encryption scheme is due to Goldwasser, Micali, Rackoff and Simon.

Definition 4.41 A public-key encryption scheme is said to be secure if it is indistinguishable by a computationally bounded adversary who can mount an adaptive chosen-ciphertext attack. In other words, an adversary who selects two plaintext messages m1 and m2 (of the same length) and is then given the ciphertext c of one of them is unable to decide with non-negligible advantage whether c is the encryption of m1