David Evans http://www.cs.virginia.edu/evans

1. Lecture 14: Public Key Infrastructure David Evans http://www.cs.virginia.edu/evans CS588: Security and Privacy University of Virginia Computer Science

2. Using RSA to Encrypt • Use 1024-bit modulus (RSA recommends >= 768) • Encrypt 1M file • 1024 1024-bit messages • To calculate Me requires log2e 1024-bit modular multiplies • Why does no one use RSA like this? • About 100-1000 times slower than DES • Need to be careful not to encrypt particular Ms • Can speed up encryption by choosing e that is an easy number to multiply by (e.g., 3 or 216 + 1) • But, decryption must use non-easy d (~1024 bits) CS588 Spring 2005

3. Alternatives • Use RSA to establish a shared secret key for symmetric cipher (DES, RC6, ...) • Lose external authentication, non-repudiation properties of public-key cryptosystems • Sign (encrypt with private key) a hash of the message • A short block that is associated with the message CS588 Spring 2005

4. RSA Paper “The need for a courier between every pair of users has thus been replaced by the requirement for a single secure meeting between each user and the public file manager when the user joins the system.” CS588 Spring 2005

5. Key Management Public keys only useful if you know: • The public key matches the entity you think it does (and no one else). • The entity is trustworthy. CS588 Spring 2005

6. Approach 1: Public Announcement • Publish public keys in a public forum • USENET groups • Append to email messages • New York Time classifieds • Easy for rogue to pretend to be someone else CS588 Spring 2005

7. Approach 2: Public Directory • Trusted authority maintains directory mapping names to public keys • Entities register public keys with authority in some secure way • Authority publishes directory • Print using watermarked paper, special fonts, etc. • Allow secure electronic access CS588 Spring 2005

8. Can we avoid needing an on-line directory? CS588 Spring 2005

9. Certificates Loren Kohnfelder, MIT 4th year thesis project, 1978: Towards a Practical Public-key Cryptosystem • “Public-key communication works best when the encryption functions can reliably be shared among the communicants (by direct contact if possible). Yet when such a reliable exchange of functions is impossible the next best thing is to trust a third party. Diffie and Hellman introduce a central authority known as the Public File… Each individual has a name in the system by which he is referenced in the Public File. Once two communicants have gotten each other’s keys from the Public File then can securely communicate. The Public File digitally signs all of its transmission so that enemy impersonation of the Public File is precluded.” CS588 Spring 2005

10. { bob@bob.com, KUB} CA = EKRTrustMe[“alice@alice.org”, KUA] CB = EKRTrustMe[“bob@bob.com”, KUB] CA CB Certificates TrustMe.com { alice@alice.org, KUA } Alice Bob Use anything like this? CS588 Spring 2005

11. Data encrypted using secret key exchanged using some public key associated with some certificate. CS588 Spring 2005

12. CS588 Spring 2005

13. KRCA[Server Identity, KUS] KUS[K] Secure channel using K SSL (Secure Sockets Layer)Simplified TLS Handshake Protocol Client Server Hello Check Certificate using KUCA Pick random K Find K using KRS Textbook, Section 12.5 CS588 Spring 2005

14. { bob@bob.com, KUB} CA = EKRTrustMe[“alice@alice.org”, KUA] CB = EKRTrustMe[“bob@bob.com”, KUB] CA CB Certificates VarySign { alice@alice.org, KUA } Alice Bob How does TrustMe.com decide whether to provide Certificate? CS588 Spring 2005

15. { bob@bob.com, KUB} CA = EKRTrustMe[“alice@alice.org”, KUA] CB = EKRTrustMe[“bob@bob.com”, KUB] CA CB Verifying Identities VarySign $$$$ { alice@alice.org, KUA } Alice Bob CS588 Spring 2005

16. With over half a million businesses authenticated, VeriSign follows a rigorous and independently audited authentication process. All involved VeriSign employees pass stringent background checks, and each authentication is split between multiple individuals. We maintain physically secure facilities, including biometric screening on entry. CS588 Spring 2005

17. VeriSign’s Certificate Classes • “Secure Site” SSL Certificate • Supports 40-bit session key • Proves: you are communicating with someone willing to pay VeriSign $598 (or with ~$1000 to break a 40-bit key) • Except they have a free 14-day trial (but it uses a different Trial CA key) CS588 Spring 2005

18. CS588 Spring 2005

19. “Secure Site Pro” Certificate • $995 per year • “true 128-bit key” “128-bit encryption offers 288 times as many possible combinations as 40-bit encryption. That’s over a trillion times a trillion times stronger.” trillion = 1012 trillion * trillion = 1024 Verisign’s marketing claim could be: “trillion times a trillion times a trillion times a trillion times a trillion times a trillion times a trillion times ten thousand (in Britain it is a trillions time a trillion times a trillion times a trillion times a billion times a thousand) times stronger” (but that would sound even sillier!) • Businesses authentication: “out-of-band” communication, records CS588 Spring 2005

20. CS588 Spring 2005

21. Limiting The Damage VarySign.com { alice@alice.org, KUA } CA = EKRTrustMe[“alice@alice.org”, cert id, expiration time, KUA] CA Alice Bob Checks expiration time > now CS588 Spring 2005

22. CS588 Spring 2005

23. EKRTrustMe[CRL] Revoking Certificates VarySign.com { alice@alice.org, KUA } CA Send me the CRL CA Alice <certid, Date Revoked> <certid, Date Revoked> <certid, Date Revoked> … Bob CS588 Spring 2005

24. Revoked! CS588 Spring 2005

25. Certificate Questions • How do participants acquire the authority’s public key? • If authority’s private key is compromised, everything is vulnerable! • Keep the key locked up well CS588 Spring 2005

26. Problems with Certificates • Depends on a certificate authority • Needs to be a big, trusted entity • Needs to make money (or be publically funded) • Need to acquire a certificate • Makes anonymity difficult • Requires handshaking CS588 Spring 2005

27. PGP (Pretty Good Privacy) • Keyring: list of public keys, signed by owner’s private key Alice’s keyring: EKRAlice (<“bob@bob.com”, KUBob>, <“cathy@sharky.com”, KUCathy>) • Exchanging Keyrings (Web of Trust) • Complete Trust: I trust Alice’s keyring (add the public key pairings to my own keyring) • Partial Trust: I sort of trust Alice, but require confirmation from someone else too (I need to get EKRCathy (<“bob@bob.com”, KUBob>) before trusting KUBob CS588 Spring 2005

28. Avoiding Certificates • What if your identity (e.g., your email address) is your public key? • Is it possible to do this with RSA? Do you want your email address to be a 200-digit “random” number? CS588 Spring 2005

29. Identity Based Encryption • [Shamir 1984], [Boneh & Franklin 2003] public-key = identity private-key = F(master-key, identity) The owner of the master-key is the new authority. Must be careful who it gives private keys to. CS588 Spring 2005

30. Key-Generating Service • Holds master-key • Participants request private keys from KGS • Sends s to KGS, requests corresponding private key • KGS authenticates requestor • If valid, computes F(master-key, s) and sends over secure channel • How does the trust given to the KGS compare to that given to CA in SSL? KGS can decrypt all messages! With certificates, certificate owner still has her own private key. But, CA can impersonate anyone by generating a certificate with a choosen public-key. CS588 Spring 2005

31. Shamir’s IBE Signature Scheme • Setup: done by KGS • Select p, q large primes • N = pq • Choose e relatively prime to  (N) (p-1)(q-1) • Choose dsatisfying ed 1 mod  (N) • Choose h a cryptographic hash function • Publish N, e and h to all participants • Keep d secret master-key CS588 Spring 2005

32. Shamir’s Signatures • Generating a private key privatekey(ID) = IDd mod N • Can only be done by KGS (d is master secret) • Signing a message M with identity ID • Obtain g = privatekey(ID) from KGS • Choose random r less than N • Compute signature (s, t): t = re mod N s = g rh(t || M) mod N Warning: book typesetting is off and wrong range for h! CS588 Spring 2005

33. Verifying a Signature • KGS produced g = IDd mod N • Recipient knows ID and M, system parameters e and N t = re mod N s = g rh(t || M) mod N • Verify (ID, s, t, M) se = ID th(t || M)mod N (IDdrh(t || M))e mod N IDderh(t || M)e mod N IDreh(t || M) mod N  IDth(t || M) mod N What does non-forgability of a Shamir IBE signature rely on? CS588 Spring 2005

34. Identity-Based Encryption • Shamir’s scheme – signatures only, not encryption • Boneh & Franklin, 2001 • First practical and provably secure IBE scheme • Builds on elliptic curves CS588 Spring 2005

35. Issues in IBE • Complete trust in KGS • With Boneh & Franklin’s system can use secret sharing techniques to divide this trust among multiple entities • Could you do this with Shamir’s IBE signatures? • Revocation • Can include expiration times in identities • But no way to revoke granted private keys CS588 Spring 2005

36. Charge • Read Chapter 13 in the book • Look at the certificate chains when you browse the web • Find a certificate with a trust chain more than two levels deep • Update your browser CRLs: when were they last updated? CS588 Spring 2005