Digital Signature 2019

Digital Signatures
Dr. V. K. Pachghare
Department of Computer Engineering and Information Technology

College of Engineering Pune (COEP) 1
Forerunners in Technical Education
Digital Signatures
• Verify author, date & time of signature

• Authenticate message contents
• Can be verified by third parties to resolve disputes

College of Engineering Pune (COEP)
Generation and Verification of Digital Signature

Digital Signature Requirements
• Must depend on the message signed
• Must use information unique to sender
• To prevent both forgery and denial
• Must be relatively easy to produce
• Must be relatively easy to recognize & verify
• Directed Recipient can verify
• Arbitrated Anyone can verify

• Be computationally infeasible to forge
• With new message for existing digital
signature
• With fraudulent digital signature for given
message
• Be able to retain a copy of the signature in
storage

Replay Attacks
• where a valid signed message is copied and later
resent
– Simple replay: The opponent simply copies a
message and replays it later
– Repetition that can be logged: An opponent can
replay a time stamped message within the valid
time window.
– Repetition that cannot be detected: This
situation could arise because the original message
could have been suppressed and thus did not arrive
at its destination; only the replay message arrives.

College of Engineering Pune (COEP) 1/31/2020
Forerunners in Technical Education 6
– Backward replay without modification:
This is a replay back to the message sender.
This attack is possible if symmetric encryption
is used and the sender cannot easily recognize
the difference between messages sent and
messages received on the basis of content
• Countermeasures include
– Use of sequence numbers: it requires each
party to keep track of the last sequence number
for each claimant it has dealt with. It increases
overhead, so impractical.

– Challenge/response (using unique nonce): Party A,
expecting a fresh message from B, first sends B a nonce
(challenge) and requires that the subsequent message
(response) received from B contains the correct nonce
value
– Timestamps (needs synchronized clocks): party A
accepts a message as fresh only if the message contains a
timestamp that, in A’s judgment, is close enough to A’s
knowledge of current time. This approach requires that
clocks among the various participants be synchronized.

Digital Signature Algorithm

• 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
• Variant of ElGamal & Schnorr schemes

DSA
1. Key Generation
2. Signature Creation
3. Signature Verification

DSA Key Generation
• Shared global public key values (p, q, g):
– Choose a large prime number p
• such that 2L-1 < p < 2L
• where L= 512 to 1024 bits and is a multiple of 64
– Choose q, a 160 bit prime factor of p-1
– choose g = h(p-1)/q mod p
• where 1<h<p-1, h(p-1)/q mod p > 1
• users choose private key & compute public key:
– choose 0<x<q (private key)
– compute y = gx mod p (public key)

DSA Signature Creation
• to sign a message M the sender:
– generates a random signature key k, 0<k<q
– 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)+ x.r)(mod q)
• signature = (r, s)
• Sends signature (r, s) with message M

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= (r. w)(mod q)
v = (gu1.yu2(mod p)) (mod q)
• if v=r then signature is verified

• Suppose p=283, q=47, g=60
• User A’s private key, X=24
• Message M with message digest H(M)=41.
• A chooses a random k=15 in the range [1, q−1]
• A computes
r = (gk(mod p))(mod q) = (6015 mod 283)mod 47
= 207 mod 47 = 19
s = (k-1.H(M)+ x.r)(mod q)
• r≠0 so continue.
• A computes k−1modq=15−1mod47=22. A computes H(M)=41.
• Alice computes s = (k-1.H(M)+ x.r)(mod q)
=22(41+24⋅19)mod47=30. s≠0 so continue. A issues the message
M and signature (r, s)=(19, 30).

DSA verification by Bob (or anyone)
• Domain parameters (p=283,q=47,g=60)

• A's public key, X=158
• Message M with message digest H(M)=41. Signature
(r,s)=(19,30).
• Bob verifies that 0<r=19<47
• and 0<s=30<47 ⇒ OK, so continue. Bob computes
w=s−1modq=30−1mod47=11. Bob computes h=Hash(M)=41. Bob
computes u1=hwmodq=41⋅11mod47=28 and
u2=rwmodq=19⋅11mod47=21. Bob computes
X=gu1Au2modp=6028⋅15821mod283=106⋅42mod283=207 and
v=Xmodq=207mod47=19. Bob checks that v=19=r, so he accepts
the signature.

Homework
DSA specifies that if signature generation process results in a
value of s=0, a new value of k should be generated and the
signature should be recalculated.
Why?
Suppose Alice signed a message M using DSA with a specific k
value and then the k value was compromised. Can Alice still use
her private key for future digital signatures?
Hint: Show that the private key of the signer can be easily
computed in both of the above cases.

Certificates

X.509 Certificates
• issued by a Certification Authority (CA), containing:
– Version (1, 2, or 3)
– Serial number (unique within CA) identifying certificate
– Signature
– Issuer name (CA)
– Validity (from - to dates)
– Subject (name of owner)
– Subject public key information (algorithm, parameters,
key)
– Issuer unique identifier (version 2 and 3 only)
– Subject unique identifier (version 2 and 3 only)
– Extensions (version 3 only)
– Signature (of hash of all fields in certificate)
• notation CA<<A>> denotes certificate for A signed by CA

• Version: This gives information about the version of the
X.509 standard applies to the certificate. Currently three
versions of X.509 certificates are available. Version
indicates the information available with the certificate.
• Serial number: A serial number of the certificate

distinguishes it from other certificates issued by the same
party. Certificate’s serial number is placed in a certificate
revocation list (CRL) when a certificate is revoked.

• Signature: This identifies the algorithm used to compute the
signature on the certificate.
• Issuer name: It is X.500 name of the entity who signed the
certificate. Generally, a certificate authority (CA). Using
issuer name certificate implies trusting the entity who
signed the certificate.
• Validity: Each certificate has its life span. Validity gives the
information about this life span. The life span can be as
short as a few seconds or almost as long as a century. This
contains two types of information: a start date and an end
date with time.
• The validity period depends on: the private key used or the
amount one is willing to pay for a certificate. This is the
expected period that entities can rely on the public value, if
the associated private key has not been compromised.
• Subject: The name of the user whose public key the

certificate identifies. This name uses the X.500 standard,
so it is intended to be unique across the Internet. This is
the Distinguished Name (DN) of the entity, for example,
CN = Ram, OU = COEP, O = PIET, C = INDIA
CN: Subject’s Common Name, OU: Organizational Unit, O: Organisation,

and C: Country.

• Subject public key information: This contains two types of
information:- the public key and an algorithm identifier
which specifies which public key cryptosystem this key
belongs to and any associated key parameters.
• Issuer unique identifier (versions 2 and 3 only): This is an
optional bit string field used to identify uniquely the
issuing CA in the event the X.500 name has been reused
for different entities.

• Subject unique identifier (versions 2 and 3 only): Each user
has one number which is unique across the internet. This
provides the unique identity of the user.
• Extensions: It is a set of one or more extension fields.
Extensions were added in version 3.
• Signature on the above fields: Covers all of the other fields
of the certificate; it contains the hash code of the other
fields, encrypted with the CA’s private key. This field
includes the signature algorithm identifier.

X.509 Certificates

Obtaining a Certificate
• any user with access to CA can get any certificate
from it
• only the CA can modify a certificate
• because cannot be forged, certificates can be placed in

a public directory

CA Hierarchy
• if both users share a common CA then they are
assumed to know its public key
• otherwise CA's must form a hierarchy
• use certificates linking members of hierarchy to

validate other CA's
– each CA has certificates for clients (forward) and

parent (backward)

• each client trusts parents certificates
• enable verification of any certificate from one CA by

users of all other CAs in hierarchy

CA Hierarchy Use

Certificate Revocation
• certificates have a period of validity
• may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised

• CA’s maintain list of revoked certificates
– the Certificate Revocation List (CRL)
• users should check certs with CA’s CRL

Authentication Procedures
X.509 includes three alternative authentication
procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures

One-Way Authentication
• 1 message ( A->B) used to establish
– the identity of A and that message is from A
– message was intended for B
– integrity & originality of message
• message must include timestamp, nonce, B's identity

and is signed by A

Two-Way Authentication
• 2 messages (A->B, B->A) which also establishes in
addition:
– the identity of B and that reply is from B
– that reply is intended for A
– integrity & originality of reply
• reply includes original nonce from A, also timestamp

and nonce from B

Three-Way Authentication
• 3 messages (A->B, B->A, A->B) which enables above
authentication without synchronized clocks
• has reply from A back to B containing signed copy of

nonce from B
• means that timestamps need not be checked or relied

upon


Digital Signature 2019

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Digital Signature 2019

Загружено:

Авторское право:

Доступные форматы

Digital Signatures

Department of Computer Engineering and Information Technology

• Verify author, date & time of signature

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

• Domain parameters (p=283,q=47,g=60)

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

• Serial number: A serial number of the certificate

Department of Computer Engineering and Information Technology

• Subject: The name of the user whose public key the

CN: Subject’s Common Name, OU: Organizational Unit, O: Organisation,

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

• only the CA can modify a certificate

• because cannot be forged, certificates can be placed in

Department of Computer Engineering and Information Technology

• otherwise CA's must form a hierarchy

• use certificates linking members of hierarchy to

– each CA has certificates for clients (forward) and

Department of Computer Engineering and Information Technology

• enable verification of any certificate from one CA by

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

• may need to revoke before expiry, eg:

1. user's private key is compromised

2. user is no longer certified by this CA

3. CA's certificate is compromised

Department of Computer Engineering and Information Technology

– the Certificate Revocation List (CRL)

• users should check certs with CA’s CRL

Department of Computer Engineering and Information Technology

Department of Computer Engineering and Information Technology

– the identity of A and that message is from A

– message was intended for B

– integrity & originality of message

• message must include timestamp, nonce, B's identity

Department of Computer Engineering and Information Technology

– the identity of B and that reply is from B

– that reply is intended for A

– integrity & originality of reply

• reply includes original nonce from A, also timestamp

Department of Computer Engineering and Information Technology

• has reply from A back to B containing signed copy of

• means that timestamps need not be checked or relied

Department of Computer Engineering and Information Technology

Вам также может понравиться