Digital Signatures
Dan Fleck
CS 469: Security Engineering
1
Coming up: Digital Signatures
These slides are modified with permission from Bill Young (Univ of Texas)
Digital Signatures
Suppose you write a (physical) check. What would you like to be true?
• A check is a tangible object authorizing the transaction.
• The signature on the check confirms authenticity.
• In the case of an alleged forgery, a third party may be called to judge
authenticity.
• The check is not alterable or alterations can be easily detected.
• The signature is part of the check, so cannot be easily removed and
re-used.
Can we define a mechanism for signing a document digitally that has
analogous characteristics?
Coming up: Digital Signatures Properties
2
Digital Signatures Properties
Suppose S sends a message M to R with signature f (S, M): We’d like
the signature to have certain properties:
unforgeable: it should be difficult for anyone but S to
produce f (S, M);
authentic: R can verify that S signed the document M;
no repudiation: S cannot deny producing the signature;
tamperproof: after being transmitted, M cannot be modified;
not reusable: the signature cannot be detached and reused for
another message.
3
Coming up: Digital Signatures (Cont.)
Digital Signatures (Cont.)
Public key systems are well-suited for digital signatures. Recall
that some algorithms, RSA in particular, have the following
characteristic:
{{M}K }K -1 = M = {{M}K -1 }K
So, if S wishes to send message M to R in a way that has some of
the characteristics of a digitally signed message, S could send
{{M}K -1 }KR
S
Most often, it’s not the M but a hash of M that is signed. Why?
What assurance does R gain from this interchange?
Coming up: Digital Signatures Properties
4
Digital Signatures Properties
S sends to R the following message:
{{M}K -1 }KR
S
This scheme has the desired properties:
unforgeable: only S can use KS-1 ;
authentic: a third party can verify the signature with KS ;
no repudiation: only S can use KS-1;
tamperproof: only R can remove the outer layer of encryption;
not reusable: the signature is tightly bound to the message M.
Coming up: Lessons
5
Lessons
• Digital signatures function much as physical signatures.
• Ideally a signature should be: unforgeable, authentic,
tamperproof, non-reusable, and allow no repudiation.
• Public key cryptosystems facilitate creating digital signatures.
6
Coming up: Certificates
Certificates
Dan Fleck
CS 469: Security Engineering
7
Coming up: Web of Trust
These slides are modified with permission from Bill Young (Univ of Texas)
Web of Trust
Much of what happens on-line, particularly e-commerce,
depends on establishing a web of trust relationships among the
parties.
Question: Why should A trust B with whom he’s never
previously dealt?
Possible Answer: A might rely on a known third party to “vouch
for” B.
The Chamber of Commerce, Better Business Bureau, credit
reporting agencies, friends all function in part as certification
authorities for some commercial transactions.
Coming up: Need for Trust
8
Need for Trust
With a public key infrastructure (PKI), if A knows B’s public key,
then A can:
• send a message securely to B;
• be assured that a message from B really originated with B.
But, how does A know that the public key B presents is really B’s
public key and not someone else’s?
The most common circumstance in which trust is needed in a
distributed on-line context is reliably binding a public key to an
identity.
Coming up: Certificates
9
Certificates
A certificate is the electronic equivalent of a “letter of
introduction.”
A certificate is constructed with digital signatures and hash
functions.
A public key and a user’s identity are bound together within a
certificate, signed by a certification authority, vouching for the
accuracy of the binding
10
Coming up: How it Might Work
How it Might Work
Suppose X is the president of a company; Y is her subordinate.
Each have an RSA public key pair.
1. Y securely passes message {Y ,KY } to X.
2. X produces a cryptographic hash of the message, i.e., h({Y
,KY }).
3. X produces {Y, KY ,{h({Y, KY })} -1 }
KX
This last then becomes Y ’s certificate, signed by X
11
Coming up: Validating the Certificate
Validating the Certificate
Suppose Y presents to Z the certificate :
{Y, KY ,{h({Y, KY })}K -1 }
X
What does Z do with this? What does Z learn?
• The message certifies the binding of Y and KY .
• X is the certifying authority.
• Data items Y and KY were not altered or corrupted.
This scheme assumes that Z has a trustworthy public key for X,
to verify X’s signature.
Coming up: Lessons
12
Lessons
• Certificates are needed to establish a web of trust in a
distributed environment.
• A trusted individual can “vouch for” another party by
certifying the binding of identity to public key.
• A third party can check the validity of the binding
13
Coming up: Certificates and Trust
Certificates and Trust
Certificates address the need for constructing a web of trust in
computer systems: How do mutually suspicious entities establish
a relationship of trust?
One way is to rely on a known third party to “vouch for” one or
both of the parties.
In a digital context, this typically means certifying the binding
between identity and public key.
14
Coming up: Chains of Trust
Chains of Trust
Suppose Y has a certificate signed by X, but Y now needs to
certify W . He might produce a certificate for W and append X’s
certificate to it.
This creates a chain of trust from W to Y to X.
Ideally, the chain is rooted at some unimpeachable authority.
15
Coming up: Certification Authorities
Certification Authorities
An entity may gain authority to certify by virtue of position,
rather than familiarity.
In off-line transactions this might be a notary public, personnel
officer, security officer in a company, etc.
On the Internet, several groups serve as “root certification
authorities”: Verisign, SecureNet, Baltimore Technologies,
Deutsche Telecom, Certiposte, and several others.
16
Coming up: X.509 Certificates
X.509 Certificates
X.509 is a widely followed standard for digital certificates. An X.509v3
certificate has the following components:
1.
2.
3.
4.
5.
6.
7.
Version: version of X.509 used;
Serial number: unique among certificates issued by this issuer;
Signature algorithm identifier: identifies the algorithm and params
used to sign the certificate;
Issuer’s distinguished name: with serial number, makes all
certificates unique;
Validity interval: start and end times for validity;
Subject’s distinguished name: identifies the party being “vouched
for”;
Subject’s public key info: identifies algorithm, params, and public
key;
Coming up: X.509 Certificates (Cont.)
17
X.509 Certificates (Cont.)
8.
Issuer’s unique id: used if an Issuer’s distinguished name is ever
reused;
9. Subject’s unique id: same as field 8, but for the subject;
10. Extensions: version specific information;
11. Signature: identifies the algorithm and params, and the signature
(encrypted hash of fields 1 to 10).
To validate the certificate, the user:
• obtains the issuer’s public key for the algorithm (3);
• verifies the signature (11);
• recompute the hash and compare with the received value;
• check the validity interval.
• Try it: openssl s_client -showcerts -connect www.suntrust.com:443
Coming up: Lessons
18
Lessons
• Certificates can be combined to produce a chain of trust.
• To be useful the chain must be rooted in a trusted authority.
• X.509 is a widely followed international standard for
certificates.
19
End of presentation