Lecture 10 Overview
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
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
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
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
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
Public-Key Authority CS 450/650 Lecture 10: Key Exchange 7
Public-Key Certificates • certificates allow key exchange without realtime 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
Public-Key Certificates CS 450/650 Lecture 10: Key Exchange 9
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
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
Public-Key Distribution of Secret Keys • if have securely exchanged public-keys: CS 450/650 Lecture 10: Key Exchange 12
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
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
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 gk ≡ a (mod p) • each user generates their key – chooses a secret key (number): a < p – compute their public key: A = ga mod p CS 450/650 Lecture 10: Diffie-Hellman Key Exchange 15
Diffie-Hellman Key Exchange • shared session key for users is KAB: – KAB = gab mod p = Ab mod p (which B can compute) = Ba 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
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-themiddle attack – authentication of the keys is needed CS 450/650 Lecture 10: Diffie-Hellman Key Exchange 17
Lecture 11 Digital Certificates CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Robin Burke
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
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).
Digital certificates • amazon. com name X. 509 certificate public key
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
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
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
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
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
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
Issues • Trust in the CA – issuance policies • Security of the CA's private key – very important!!!
Multiple CAs • If there is only one CA – all is simple • Multiple CAs – Alice's public key is signed by C 1 – Bob's public key is signed by C 2 • How can Bob be confident? – maybe C 1 is really Trudy in disguise
Solutions • Full distribution – every user has the public key for every CA – Impractical • Cross certification – Suppose Alice presents Bob with C 1's public key – Signed by C 2 – Bob can verify the certificate C 2 – C 1's public key can be trusted – Therefore Alice's public key can be trusted
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
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
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
Certificate assumptions • During the valid period – public key is valid for use – association with identity assumed correct – revocation notifications will be published
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?
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
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.
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
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
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
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
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
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
Obtaining a certificate Bob’s public key + KB Bob’s identifying information Digital signature (encrypt) CA private key + KB K- CA certificate for Bob’s public key, signed by CA
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
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 10 x the message size • What if Bob already has Alice's public key?
Certificate + Signature • Inefficient • Not practical in network environment • Different users might need different certification paths – can't predict which certificates to include
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
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 + KB digital signature (decrypt) CA public key K CA + KB Bob’s public key
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
LDAP Directory services • Useful subset of X. 500 • Easier to implement than X. 500 • Widely available – Uses X. 509 certificates
X. 509 Certificate format
Example of a Certificate • Serial number (unique to issuer) • info about certificate owner, including algorithm and key value itself (not shown) • info about certificate issuer • valid dates • digital signature by issuer
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
Directory Information Tree • Country – C=US, Canada, Mexico, etc. • Organization – O=De. Paul University, UIC, Northwestern University, etc. • Organizational unit – OU=CTI, LA&S, Commerce, Theater, etc. • Common Name – CN=Robin Burke, Yonghe Yan, etc.
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=De. Paul University, OU=CTI, CN=Robin Burke}
Name collision • Typically we augment the common name with some other identifier – employee / student id – email address
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
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
Скачать презентацию Lecture 10 Overview Key Management public-key
b49b10c46813f1b870075816b6390a2c.ppt