1. Digital Signatures Dan Fleck CS 469: Security Engineering These slides are modified with permission from Bill Young (Univ of Texas) Coming up: Digital Signatures 11

2. 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 22

3. 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. Coming up: Digital Signatures (Cont.) 33

4. 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? Coming up: Digital Signatures Properties 44

5. Digital Signatures Properties S sends to R the following message: This scheme has the desired properties: unforgeable: only S can use K S -1 ; authentic: a third party can verify the signature with K S ; no repudiation : only S can use K S -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 55

6. 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. Coming up: Certificates 66

7. Certificates Dan Fleck CS 469: Security Engineering These slides are modified with permission from Bill Young (Univ of Texas) Coming up: Web of Trust 77

8. 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 88

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

10. 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 Coming up: How it Might Work 10

11. 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,K Y } to X. 2.X produces a cryptographic hash of the message, i.e., h({Y,K Y }). 3.X produces This last then becomes Y ’s certificate, signed by X Coming up: Validating the Certificate 11

12. 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 K Y. X is the certifying authority. Data items Y and K Y 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

13. 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 Coming up: Certificates and Trust 13

14. 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. Coming up: Chains of Trust 14

15. 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. Coming up: Certification Authorities 15

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

17. 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; Coming up: X.509 Certificates (Cont.) 17

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

19. 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. End of presentation 19