210 likes | 309 Views
Public Key Management. Lecture 5. Outline. Key management with asymmetric encryption Diffie-Hellman key exchange. Key Management (public). public-key encryption helps address key distribution problems have two aspects of this: distribution of public keys
E N D
Public Key Management Lecture 5
Outline • Key management with asymmetric encryption • Diffie-Hellman key exchange
Key Management (public) • 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
Distribution of Public Keys • can be considered as using one of: • Public announcement • Publicly available directory • Public-key authority • Public-key certificates
Public Announcement • users distribute public keys to recipients or broadcast to community at large • (e.g. post to a newsgroup) • major weakness is forgery • Weakness: anyone can create a key claiming to be someone else and broadcast it (impersonation attack)
Publicly available directory • Publicly available directory: Achieve greater security by registering keys with a public directory • Weakness: directory must be trusted and still vulnerable to forgery • Public-key certificates (next slide) • Public-key authority (a few slides later)
Digital Certificate • To encrypt using a receiver’s public key, the sender needs to be assured that the public key used corresponds to the private key of the receiver. • To verify a signature, a verifier needs to be assured that the public key used corresponds to the private key of the signer. • The electronic document that attests to the ownership of a public key is called a certificate. • How it works: • There is an entity called Certification Authority (CA) • Everyone trusts the certificates issued by the CA • CA has a public key which is publicly known • e.g. built in all the web browsers • CA issues a certificate by generating a signature on the public key and the identity of its owner. • Only the CA can create a certificate • Anyone can determine the user ID of a certificate owner • Anyone can verify the authenticity of the certificate (using CA’s public key) • Anyone can verify the validity (e.g. expiry date) of a certificate CertA = < IDA, PKA, Validity Period, SignCA(IDA, PKA, Validity Period) >
Public-Key Certificates • Certificates allow key exchange without real-time access to public-key authority • a certificate binds the identity (of the public key pair owner) to a public key • usually with other info such as period of validity, rights of use etc • with all contents signed by a trusted Public-Key or Certificate Authority (CA) • can be verified by anyone who knows CA’s public key • E.g. CertAlice = < IDAlice, SN, Expiry, PKAlice, SigCA(IDAlice, SN, Expiry, PKAlice) > • So each user only needs to maintain a valid CA’s public key
digital signature (encrypt) PK PK B B Certification Authorities • Certification authority (CA): binds public key to particular entity, E. • E (person, router) registers its public key with CA. • E provides “proof of identity” to CA. • CA creates certificate binding E to its public key. • certificate containing E’s public key digitally signed by CA – CA says “this is E’s public key” Bob’s public key CA private key certificate for Bob’s public key, signed by CA Bob’s identifying information RK CA
digital signature (decrypt) PK B Certification Authorities • When Alice wants Bob’s public key: • gets Bob’s certificate (Bob or elsewhere). • apply CA’s public key to Bob’s certificate, get Bob’s public key Bob’s public key PK B CA public key PK CA
Verify the Public Key of a Web Server Internet Web Server • The web browser has CA’s public key built in. • In practice, there could have several trusted CAs for each web browser • New CAs can also be installed by users • The legitimacy of the web browser softwarebecomes crucial for ensuring the security of digital certificates • A certificate is NO more secure than the security of the web browser download site • Exercise: find out the information of three pre-installed CAs in Internet Explorer (PK, SK) Web Browser Cert = < IDserver, PK, Expiry, SignCA(…) >
Pre-installed CAs Public Key: (RSA 1024-bit) 30 81 89 02 81 81 00 cc 5e d1 11 5d 5c 69 d0 ab d3 b9 6a 4c 99 1f 59 98 30 8e 16 85 20 46 6d 47 3f d4 85 20 84 e1 6d b3 f8 a4 ed 0c f1 17 0f 3b f9 a7 f9 25 d7 c1 cf 84 63 f2 7c 63 cf a2 47 f2 c6 5b 33 8e 64 40 04 68 c1 80 b9 64 1c 45 77 c7 d8 6e f5 95 29 3c 50 e8 34 d7 78 1f a8 ba 6d 43 91 95 8f 45 57 5e 7e c5 fb ca a4 04 eb ea 97 37 54 30 6f bb 01 47 32 33 cd dc 57 9b 64 69 61 f8 9b 1d 1c 89 4f 5c 67 02 03 01 00 01
A Certificate e.g. User Name: login.yahoo.com Certificate Version: V3 Validity Period: Jan 28, 05 – Jan 29, 06 Serial No: 4b5c94d17508e86594593d777e4d7dc4 User’s Public Key: RSA (1024 bits) 30 81 89 02 81 81 00 be 33 b1 6b a6 f4 15 e9 54 d3 06 a4 c4 55 f2 ae db 4d 38 b2 ce 83 f9 06 cd ad a7 f6 d9 54 76 aa 0c f4 85 e1 b9 3a b1 30 b4 56 c3 e4 ae 5a 3a 98 8e 47 52 f5 be 72 5d 38 c1 a8 51 91 85 3b 28 7c f1 f4 a5 5b 19 74 8d 36 38 89 ae 26 3e 41 7a c1 b8 54 a9 4c 4e 69 6c 96 51 a5 12 f7 bc e5 78 45 c2 8f 83 f2 ac 39 b3 04 7a 44 20 d7 c8 ac 78 eb c7 ce 9c a5 25 48 33 ed 76 b9 6f 68 ef fc 80 6f 02 03 01 00 01 Other attributes: e.g. signing algorithm: sha1RSA CA’s name: Secure Server Certification Authority, RSA Data Security, Inc. CA’s signature: 1024-bit data CertA = < IDA, PKA, Validity Period,… SignCA(IDA, PKA, Validity Period, …) >
Public-Key Certificates Certificate Authority IDBob, PKBob IDAlice, PKAlice CertAlice CertAlice CertBob Alice Bob CertAlice = < IDAlice, SN, Expiry, PKAlice, SigCA(IDAlice, SN, Expiry, PKAlice) >
Distribution of Secret Keys usingPublic Key • public-key cryptography can be used for secrecy or authentication • but public-key algorithms are slow • We want to use symmetric key encryption algorithm encrypt bulk message • Because symmetric key encryption algorithms are hundreds of times faster than public key encryption algorithms • So two communicating parties usually • negotiate a symmetric key (called session key) with the help of public key algorithms • Then use the session key to encrypt messages • For each new session (e.g. login your online banking service again after closing the web browser), a new session key will be established
Public-Key Distribution of Secret Keys CertAlice CertBob session key negotiation … Bob Alice Public key encrypted Message flows … Session key encrypted
Diffie-Hellman Key Exchange • A Key Exchange Protocol: • provide a secure way for two communicating parties to share a symmetric key (so called a session key) • This session key is then used to provide privacy and authentication for subsequent message flow. • History: problem first posed by Merkle at UC Berkeley, Diffie and Hellman came up with the protocol: Alice Bob a R Zp-1 ga mod p b R Zp-1 gb mod p Shared Session Key = gab mod p • More details next…
Diffie-Hellman Key Exchange Setup • Alice and Bob agree on global parameters: • Large prime integer p (e.g. 1024 bits long) • g a primitive root / generator of Zp* (i.e. the multiplicative group modulo p) • Alice • chooses a random positive integer: a < p • computes yA = ga mod p • Bob does the same and generates yB = gb mod p
Diffie-Hellman Key Exchange • Shared session key for Alice and Bob is KAB: KAB = ga b mod p = yAb mod p (which Bob can compute) = yBa mod p (which Alice can compute) • KAB will then be used as a session key in symmetric key algorithms between Alice and Bob • Attacker needs to find KAB from yA and yB • A difficult problem
Diffie-Hellman Key Exchange Example Alice and Bob want to carry out DH Key Exchange: • Agree on prime p=353 and g=3 • Select random secret keys: • A chooses a = 97 • B chooses b = 233 • Compute session key contributions • yA = 397 mod 353 = 40 (Alice) • yB = 3233 mod 353 = 248 (Bob) • Compute shared session key as: KAB = yBa mod 353 = 24897 mod 353 = 160 (Alice) KAB = yAb mod 353 = 40233 mod 353 = 160 (Bob)