Document Sample

Key Management CS461/ECE422 1 Reading • Chapter 10 in Computer Security: Art and Science • Handbook of Applied Cryptography http://www.cacr.math.uwaterloo.ca/hac/ – Section 11.3.2 attack on RSA signature – Section 13.8.3 Key Escrow 2 Key Management Motivation • Cryptographic security depends on keys – Size – Generation – Retrieval and Storage • Example – House security system no good if key or code is under the mat 3 Overview • Key Generation • Key Exchange and management – Classical (symmetric) – Public/private • Digital Signatures • Key Storage 4 Key Management Processes associated with – Distribution of keys – Binding identities to keys – Generation, maintenance, and revoking keys Notation • X Y : { Z || W } kX,Y – X sends Y the message produced by concatenating Z and W encrypted by key kX,Y, which is shared by users X and Y • A T : { Z } kA || { W } kA,T – A sends T a message consisting of the concatenation of Z encrypted using kA, A’s key, and W encrypted using kA,T, the key shared by A and T • r1, r2 nonces (nonrepeating random numbers) 6 Session and Interchange Keys • Long lived Interchange Keys only exist to boot strap – Associated with a principal to the communication, e.g. public keys Kb,Ka below • Short lived session keys used for bulk encryption, e.g. Ka,b Ka,b Ka,b Kb,Ka Ka,Kb {Ka,b}Ka {m1}Ka,b 7 Session and Interchange Keys • Another view---key and message in one shot • Alice wants to send a message m to Bob – Assume public key encryption – Alice generates a random cryptographic key ks and uses it to encrypt m • To be used for this message only, not used for authentication • Called a session key – She encrypts ks with key kB • kB encrypts all session keys Alice uses to communicate with Bob : known by Bob, shared with Alice • Called an interchange key. Used for authentication – Alice sends { m } ks ||{ ks } kB Message m coded with ks Message ks coded with kB 8 Benefits • Limits amount of traffic encrypted with single key – Standard practice, to decrease the amount of traffic an attacker can obtain • Prevents some attacks. e.g., – Suppose long lived key (public, or broken) kB – Suppose set of possible messages is small, e.g. “BUY” or “SELL” – Attack can pre-compute possible ciphertexts, observe, compare – Example: Alice will send Bob message that is either “BUY” or “SELL”. Eve computes possible ciphertexts { “BUY” } kB and { “SELL” } kB. Eve intercepts encrypted message, compares, and gets plaintext at 9 once Key Generation • Goal: generate keys that are difficult to guess • Problem statement: given a set of K potential keys, choose one randomly – Equivalent to selecting a random number between 0 and K–1 inclusive • Why is this hard: generating random numbers – Actually, numbers are usually pseudo-random, that is, generated by an algorithm 10 What is “Random”? • Sequence of cryptographically random numbers: a sequence of numbers n1, n2, … such that for any integer k > 0, an observer cannot predict nk even if all of n1, …, nk–1 are known – Best: physical source of randomness • Random pulses • Electromagnetic phenomena • Characteristics of computing environment such as disk latency • Ambient background noise 11 What is “Pseudorandom”? • Sequence of cryptographically pseudorandom numbers: sequence of numbers intended to simulate a sequence of cryptographically random numbers but generated by an algorithm – Very difficult to do this well • Linear congruential generators [nk = (ank–1 + b) mod n] broken • Polynomial congruential generators [nk = (ajnk–1j + … + a1nk–1 a0) mod n] broken too • Here, “broken” means next number in sequence can be determined 12 Best Pseudorandom Numbers • Strong mixing function: function of 2 or more inputs with each bit of output depending on some nonlinear function of all input bits – Examples: DES (mixes key and data), MD5, SHA-1, (multi-stage functions in hashing) avalanche effect • Inputs need to be unpredictable 13 Key Exchange Principals to communication need to agree on key to be used. Criteria – Key should not be transmitted in the clear • Solutions : encrypt when sent, derive from public keys (e.g. Diffie-Hellman) • Assume attacker can view EVERYTHING that is transmitted – Permissible to use a trusted third party – All protocols, mechanisms, algorithms should be assumed known. The only secrets are the keys involved Separate Channel • Ideally you have separate secure channel for exchanging keys – Direct secret sharing grows at N2 Telephone, separate data network, ESP, sneaker net Regular data network 15 Shared Channel • Generally separate channel is not practical – No trustworthy separate channel – Want to scale linearly with additional users KA,KB, … KZ KB Key Exchange Regular data network KA 16 Classical Key Exchange • “Classical” means “no public key infrastructure” • Bootstrap problem: how do Alice, Bob begin? – Alice can’t send it to Bob in the clear! • Assume trusted third party, Cathy – Alice and Cathy share secret key kA – Bob and Cathy share secret key kB • Use this to exchange shared key ks 17 Simple Protocol { request for session key with Bob } kA Alice Cathy { ks } kA || { ks } kB Alice Cathy { ks } kB Alice Bob Notice : Cathy gives Alice the job of sending key to Bob { ks } kB Eve Bob Notice : Eve might break key, and entice Bob to use it with her or might simply replay the communication Alice had with Bob using that key 18 Problems • How does Bob know he is talking to Alice? – Replay attack: Eve records message from Alice to Bob, later replays it; Bob may think he’s talking to Alice, but he isn’t • e.g. message is “buy 100 shares of GE stock” – Session key reuse: Eve replays message from Alice to Bob, so Bob re-uses session key • If Eve has cracked session key off-line, she can say anything she likes in the communication • Protocols must provide authentication and defense against replay 19 Public Key Key Exchange • Here interchange keys known – eA, eB Alice and Bob’s public keys known to all – dA, dB Alice and Bob’s private keys known only to owners • Simple protocol – ks is desired session key { ks } eB Alice Bob 42 Problem and Solution • Vulnerable to forgery or replay – Because eB known to anyone, Bob has no assurance that Alice sent message • Simple fix uses Alice’s private key – ks is desired session key { { ks } dA } eB Alice Bob 43 Notes • Can include message enciphered with ks • Assumes Bob has Alice’s public key, and vice versa – If not, each must get it from public server – If keys not bound to identity of owner, attacker Eve can launch a man-in-the-middle attack (next slide; Cathy is public server providing public keys) • Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI) 44 Man-in-the-Middle Attack Alice Pls send Bob’s public key Eve intercepts request Cathy send Bob’s public key Eve Cathy eB Eve Cathy eE Alice Eve Alice believes that eE is Bob’s public key. It isn’t…. { k s } eE Eve intercepts message Alice Bob { ks } eB 45 Eve Bob Cryptographic Key Infrastructure • Goal: bind identity to key • Classical: not possible as all keys are shared – Use protocols to agree on a shared key (see earlier) • Public key: bind identity to public key – Crucial as people will use key to communicate with principal whose identity is bound to key – Erroneous binding means no secrecy between principals – Assume principal identified by an acceptable name 46 Certificates • Create token (message) containing – Identity of principal (here, Alice) – Corresponding public key – Timestamp (when issued) – Other information (perhaps identity of signer) – Compute hash (message digest) of token Hash encrypted by trusted authority (here, Cathy) using private key: called a “signature” CA = eA || Alice || T || {h(eA || Alice || T )} dC OBSERVE : public key, Alice and T are in the clear; hash is signed. Why? 47 Use • Bob gets Alice’s certificate – If he knows Cathy’s public key, he can validate the certificate • Decrypt encrypted hash using Cathy’s public key • Re-compute hash from certificate and compare • Check validity • Is the principal Alice? – Now Bob has Alice’s public key • Problem: Bob needs Cathy’s public key to validate certificate – That is, secure distribution of public keys – Solution: Public Key Infrastructure (PKI) using trust anchors called Certificate Authorities (CAs) that issue certificates 48 X.509 Certificates • Some certificate components in X.509v3: – Version – Serial number – Signature algorithm identifier: hash algorithm – Issuer’s name; uniquely identifies issuer – Interval of validity – Subject’s name; uniquely identifies subject – Subject’s public key – Signature: encrypted hash 49 Transitive Trust • If user U1 has a public-key certificate C issued by certificate authority CA1, then CA1 trusts that the identity on C is user U1’s – Some validation used before C is issued – U1 also trusts validity of other certs issued by CA1 • If CA1 has a certificate D issued by CA2, then CA2 trusts that the identity on D is CA1’s, and that CA1 does due diligence in checking identities on certs that CA1 issues… – CA1 trusts other certs that CA2 issues to certificate authorities and (possibly) users 50 Transitive Trust Illustrated cert issued Trusts CA3’s identity and trustworthiness of certs issued CA2 CA3 Trusts certs signed by CA2 Trusts CA1’s identity Trusts CA4’s identity and trustworthiness and trustworthiness Trusts certs Trusts certs of certs issued of certs issued signed by CA2 signed by CA3 CA1 CA4 Trusts Bob’s Trusts Alice’s identity identity Trusts certs Trusts certs signed by CA4 signed by CA1 Bob Alice Suppose Alice has every cert implied in this diagram she trusts the key on Bob’s cert--- Why? She trusts CA2, and CA2 trusts Bob PKI Trust Models • A Single Global CA • Hierarchical CAs (Tree) – Unmanageable, inflexible – There is no universally Root CA trusted organization Level I CA … Level I CA Level n CA User – Offloads burden on multiple CAs – Need to verify a chain of certificates – Still depends on a single trusted root CA 52 PKI Trust Models • Hierarchical CAs with cross-certification – Multiple root CAs that are cross-certified – Cross-certification at lower levels for efficiency • Web Model – Browsers come pre-configured with multiple trust anchor certificates – New certificates can be added • Distributed (e.g., PGP) – No CA; instead, users certify each other to build a “web of trust” 53 Validation and Cross-Certifying • Alice’s CA is Cathy; Bob’s CA is Dan; how can Alice validate Bob’s certificate? – Have Cathy and Dan cross-certify – Each issues certificate for the other • Certificates: – Cathy<<Alice>> (Cathy issues cert for Alice) – Dan<<Bob> (Dan issues cert for Bob) – Cathy<<Dan>> (Cathy issues cert for Dan) – Dan<<Cathy>> (Dan issues cert for Cathy) Cross-certification 54 Cross-Certification Cert binds dest ID to dest PK, signed by src CA Alice gets cert from Bob : Cathy is there a common CA ancestor CA CA in the directed CA graph? Alice CA CA Dan Cross-certification Bob –Alice gets Bob’s cert, signed by Dan –Sees Dan’s cert is signed by Cathy –Trusts Cathy as her own CA –Alice uses (known) public key of Cathy to validate Dan’s cert –Alice uses Dan’s public key (from cert) to validate Bob’s cert PGP Chains • OpenPGP certificates structured into packets – One public key packet – Zero or more signature packets – See http://www.ietf.org/rfc/rfc4880.txt • Public key packet: – Version (3 or 4; 3 compatible with all versions of PGP, 4 not compatible with older versions of PGP) – Creation time – Validity period (not present in version 3) – Public key algorithm, associated parameters – Public key 56 OpenPGP Signature Packet • Version 3 signature packet – Version (3) – Signature type (level of trust) – Creation time – Signer’s key identifier (identifies key to encrypt hash) – Public key algorithm (used to encrypt hash) – Hash algorithm – Part of signed hash (used for quick check) – Signature (encrypted hash) • Version 4 packet more complex 57 Signing • Single certificate may have multiple signatures • Notion of “trust” embedded in each signature – Range from “untrusted” to “ultimate trust” – Signer defines meaning of trust level (no standards!) • All version 4 keys signed by subject – Called “self-signing” 58 Validating Certificates • Alice needs to validate Arrows show signatures Bob’s OpenPGP cert Self signatures not shown – Does not know Fred, Giselle, or Ellen Jack • Alice gets Giselle’s cert – Knows Henry slightly, but Henry Ellen his signature is at “casual” level of trust Irene Giselle • Alice gets Ellen’s cert – Knows Jack, so uses his cert Fred to validate Ellen’s, then hers to validate Bob’s Bob 59 Key Revocation • Certificates invalidated before expiration – Usually due to compromised key – May be due to change in circumstance (e.g., someone leaving company) • Problems – Verify that entity revoking certificate authorized to do so – Revocation information circulates to everyone fast enough • Network delays, infrastructure problems may delay information 60 CRLs • Certificate revocation list lists certificates that are revoked • X.509: only certificate issuer can revoke certificate – Added to CRL • PGP: signers can revoke signatures; owners can revoke certificates, or allow others to do so – Revocation message placed in PGP packet and signed – Flag marks it as revocation message 61 Digital Signature • Construct that authenticated origin, contents of message in a manner provable to a disinterested third party (“judge”) • Sender cannot deny having sent message (service is “non-repudiation”) – Limited to technical proofs • Inability to deny one’s cryptographic key was used to sign – One could claim the cryptographic key was stolen or compromised • Legal proofs, etc., probably required; not dealt with here 62 Simple Approach • Classical: Alice, Bob share key k – Alice sends m || { m } k to Bob This is a digital signature WRONG This is not a digital signature – Why? Third party cannot determine whether Alice or Bob generated message 63 Public Key Digital Signatures • Alice’s keys are (private) dAlice, (public) eAlice • Alice sends Bob m || { m } dAlice • In case of dispute, judge computes { { m } dAlice } eAlice • and if it is m, Alice’s private key signed message – She’s the only one who knows dAlice, so we infer Alice did the signing action 64 RSA Digital Signatures • Use private key to encrypt message – Protocol for use is critical • Key points: – Never sign random documents, and when signing, always sign hash and never document • Mathematical properties can be turned against signer – Sign message first, then encrypt • Changing public keys causes forgery 65 Attack #1 Given Bob’s signatures on messages m1 and m2 Alice can compute his signature on message m m1 m2 so the attack is to create evil message m, find factors (with appropriate modulus) and get Bob to sign them • (m1 x m2 ) mod nb = m • Get Bob to sign m1 and m2 • m1d mod nb x m2d mod nb = (m1d x m2d ) mod nb = (m1 x m2 )d mod nb = md mod nb 66 Attack #1 example • Example: Alice, Bob communicating – nA = 95, eA = 59, dA = 11 – nB = 77, eB = 53, dB = 17 – note that ops using Alice’s key are mod nA,, using Bob’s are nB • 26 contracts, numbered 00 to 25 – Alice has Bob sign 05 and 17: • c = mdB mod nB = 0517 mod 77 = 3 • c = mdB mod nB = 1717 mod 77 = 19 – Alice computes 0517 mod 77 = 08; corresponding signature is (08)17 mod 77 = (0319) mod 77 = 57; – claims Bob signed 08 – Judge computes ceB mod nB = 5753 mod 77 = 08 • Signature validated; Bob is toast 67 Attack #2: Bob’s Revenge • Bob, Alice agree to sign contract m but Bob wants it to appear that she signed contract M – Alice encrypts with Bob’s public key (e.g. for confidentiality), then signs with her private key: c = (meB mod nB)dA mod nA • Bob now changes his public key – Computes r such that Mr mod nB = m – Replace public key with product reB and computes a new matching private key d'B • What exactly is the math problem to be solved? • Bob claims contract was M. Judge computes: – (ceA mod nA)d'B mod nB = M 68 Attack #2: Bob’s Revenge (cont’d) • Document is c = (meB mod nB)dA mod nA • Bob’s new key pair is (r eB, d’B) – M and r satisfy Mr mod nB = m • What happens if M is encoded using new public key? – (M r eB mod nB) = (M r )eB mod nB » = m mod nB • Bob claims contract was M. Judge computes: – (ceA mod nA)d'B mod nB = M – Verify Alice signed – Decode using new public key – Busted • Illustrates dangers of encrypt-then-sign – Recipient can pull a fast one on you 69 Attack #2 Example • Bob, Alice agree to sign contract 06 • Alice encrypts, then signs: (meB mod 77)dA mod nA = (0653 mod 77)11 mod 95 = 63 • Bob now changes his public key – Computes r such that 13r mod 77 = 6; say, r = 59 – Computes r eB mod (nB) = 5953 mod 60 = 7 – Replace public key eB with 7, private key dB = 43 • Bob claims contract was 13. Judge computes: – (6359 mod 95)43 mod 77 = 13 – Verified; now Alice is toast 70 Digital Signature Algorithm (DSA) Is a FIPS standard (186-3) proposed by NIST, 1991 See this link http://www.itl.nist.gov/fipspubs/fip186.htm Is a bit more technical than it is interesting That has never stopped us before…. Three phases – Key generation – Signing – Verification DSA Key Generation Algorithmic parameters – Hash function h – Key lengths (L, N) 186-3 specifies options (1024,160), (2048,224), (2048,256), and (3072,256). – Choose an N-bit prime q. – Choose an L-bit prime modulus p such that p–1 is a multiple of q. – Choose g, with multiplicative order modulo p equal to q. – (p, q, g) may be shared Key generation---public and private keys – Choose random x, with 0 < x < q. – Calculate y = (g x ) mod p. – Public key is (p, q, g, y). Private key is x. DSA Signature • Generate a random per-message value k where 0 < k < q • Calculate r = ((g k) mod p) mod q • Calculate s = (k’(H(m) + x*r)) mod q – where k’ is the multiplicative inverse mod q of k – Remember that x is private key • Recalculate the signature in the unlikely case that r = 0 or s = 0 • The signature is (r, s) DSA Verification Given legal signature (r, s) • Calculate w = (s’) mod q • s’ multiplicative inverse mod q • Calculate u1 = (h(m)*w) mod q – m is message whose signature we’re checking • Calculate u2 = (r*w) mod q • Calculate v = ((gu1 * yu2) mod p) mod q • The signature is valid if v = r Storing Keys • Multi-user or networked systems: attackers may defeat access control mechanisms – Encrypt file containing key • Attacker can monitor keystrokes to decrypt files • Key will be resident in memory that attacker may be able to read – Use physical devices like “smart card” • Key never enters system • Card can be stolen, so have 2 devices combine bits to make single key 75 Key Escrow • Key escrow system allows authorized third party to recover key – Useful when keys belong to roles, such as system operator, rather than individuals – Business: recovery of backup keys – Law enforcement: recovery of keys that authorized parties require access to • Goal: provide this without weakening cryptosystem • Very controversial 76 Desirable Properties • Escrow system should not depend on encryption algorithm • Privacy protection mechanisms must work from end to end and be part of user interface • Requirements must map to key exchange protocol • System supporting key escrow must require all parties to authenticate themselves • If message to be observable for limited time, key escrow system must ensure keys valid for that period of time only 77 Beth, Knobloch, Otten, Simmons, Wichmann 94 Components • User security component – Does the encryption, decryption – Supports the key escrow component • Key escrow component – Manages storage, use of data recovery keys • Data recovery component – Does key recovery 78 Example: ESS, Clipper Chip • Escrow Encryption Standard – FIPS 185 (http://www.itl.nist.gov/fipspubs/fip185.htm) – Set of interlocking components – Designed to balance need for law enforcement access to enciphered traffic with citizens’ right to privacy • Clipper chip given to user with prepared per- message escrow information – Each chip numbered uniquely by UID – Special facility programs each chip • Key Escrow Decrypt Processor (KEDP) – Available to agencies authorized to read messages 79 User Security Component • Unique device key kunique • Non-unique family key kfamily • Cipher is Skipjack – Classical cipher: 80 bit key (ksession ), 64 bit input, output blocks • Attaches Law Enforcement Access Field (LEAF) of 128 bits: – { UID || { ksession } kunique || hash } kfamily – hash: 16 bit authenticator from session key and initialization vector 80 User Security Component message Programmed at initialization UID kunique 64 bits 80 bit session key skipjack ksession Based on session key and Initialization vector 64 bits k family Law Enforcement {UID|| ksession }kunique || hash}k family Access Field (32) (80) (16) Field sizes (in bits) ciphertext Initialization of User Security Component Seed1, Key1, Fam1 Secure Facility Escrow Agent I {ku1}kcomp •Creates ku1,ku2 •Combine Fam1, Fam2 to obtain kfamily UID, kunique, •Combine Key1,Key2 kfamily User to obtain kcomp “Clipper” Seed2, Key2, Fam2 •Combine Seed1, Seed2 Chip Escrow {ku2}kcomp to generate sequence Agent II kunique = ku1 ku2 Essential points • Key that encrypts session key requires both ku1 and ku2 • k family depends on input from both Escrow agents • Returned encoding of ku1,ku2 uses key derived from both Escrow agents 82 Obtaining Access • Alice obtains legal authorization to read message • She runs message LEAF through KEDP – LEAF is { UID || { ksession } kunique || hash } kfamily • KEDP uses (known) kfamily to validate LEAF (think hash(UID)), obtain sending device’s UID • Authorization, LEAF taken to escrow agencies – To get session key she needs to get kunique 83 Agencies’ Role • Each validates authorization offered by Alice • Each supplies { kui } kcomp and key number Keyi • KEDP takes these and LEAF: { UID || { ksession } kunique || hash } kfamily – Key numbers produce kcomp – kcomp produces ku1 and ku2 – ku1 and ku2 produce kunique – kunique and LEAF produce ksession 84 Problems • Clipper would not decode messages with an invalid hash – So naturally the attack is to replace the real LEAF with one that has a valid hash! • hash too short – LEAF 128 bits, 16-bit “checksum” (hash) – 2112 LEAFs have a valid hash, e.g., would validate • 1 has actual session key, UID • Takes about 42 minutes to find a randomly generated LEAF with a valid hash but meaningless session key and UID – Turns out deployed devices would prevent this attack – Scheme does not meet temporal requirement • As kunique fixed for each unit, once message is read, any future messages can be read 85 Yaksha Key Escrow Main ideas: – Session keys obtained from a Yaksha server • Server escrows generated keys – Only messages encoded with the session key are recoverable Key Points • Key management critical to effective use of cryptosystems – Different levels of keys (session vs. interchange) • Exchange algorithms can be vulnerable to attacks – Replay – Identity integrity • Digital signatures provide integrity of origin and content Much easier with public key cryptosystems than with classical cryptosystems • Keys need infrastructure to identify holders, allow revoking and possible escrow 88

DOCUMENT INFO

Shared By:

Categories:

Tags:
Introduction, Ticket

Stats:

views: | 10 |

posted: | 12/19/2010 |

language: | English |

pages: | 65 |

Description:
Introduction Ticket

OTHER DOCS BY MikeJenny

Docstoc is the premier online destination to start and grow small businesses. It hosts the best quality and widest selection of professional documents (over 20 million) and resources including expert videos, articles and productivity tools to make every small business better.

Search or Browse for any specific document or resource you need for your business. Or explore our curated resources for Starting a Business, Growing a Business or for Professional Development.

Feel free to Contact Us with any questions you might have.