1. Lecture 10 Overview

2. Key Management public-key encryption helps address key distribution problems have two aspects of this: – distribution of public keys – use of public-key encryption to distribute secret keys CS 450/650 Lecture 10: Key Exchange 2

3. Distribution of Public Keys can be considered as using one of: – public announcement – publicly available directory – public-key authority – public-key certificates CS 450/650 Lecture 10: Key Exchange 3

4. Public Announcement users distribute public keys to recipients or broadcast to community at large – eg. append PGP keys to email messages or post to news groups or email list major weakness is forgery – anyone can create a key claiming to be someone else and broadcast it – until forgery is discovered attacker can masquerade as claimed user CS 450/650 Lecture 10: Key Exchange 4

5. Publicly Available Directory can obtain greater security by registering keys with a public directory directory must be trusted with properties: – contains {name, public-key} entries – participants register securely with directory – participants can replace key at any time – directory is periodically published – directory can be accessed electronically still vulnerable to tampering or forgery CS 450/650 Lecture 10: Key Exchange 5

6. Public-Key Authority improve security by tightening control over distribution of keys from directory has properties of directory requires users to know public key for the directory users interact with directory to obtain any desired public key securely requires real-time access to directory when keys are needed CS 450/650 Lecture 10: Key Exchange 6

7. Public-Key Authority CS 450/650 Lecture 10: Key Exchange 7

8. Public-Key Certificates certificates allow key exchange without real- time access to public-key authority a certificate binds identity to public key – usually with other info such as period of validity, rights of use all contents signed by a trusted Public-Key or Certificate Authority (CA) can be verified by anyone who knows the public-key authority’s public-key CS 450/650 Lecture 10: Key Exchange 8

9. Public-Key Certificates CS 450/650 Lecture 10: Key Exchange 9

10. Distribution of Secret Keys use previous methods to obtain public-key can use for secrecy or authentication public-key algorithms are slow usually prefer to use private-key encryption to protect message contents hence need a session key have several alternatives for negotiating a suitable session CS 450/650 Lecture 10: Key Exchange 10

11. Simple Secret Key Distribution proposed by Merkle in 1979 – A generates a new temporary public key pair – A sends B the public key and the identity – B generates a session key K sends it to A encrypted using the supplied public key – A decrypts the session key and both use Man in the middle attack: – an opponent can intercept and impersonate both halves of protocol CS 450/650 Lecture 10: Key Exchange 11

12. Public-Key Distribution of Secret Keys if have securely exchanged public-keys: CS 450/650 Lecture 10: Key Exchange 12

13. Diffie-Hellman Key Exchange public-key type scheme – proposed in 1976 – note: now know that Williamson (UK CESG) secretly proposed the concept in 1970 A practical method for public exchange of a secret key Used in a number of commercial products CS 450/650 Lecture 10: Diffie-Hellman Key Exchange 13

14. Diffie-Hellman Key Exchange public-key distribution scheme – cannot be used to exchange an arbitrary message – rather it can establish a common key – known only to the two participants based on exponentiation in a finite field – modulo a prime or a polynomial security relies on the difficulty of computing discrete logarithms CS 450/650 Lecture 10: Diffie-Hellman Key Exchange 14

15. Diffie-Hellman Setup all users agree on global parameters: – large prime integer or polynomial p – g = primitive root mod p for every integer a that has gcd(a, p) = 1, there is an integer k such that g k ≡ a (mod p) each user generates their key – chooses a secret key (number): a < p – compute their public key: A = g a mod p CS 450/650 Lecture 10: Diffie-Hellman Key Exchange 15

16. Diffie-Hellman Key Exchange shared session key for users is K AB : – K AB = g ab mod p = A b mod p (which B can compute) = B a mod p (which A can compute) g can be small – 2 or 5 is common a, b, p should be large attacker needs a or b to obtain the session key – must solve discrete log CS 450/650 Lecture 10: Diffie-Hellman Key Exchange 16

17. Key Exchange Protocols users could create random Diffie-Hellman keys each time they communicate users could create a known Diffie-Hellman key and publish in a directory, then consulted and used to securely communicate with them both of these are vulnerable to a man-in-the- middle attack – authentication of the keys is needed CS 450/650 Lecture 10: Diffie-Hellman Key Exchange 17

18. Lecture 11 Digital Certificates CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Robin Burke

19. Trusting a Public Key We can't trust – the public key associated with a message We might trust – an authoritative source to vouch for Alice

20. Digital Certificates A digital certificate is a digital file that certifies the identity of – an individual, – an institution, – a server, – a router seeking access to computer- based information. It is issued by a Certification Authority (CA).

21. Digital certificates amazon.com name public key X.509 certificate

22. Trusted third party Certification authority (CA) They issue digital certificates and validate holders’ identity and authority. CA can – meet with Alice – look at her driver's license / birth certificate / etc – take her fingerprints CA will then – sign her public key

23. Man-in-the-middle? When Trudy tries to substitute her public key for Alice's – Bob will either notice that the key isn't certified, or – Notice that it is certified but not for Alice, for someone else

24. Masquerading as CA? Trudy could falsely issue a certificate – sign the certificate pretending to be the CA But – strong interest in making CA’s correct public key well known Multiple sources to access the CA's public key – Some public keys are actually bundled with IE

25. Public key certificate A public key An identifier Certificate by the CA – Embed public key along with other identifying information – cryptographically sign it as a tamper-proof seal verifying the integrity of the data within the certificate validating its use

26. Benefits of certification Alice and Bob can exchange certificates directly – no need for a separate way to communicate public keys – certificate is self-protecting Many users can participate – only need to know CA's public key

27. Uses of Digital Certificates In a number of Internet applications that include: 1.Secure Socket Layer (SSL) developed by Netscape Communications Corporation 2.Secure Multipurpose Internet Mail Extensions (S/MIME) Standard for securing email and electronic data interchange (EDI). 3.Secure Electronic Transactions (SET) protocol for securing electronic payments 4.Internet Protocol Secure Standard (IPSec) for authenticating networking devices

28. Issues Trust in the CA – issuance policies Security of the CA's private key – very important!!!

29. Multiple CAs If there is only one CA – all is simple Multiple CAs – Alice's public key is signed by C1 – Bob's public key is signed by C2 How can Bob be confident? – maybe C1 is really Trudy in disguise

30. Solutions Full distribution – every user has the public key for every CA – Impractical Cross certification – Suppose Alice presents Bob with C1's public key – Signed by C2 – Bob can verify the certificate C2 – C1's public key can be trusted – Therefore Alice's public key can be trusted

31. Hierarchical trust model Root CA – a generally-trusted CA e.g. Federal Reserve Bank – all parties trust root Non-root CAs – have certificates signed by root CA, or – signed by another non-root CA closer to the root CA Certification path – the chain of certifications from the root to a particular public key certificate

32. CA relationships Intra-organization communication – Bank ATM network – Organization can be its own CA The third party CA – CA is an independent entity – is like a notary public – is evaluating the truth of a person's representation – may be liable if due diligence is not performed

33. Validity Public key is not valid forever – limits risk associated with key compromise – 1 year is typical Certificates have a valid period – expired certificate may still be useful non-repudiation – new certificate issued when old one expires Possibly the same key re-certified

34. Certificate assumptions During the valid period – public key is valid for use – association with identity assumed correct – revocation notifications will be published

35. Non-repudiation Non-repudiation and repudiation of signatures involved in legal practice for untold generations. Traditional paper signatures may be repudiated: – False signature – Real signature, but extenuating circumstances Unconscionable conduct / inequality of bargaining power Fraud Undue influence, or signature made under duress

36. Non-repudiation Increasing legislation to allow digital signatures to serve as legally binding. Non-repudiation as applied to digital signatures: – Provides proof of the integrity and origin of data, both unforgeable, which can be verified by any third party at any time. – An authentication that with high assurance can be asserted to be genuine and that cannot subsequently be refuted. Thoughts? Comments?

37. Revocation What if Trudy hacks into Bob's computer and steals his private key? – Alice will still be sending encrypted messages, but now Trudy can read Certificate must be revoked – can no longer be trusted – new certificate issued – how does Alice find this out?

38. Revoking a certificate Reasons for revocation – Detected or suspected compromise – Change of data e.g. subject name – Change of relationship between subject and CA e.g. employee quitting a job from an organization which uses the current CA

39. Who can revoke? who revokes? – the subject – the CA – an authorized third party e.g. the organization with an employee quitting Authentication of the source of revocation request is needed.

40. Certificate Revocation List CRL is a time-stamped list of revoked certificates, – digitally signed by the CA – available to all users Each revoked cert is identified by a certificate serial number CRL contains digital signatures, thus can be sent via unprotected channels Users of public key certificates should check a suitably-recent CRL

41. Certificate Revocation List The user of a public key – must check the CRL – every time the key is used – not enough to check when the certificate is originally accepted CA – must keep a revoked certificate in the CRL until it expires – list could get large

42. Example Trudy steals Bob's private key Bob discovers break-in – requests certificate revocation Trudy sends a forged message to Alice Alice verifies message – checks CRL – no problems with Bob's public key CA publishes CRL with Bob's revocation – too late

43. CRL Distribution Pull method – CA periodically updates CRL depository – users check when using a public key Push method – broadcast new CRL when it changes Both subject to denial of service attacks

44. CRLs Problems similar to blacklists with credit card companies – Database is periodically pruned, but still very large – Time delay between certificate being revoked and revocation being published in CRL Widely-used CRLs have too many verifiers to be able to effectively use the “push” method. Susceptible to DOS attacks – Is the software default to accept or reject the certificate?

45. Online Certificate Status Protocol Request / response protocol – Verifier receives up-to-the-minute status info Alice checks Bob's public key directly with CA – most effective – most costly Costs – handling traffic for every public key use – handling cryptographic operations at high spped – maintaining high security in Internet environment Also subject to denial of service attack

46. Short-Lived Certificates Certificate valid for 1 day at a time – re-requested each day – possibly the same public key Revocation not necessary – client stops asking for a new certificate Suitable for limited resource systems – e.g. mobile wireless systems Assumes efficient certificate generation

47. Obtaining a certificate 1.Subscriber generates a public\private key pair. Applies to CA for digital certificate with the public key. 2.CA verifies subscriber's identity and issues digital certificate containing the public key. 3.CA publishes certificate to public, on-line repository. 4.Subscriber signs message with private key and sends message to second party. 5.Receiving party verifies digital signature with sender's public key and requests verification of sender's digital certificate from CA's public repository. 6.Repository reports status of subscriber's certificate.

48. Bob’s public key Bob’s identifying information CA private key K B + certificate for Bob’s public key, signed by CA Digital signature (encrypt) K B + K CA - Bob’s public key Bob’s identifying information CA private key K B + certificate for Bob’s public key, signed by CA K B + K CA Obtaining a certificate

49. CA's key management CA keys have many uses – signing (real-time validation) – historical validation Short-use private keys – better security But – a signed certificate can't have a valid period beyond the signer's certificate CA will need multiple keys for different purposes

50. Certificate distribution Alice sends Bob a two line signed email – signature ≈ message size – certificate > message size Alice's public key + CA's signature – certificate for each CA in certification path Certification info could easily be 10x the message size What if Bob already has Alice's public key?

51. Certificate + Signature Inefficient Not practical in network environment Different users might need different certification paths – can't predict which certificates to include

52. Directory services General case for public key discovery Online access to a directory – request a public key certificate for a given user In this case – Alice sends only the signed message – Bob is responsible for getting Alice's certificate

53. Obtaining an Individual’s Public Key – When Alice wants Bob’s public key: Alice gets Bob’s certificate (from Bob or elsewhere). apply CA’s public key to Bob’s certificate, get Bob’s public key K B + digital signature (decrypt) K B + CA public key K CA Bob’s public key

54. X.500 Directory services Developed by the international standards bodies Extremely general – look up by name – browse available entities – representing people, devices, applications, etc. Extension for public key certificates – X.509

55. LDAP Directory services Useful subset of X.500 Easier to implement than X.500 Widely available – Uses X.509 certificates

56. X.509 Certificate format

57. Serial number (unique to issuer) info about certificate owner, including algorithm and key value itself (not shown) Example of a Certificate info about certificate issuer valid dates digital signature by issuer

58. IDs Many things need to be identified – what algorithm? – who is the CA? – whose key are we signing? X.500 Names – every unique individual must have a unique name – hierarchical naming scheme X.500 Object Identifiers – for things like algorithms – also hierarchical – but with integer components

59. Directory Information Tree Country – C=US, Canada, Mexico, etc. Organization – O=DePaul University, UIC, Northwestern University, etc. Organizational unit – OU=CTI, LA&S, Commerce, Theater, etc. Common Name – CN=Robin Burke, Yonghe Yan, etc.

60. Distinguished name A collection of choices at each level of the DIT – leading to an individual Not necessarily a person – printer, router, application, web server DN – {C=US, O=DePaul University, OU=CTI, CN=Robin Burke}

61. Name collision Typically we augment the common name with some other identifier – employee / student id – email address

62. Object identifiers Problem – different organization may want their own "objects" – impossible to create a list of legal values in advance Like DIT tree – but with integers Used to label – algorithms – certificate types

63. Example 1.2.840.113549.1.1.5 – this is a digital signature algorithm SHA-1 from RSA Labs How do we know this? – 1 = ISO – 2 = Indicates a member of the organization – 840 = the USA – 113549 = RSA's organizational id – RSA chooses the rest of the identifiers

64. X.509 Version 3 Versions 1 and 2 of X.509 did not work well for public key management Problems – multiple public keys per user – additional required information for some purposes – all certificates not created equal

65. X.509 Extensions Instead of fixing all the fields in v. 3 – an "extension mechanism" – allow organizations to define their own certificate components Extensions – must be registered (object identifier) – criticality indicator

66. Standard extensions Authority key ID – CA's may have multiple signing keys – helps to build certification path Key usage – what the certified key is for Certificate policies – under what policy was the certificate issued – degree of authentication Path constraints – what is a legal certification path from this certificate

67. Version 3 naming Much more flexible naming scheme – X.500 names OK Others – email address – domain name – IP address – URL

68. X.509 CRL format Similar to certificate itself Also – date/time of issue of this CRL – date/time of issue of next CRL List of revoked certs: – user certificate: cert serial number – revocation date CRL extensions