Lecture 15. Public Key Distribution (certification) PK-based Needham-Schroeder TTP. 3. [N a, A] PKb 6. [N a, N b ] PKa. 7.

Transcription

1 Lecture 15 Pulic Key Distriution (certifiction) 1 PK-sed Needhm-Schroeder TTP 1. A, B 4. B, A 2. {PK, B}SKT 5. {PK, A} SKT SKs A 2. {PK, B} SKs 3. [N, A] PK 6. [N, N ] PK B 7. [N ] PK Here, TTP cts s n on-line certifiction uthority (CA) nd tkes cre of revoction 2 1

2 x.509 Authentiction & Key Distriution Protocols How does Alice get PK nd Bo PK? One-wy A B à {1, t, r, B, other,[ K ] } PK B SK A Two-wy A B à {2, t, r, B, other,[ K ] } PK {2, t, r, A, r, other,[ K ] } B PK A SK A SK B Three-wy A B ß à {3, t, r, B, other,[ K ] } PK {3, t, r, A, r, other,[ K ] } {3, r } SK A B PK A SK A SK B 3 Wht if? Alice nd Bo hve: No common mutully trusted TTP(s) nd/or No on-line TTP(s) 4 2

3 Pulic Key Infrstructure (Distriution) Prolem: How to determine the correct pulic key of given entity Binding etween IDENTITY nd PUBLIC KEY Possile ttcks Nme spoofing: Eve ssocites Alice s nme with Eve s pulic key Key spoofing: Eve ssocites Alice s key with Eve s nme DoS: Eve ssocites Alice s nme with nonsensicl (ogus) key Wht hppens in ech cse? 5 Pulic Key Distriution Diffie - Hellmn (1976) proposed the pulic file concept universlly ccessile no unuthorized modifiction poor ide à not sclle! 6 3

4 Pulic Key Distriution Popek - Kline (1979) proposed trusted third prties (TTPs) TTPs know pulic keys of the entities nd distriute them on-demnd sis on-line protocol ( disdvntge) 7 Certifictes Kohnfelder (BS Thesis, MIT, 1978) proposed certifictes s yet nother pulic-key distriution method Explicit inding etween the pulic-key nd its owner/nme Issued (digitlly signed) y the Certificte Authority (CA) Issunce is done off-line 8 4

5 Authenticted Pulic-Key-sed Key Exchnge (Sttion-to-Sttion or STS Protocol) Choose rndom v Compute v K = ( y ) mod p SIG = { y, y } lice lice y v = mod p CERT, y, SIG o CERT lice, SIG lice o Choose rndom w, Compute w K = ( y ) mod p w y = mod p SIG = { y, y } o Bo CERT lice CERT o 9 Certifictes Procedure Bo registers t locl CA Bo receives his certificte: { PK B, ID B, issunce_time, expirtion_time, ert, etc.,...}sk CA Bo sends certificte to Alice Alice verifies CA s signture PK CA hrd-coded in softwre Alice uses PK B for encryption nd/or verifying signtures 10 5

6 Who issues certifictes? CA: Certifiction Authority e.g. GlolSign, VeriSign, Thwte, etc. look into your rowser... Trustworthy (t lest to its users/clients) Off-line opertion (usully) Hs well-known long-term certificte My store client certifictes Very secure: physiclly nd electroniclly 11 How does it work? A pulic/privte key-pir is generted y user User requests certificte vi locl ppliction (e.g., we rowser) Good ide to prove knowledge of privte key s prt of the certificte request. Why? Pulic key nd nme usully prt of PK certificte Privte keys only used for smll mount of dt (signing, encryption of session keys) Symmetric keys (e.g., RC5, AES) used for ulk dt encryption 12 6

7 CA CA checks tht requesting user is who he clims to e (in the certificte request) CA s own certificte is signed y higher-level CA. Root CA s certificte is self-signed nd his identity/nme is well-known CA is criticl prt of the system nd must operte in secure nd predictle wy ccording to some policy 13 Who needs them? Alice s certificte is checked y whomever wnts to: 1) verify her signtures, nd/or 2) encrypt dt for her. A verifier must: know the pulic key of the CA(s) trust ll CAs involved Certificte checking is: verifiction of the signture nd vlidity Vlidity: expirtion + revoction checking 14 7

8 Verifying certificte (ssuming common CA) To e covered lter 15 BTW: Certificte types PK (Identity) certifictes Bind PK to some identity string Attriute certifictes Bind PK to ritrry ttriute informtion, e.g., uthoriztion, group memership We concentrte on former 16 8

9 Wht re PK certifictes good for? Secure chnnels in TLS / SSL for we servers Signed nd/or encrypted emil (PGP,S/MIME) Authentiction (e.g., SSH with RSA) Code signing! Encrypting files (EFS in Windows/2000) IPSec: encryption/uthentiction t the network lyer 17 Components of certifiction system Request nd issue certifictes (different ctegories) with verifiction of identity Storge of certifictes (WHY?) Pulishing/distriution of certifictes (LDAP, HTTP) Pre-instlltion of root certifictes in trusted environment Support y OS pltforms, pplictions nd services Mintennce of dtse of issued certifictes (no privte keys!) Helpdesk (informtion, lost + compromised privte keys) Advertising revoked certifictes (nd support for pplictions to perform revoction checking) Storge guidelines for privte keys 18 9

10 CA Security Must minimize risk of CA privte key eing compromised Best to hve n off-line CA Requests my come in electroniclly ut not processed in rel time Also, distriuted CA (using threshold crypto) Microsoft recommends using CA hierrchy where root CA is off-line nd signing CA re on-line In ddition, using tmper-resistnt hrdwre for the CA would help (should e impossile to extrct privte key) 19 Mpping personl certifictes into ccounts/nmes Certificte must mp one-to-one into n ccount/nme for the ske of uthentiction In some systems, mpping re sed upon X.509 nming ttriutes from the Suject field Exmple: Verisign issues certificte s CN=Full Nme (ccount) Account/nme is locl to the issuing domin 20 10

11 Storge of privte key The prolem of hving the user to mnge the privte key (user support, key loss or compromise) Windows offers the CryptoAPI + Protected Storge which sves privte keys (encrypted) in the Protected Storge, prt of the roming user profile. MS pps like IE nd Outlook tke dvntge of this; Netscpe sves privte keys encrypted in its configurtion directory users who mix pplictions or pltforms must mnully import / export privte keys vi PFX files. 21 Key lengths Strong encryption hs een dopted since the relxtion of US export lws 512-it RSA nd 56-it DES re not sfe Root CA should hve n (RSA) key length of >= 2048 its given its importnce nd typicl lifetime of 3-5 yers A personl (RSA) certificte should hve key length of >= 1536 its Interoperility with older stuff? E.g., when using encryption (s in SSL) need to test tht newer rowsers still work with low encryption 56-its DES 22 11

12 Nming comes first! Cnnot hve certifictes without comprehensive nming scheme Cnnot hve PKI without comprehensive distriution/ ccess method X.509 uses X.500 nming X.500 Distinguished Nmes (DNs) contin suset of: C Country SP Stte/Province L Loclity O Orgniztion OU Orgniztionl Unit CN Common Nme 23 X.500 ISO stndrd for directory services glol, distriuted first solid version in (second in 1993.) documenttion - severl RFC s 24 12

13 X.500 dt model: sed on hierrchicl nmespce Directory Informtion Tree (DIT) geogrphiclly orgnized entry is defined with its dn (Distinguished Nme) serching: you must select loction in DIT to se your serch one-level serch or sutree serch sutree serch cn e slow 25 X DIT World c=af... c=usa... o=al QAEDA o=army... cn=osm in Lden (decesed)... dn: cn=osm in Lden, o=al Qed, c=af 26 13

14 X.500 ccessile through: telnet (client progrms known s du, dish,...) WWW interfce For exmple: hrd to use nd very hevy thus LDAP ws developed 27 LDAP LDAP - Lightweight Directory Access Protocol LDAP v2 - RFC 1777, RFC 1778 LDAP v3 - RFC 1779 developed to mke X.500 esier to use provides sic X.500 functions referrl model insted originl chining server informs client to sk nother server (without sking question on the ehlf of client) LDAP URL formt: ldp://server_ddress/dn (ldp://ldp.uci.edu/cn=gene Tsudik,o=UCI,c=US) 28 14

15 Some relevnt stndrds The IETF reference site Pulic-Key Infrstructure (X.509, PKIX) RFC 2459 (X.509 v3 + v2 CRL) LDAP v2 for certificte nd CRL storge RFC 2587 Guidelines & prctices RFC 2527 S/MIME v3 RFC 2632 & 2633 TLS 1.0 / SSL v3 RFC