Digital Signatures

1. 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)

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? 2 Coming up: Digital Signatures Properties

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

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

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

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

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

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. 8 Coming up: Need for Trust

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

10. Certificates A certificateis 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

11. How it Might Work Suppose X is the president of a company; Y is her subordinate. Each have an RSA public key pair. • Y securely passes message {Y ,KY } to X. • X produces a cryptographic hash of the message, i.e., h({Y ,KY }). • X produces This last then becomes Y ’s certificate, signed by X 11 Coming up: Validating the Certificate

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 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: Lessons

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

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

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

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

17. X.509 Certificates X.509 is a widely followed standard for digital certificates. An X.509v3 certificate has the following components: • Version: version of X.509 used; • Serial number: unique among certificates issued by this issuer; • Signature algorithm identifier: identifies the algorithm and paramsused 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; 17 Coming up: X.509 Certificates (Cont.)

18. X.509 Certificates (Cont.) • Issuer’s unique id: used if an Issuer’s distinguished name is ever reused; • Subject’s unique id: same as field 8, but for the subject; • Extensions: version specific information; • 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); • recomputethe hash and compare with the received value; • check the validity interval. • Try it: openssls_client -showcerts -connect www.suntrust.com:443 18 Coming up: Lessons

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