Coming up: Digital Signatures

Digital SignaturesDan FleckCS 469: Security Engineering

These slides are modified with permission from Bill Young (Univ of Texas)

1

Coming up: Digital Signatures Properties

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?

2

Coming up: Digital Signatures (Cont.)

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 Properties

Digital Signatures (Cont.)

Public key systems are well-suited for digital signatures. Recall that some algorithms, RSA in particular, have the following characteristic:

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

Most often, it’s not the M but a hash of M that is signed. Why?What assurance does R gain from this interchange?

4

Coming up: Lessons

Digital Signatures Properties

S sends to R the following message:

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. 5

Coming up: Certificates

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: Web of Trust

CertificatesDan FleckCS 469: Security Engineering

These slides are modified with permission from Bill Young (Univ of Texas)

7

Coming up: Need for Trust

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.

8

Coming up: Certificates

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. 9

Coming up: How it Might Work

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: Validating the Certificate

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

This last then becomes Y ’s certificate, signed by X

11

Coming up: Lessons

Validating the Certificate

Suppose Y presents to Z the certificate :

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. 12

Coming up: Certificates and Trust

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: Chains of 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: Certification Authorities

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: X.509 Certificates

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 (Cont.)

X.509 Certificates

X.509 is a widely followed standard for digital certificates. An X.509v3 certificate has the following components:

1. Version: version of X.509 used;2. Serial number: unique among certificates issued by this issuer;3. Signature algorithm identifier: identifies the algorithm and

params used to sign the certificate;4. Issuer’s distinguished name: with serial number, makes all

certificates unique;5. Validity interval: start and end times for validity;6. Subject’s distinguished name: identifies the party being

“vouched for”;7. Subject’s public key info: identifies algorithm, params, and public

key;

17

Coming up: Lessons

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

18

End of presentation

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