2 4-DigitalSignatures

DI-FCT-UNL
Computer and Network Systems Security

Segurança de Sistemas e Redes de Computadores
2010-2011
2. Cryptography
2.4 Digital Signatures
© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 1

Outline
•  Digital Signatures,
Authentication and Key-Establishment Protocols
–  Digital Signatures
•  General Requirements and properties
•  Authentication vs. Non-Repudiation
•  Message Authentication with Fast (Light-Weight) Signatures
•  Digital signatures with Public Key Methods
–  Direct and Arbitrated Digital Signatures

–  Public-Key Digital Signatures
•  Digital signature methods
–  RSA
–  ElGammal
–  DSS (or DSA)
–  ECC based signatures

Outline

–  RSA
–  ElGammal
–  DSS (or DSA)

Required properties of digital signatures
•  Digital signature properties
–  Dependence of message (content) signed
–  Unforgeable
•  Must use controlled unique information by the signer
–  No new message for existent digital signature
–  No fraudulent signature for a given message
–  Undeniable
•  The signer can control the <message,signature>
association
–  Verifiable by principals or third parties to resolve
disputes
•  Direct or arbitrated signatures covering all the data
relevance: author, data&time, content, disclaimers,
usage policies, etc)
–  Must be relatively easy to produce
–  Must be relatively easy to recognize and verify
–  Practical to store (with or without the signed content)
Other possible requirements
Sometimes (useful for specific protocols):
–  Unique (one-time signatures)
–  Anonymous use (blind signatures)
•  Signature vs. Content unlinkability
•  Content disguised before it is signed
•  Publicly verifiable against the original (unblinded)
•  Signer and message author are different principals
–  Election systems, Digital Cash Schemes,

Generic requirements
•  Requirements for digital signatures
•  Message authentication (proof of origin)
•  Originality of contents (ownership proofs)
•  Authentication of principals in authentication protocols
(unilateral vs. mutual authentication)
•  Authenticity proofs for non-repudiation protocols
•  Practical issues:
–  MACs as Light-weight (or “inexpensive”) signatures
•  Message flows in session-oriented protocols
•  MACs in protocols for constrained devices
•  Datagram protocols and large amounts (load) of message
processing
–  Public-Key signatures as more robust and

expensive authentication proofs
•  Authentication of principals in handshake protocolos
and session-establishment
Approaches to Message Authentication
•  Authentication Using Conventional Encryption
–  sender and receiver should share a secret key
•  Message Authentication without Message
Encryption
–  Authentication tag (shared secret computation and
verification, based on a shared secret key value)
generated and appended to each message
•  Message Authentication Code

–  MAC computation as a function of the message and the
key. MAC = F(K, M)

Secure hash functions are appropriate
for MAC Algorithms
Henric Johnson 8
MAC with a secure HASH function
•  Secret value is added before the hash and

removed before transmission.

Remembering secure HASH Functions
Purpose of the HASH: production of secure
”fingerprints”.
Properties :
1.  H can be applied to a block of data at any size
2.  H produces a fixed length output
3.  H(x) is easy to compute for any given x.
4.  For any given block x, it is computationally
infeasible to find x such that H(x) = h
- Irreversibility, One-Way
5.  For any given block x, it is computationally
infeasible to find with H(y) = H(x).
- Weak collision resistance
1.  It is computationally infeasible to find any
pair (x, y) such that H(x) = H(y)
- Strong collision resistance
HMACs (flexible combination of secure hash functions)
•  MAC derived from a HMAC structure
cryptographic hash code,
such as SHA-1, SHA-2 and
SHA-3 in the future
•  Motivations:
–  Cryptographic hash functions
executes faster in software
than encryptoin algorithms
such as DES
–  Library code for cryptographic
hash functions is widely
available
–  No export restrictions
–  Different hash functions easily
combined for security ,
maintaining good efficiency
Henric Johnson 12
Outline

–  RSA
–  ElGammal
–  DSS (or DSA)

Direct Digital Signatures
•  Only sender & receiver involved
•  With public-key signatures:
–  assumed receiver has sender’s public-key
–  digital signature made by sender signing entire
message or hash with private-key
–  can encrypt using receivers public-key
–  important that sign first then encrypt message
& signature
–  security depends on sender’s private-key

Arbitrated Digital Signatures
•  Involve sender, receiver and one or more third parties
•  With public-key signatures:
–  assumed third parties have all sender’s public-keys
–  digital signature made by sender signing entire
message or hash with private-key, verified (and
possibly logged) by the third parties, and resigned
by the third parties
•  Notarization
–  The receivers recognize the sender signature by
verifying the third party signature
–  encryption using third-party public-key
–  important that sign first then encrypt message &
signature
–  security depends on sender’s private-key
Outline

–  RSA
–  ElGammal
–  DSS (or DSA)

RSA Signatures (from the algorithm RSA)
Correct (undeniable) Key pair (Kpriv, Kpub)

•  Principal P Private Key: Kpriv, N
•  Principal P Public Key: Kpub, N
Signature(M) = SM = H(M)Kpriv mod N
Verification: Given M and computing H(M)

SMKpub mod N

Relevant issues from RSA (1)
•  Remembering the RSA key-pair generation process
and encryption/decryption algorithm
–  Messages hashed before signing (not the
original message)
•  Security issue when preserving confidentiality
•  Controlled size, comparing with the key size
–  Size of modulus and public and private exponents:
»  The N value (modulus) determines the key sizes
–  M < N
Any value M greater than N will be reduced to M mod N
•  Key pair generation:
–  Value for public exponent so that the encryption step
will be computationally cheap to perform and then
generate the private exponent accordingly
-  Encryption cheap, decryption expensive

-  Signature expensive, Verification cheap
Relevant issues from RSA (2)
•  Key-Generation process
–  Public exponents, fixed (standardized) by
security specifications for RSA implementation
use
•  Ex., X509v3: public exponents 0x10001 (F4)
–  Default in the Bouncy Castle Implementation
–  Problem: how to speed-up the decryption and

the signature process in current
implementations
•  CRT theorem (and ex., Garner’s Algorithm)
–  Keep the original P and Q primes used to generate the
Keys
–  Pre-compute and keep other values in the CRT
computation (dP, dQ, qInv), once only
–  Store (dP, dQ, P, Q, qInv)

Implementation in JAVA-JCE
•  Optimizations are included (differently) in
each crypto provider (subjacent
implementation of RSA)
–  Ex. BC uses a multi-prime remainder theorem
approach
•  To generate keys with 2048 bits, rather than having
to primes P and Q of 1024 bits, it can be used 4
primes of 512 bits
•  Note: observe the behavior of time

consuming (processing) in the examples
provided.

RSA Padding mechanisms
•  Operations in RSA are ober big integers
•  What if the representation begins with 0
bits (MSBits) ?
–  See practical examples
•  What happens if you change the value of
the public exponent to a low value ?
–  See practical examples
–  Is it secure for encryption ?
•  You need Padding !

Padding in RSA
•  PKCS#1
•  Implementation (ex., BC)
•  See also the practical examples
Type 1: Mp= 0x00 || 0x01 || F || 0x00 || M

with F = string of 0xFF bytes, at least 8 bytes
Then: M <= Keysize in bytes – 11
- This is used when using the private key (signatures)
Type 2: Mp= 0x00 || 0x02 || R || 0x00 || M

with R = Random bytes, at least 8 bytes
Then: M <= Keysize in bytes – 11
- This is used when using the public key (encryption)

Strongest padding for RSA
•  Ex., OAEP Padding
–  Used with parameters: P, and random seed S
•  OAEP – Optimal Asymmetric Encryption Padding

M1 = Mask [ ( H(P) || PZ || 0x01 || M), S ]
M2 = Mask (S, M1)
Mp=0x00 || M2 || M1
Note: MaxLen for the message will be kLen – 2hLen – 2

Note: for a certain message length usable in PKCS#1, you
may need a more long key if you use OAEP, but this is
not an issue – why ?
See practical examples:

Suite: RSA/None/OAEPWithSHA1and MGF1Padding
RSA Signatures in the JAVA-JCE
•  See practical examples
–  Practical class examples and verifications
Signature class
Steps:
-  Initialization of the signature object for
signing
-  signature.update() is then used to feed data
into the signature object
-  When all the data has been fed in,
signature.sign() is called
-  Signature can be:
-  Returned as a byte array
-  Or load it into a passed in byte-array

Use of RSA in the Java JCE
•  Example (see practical examples)
…
After the keypair generation process initialization…
…
byte[] message = new byte[] {…..};
KeyPair KeyPair = KeyGen.generateKeyPair();

Signature signature = Signature.getInstance (“RSA”, “BC”);
// to generate a signature
signature.initSign(keyPair.getPrivate(), random);
signature.update (message);
byte[] sigBytes= signature.sign();
//verification
signature.initVerify(keyPair.getPublic());
signature.update(message);
if (signature.verify(sigBytes)) { … ok … } else { not ok }
ElGammal public key scheme (asymetric)
•  A variant of Diffie-Hellman
–  Same math. principles
•  Widely used (ex., OpenPGP implementations,
standardized in RFC 2440)
•  How does it works ?
Bob has a public key gy mod P (well known by Alice)
Alice creates a temporary public key
KpubA = gx mod P
Encryption: C = {M}KpubB = M gxy mod P

Alice sends to Bob: C, KpubA
Note: makes the cipher text twice the key size

ElGamal Digital Signatures
•  Signature variant of ElGamal, related to D-H
–  Uses exponentiation in a finite (Galois)
–  Security based difficulty of computing discrete
logarithms, as in D-H
•  Private key for encryption (signing)
•  Public key for decryption (verification)
•  each user (eg. A) generates their key
–  chooses a secret key (number): 1 < xA < q-1
xA
–  compute their public key: yA = a mod q

ElGamal Digital Signature
•  Alice signs a message M to Bob by computing
–  the hash m = H(M), 0 <= m <= (q-1)
–  chose random integer K with 1 <= K <= (q-1)
and gcd(K,q-1)=1
k
–  compute temporary key: S1 = a mod q
–  compute K-1 the inverse of K mod (q-1)
–  compute the value: S2 = K-1(m-xAS1) mod (q-1)
–  The signature is the tuple:(S1,S2)
•  any user B can verify the signature by
computing
m
–  V1 = a mod q
–  V2 = yAS1 S1S2 mod q
–  signature is valid if V1 = V2

ElGamal Signature Example
•  use field GF(19) q=19 and a=10
•  Alice computes her key:
16
–  A chooses xA=16 & computes yA=10 mod 19 = 4
•  Alice signs message with hash m=14 as (3,4):
–  choosing random K=5 which has gcd(18,5)=1
5
–  computing S1 = 10 mod 19 = 3
–  finding K-1 mod (q-1) = 5-1 mod 18 = 11
–  computing S2 = 11(14-16.3) mod 18 = 4
•  any user B can verify the signature by
computing
14
–  V1 = 10 mod 19 = 16
–  V2 = 43.34 mod 19 = 5184 mod 19 = 16
–  since V1 = V2, the signature is valid
Schnorr Digital Signatures
•  also uses exponentiation in a finite (Galois)

–  security based on discrete logarithms, as in D-H
•  minimizes message dependent computation
–  multiplying a 2n-bit integer with an n-bit integer
•  main work can be done in idle time
•  have using a prime modulus p
–  p–1 has a prime factor q of appropriate size
–  typically p 1024-bit and q 160-bit numbers

Schnorr Key Setup
•  choose suitable primes p , q
q
•  choose a such that a = 1 mod p
•  (a,p,q) are global parameters for all
•  each user (eg. A) generates a key
–  chooses a secret key (number): 0 < sA < q
-sA
–  compute their public key: vA = a mod q

Schnorr Signature
•  user signs message by
–  choosing random r with 0<r<q and computing x = ar
mod p
–  concatenate message with x and hash result to
computing: e = H(M || x)
–  computing: y = (r + se) mod q
–  signature is pair (e, y)
•  any other user can verify the signature as
follows:
–  computing: x' = ayve mod p
–  verifying that: e = H(M || x’)

Digital Signature Standard (DSS)
•  Public-Key digital signature technique
–  Like D-H, security from the discrete logarithm problem
•  DSA is digital signature only
–  unlike RSA
•  US Govt approved signature scheme
–  designed by NIST & NSA in early 90's
–  published as FIPS-186 in 1991
–  revised in 1993, 1996 & then 2000
•  Uses the SHA hash algorithm
•  DSS is the standard, DSA is the algorithm
–  FIPS 186-2 (2000) includes:
•  Alternative RSA
•  Elliptic curve signature variants

DSS vs RSA Signatures

Use of DSA in the Java JCE
•  Example (see practical examples)
…
After the keypair generation process initialization…
…
byte[] message = new byte[] {…..};
KeyPair KeyPair = KeyGen.generateKeyPair();

Signature signature = Signature.getInstance (“DSA”, “BC”);
// to generate a signature
signature.initSign(keyPair.getPrivate(), random);
signature.update (message);
byte[] sigBytes= signature.sign();
//verification
signature.initVerify(keyPair.getPublic());
signature.update(message);
if (signature.verify(sigBytes)) { … ok … } else { not ok }
Digital Signature Algorithm (DSA)
•  creates a 320 bit signature

•  with 512-1024 bit security
•  smaller and faster than RSA
•  a digital signature scheme only
•  security depends on difficulty of computing
discrete logarithms
•  A standard based in fact in a variant of
ElGamal & Schnorr schemes

DSA Key Generation
•  have shared global public key values (p,q,g):

–  choose 160-bit prime number q: 2159 < q < 2160
–  choose a large prime p with 2L-1 < p < 2L
•  where L= 512 to 1024 bits and is a multiple of 64
•  such that q is a 160 bit prime divisor of (p-1)
–  choose g = h(p-1)/q
•  where 1<h<p-1 and h(p-1)/q mod p > 1
•  users choose private & compute public key:
–  choose random private key: x<q
–  compute public key: y = gx mod p

DSA Signature Creation
•  to sign a message M the sender:
–  generates a random signature key k, k<q
–  nb. k must be random, be destroyed after use,
and never be reused
•  then computes signature pair:
r = (gk mod p)mod q
s = [k-1(H(M)+ xr)] mod q
•  sends signature (r,s) with message M

DSA Signature Verification
•  having received M & signature (r,s)
•  to verify a signature, recipient computes:
w = s-1 mod q
u1= [H(M)w ]mod q
u2= (rw)mod q
v = [(gu1 yu2)mod p ]mod q
•  if v=r then signature is verified

DSS Overview

2 4-DigitalSignatures

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2 4-DigitalSignatures

Uploaded by

Copyright:

Available Formats

DI-FCT-UNL

Computer and Network Systems Security

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 1

– Direct and Arbitrated Digital Signatures

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 2

– Direct and Arbitrated Digital Signatures

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 3

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 5

– Public-Key signatures as more robust and

• Message Authentication Code

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 7

• Secret value is added before the hash and

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 9

– Direct and Arbitrated Digital Signatures

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 13

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 14

– Direct and Arbitrated Digital Signatures

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 16

Correct (undeniable) Key pair (Kpriv, Kpub)

Signature(M) = SM = H(M)Kpriv mod N

Verification: Given M and computing H(M)

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 17

- Encryption cheap, decryption expensive

– Problem: how to speed-up the decryption and

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 19

• Note: observe the behavior of time

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 20

• You need Padding !

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 21

Type 1: Mp= 0x00 || 0x01 || F || 0x00 || M

Type 2: Mp= 0x00 || 0x02 || R || 0x00 || M

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 22

• OAEP – Optimal Asymmetric Encryption Padding

Note: MaxLen for the message will be kLen – 2hLen – 2

See practical examples:

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 24

KeyPair KeyPair = KeyGen.generateKeyPair();

Encryption: C = {M}KpubB = M gxy mod P

Note: makes the cipher text twice the key size

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 27

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 28

• also uses exponentiation in a finite (Galois)

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 30

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 31

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 32

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 33

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 34

KeyPair KeyPair = KeyGen.generateKeyPair();

• creates a 320 bit signature

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 36

• have shared global public key values (p,q,g):

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 37

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 38

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 39

© 2010, Henrique J. Domingos, DI/FCT/UNL 2.4 Digital Signatures - Slide 40

You might also like

–  Direct and Arbitrated Digital Signatures

–  Direct and Arbitrated Digital Signatures

–  Public-Key signatures as more robust and

•  Message Authentication Code

•  Secret value is added before the hash and

–  Direct and Arbitrated Digital Signatures

–  Direct and Arbitrated Digital Signatures

-  Encryption cheap, decryption expensive

–  Problem: how to speed-up the decryption and

•  Note: observe the behavior of time

•  You need Padding !

•  OAEP – Optimal Asymmetric Encryption Padding

•  also uses exponentiation in a finite (Galois)

•  creates a 320 bit signature

•  have shared global public key values (p,q,g):