Key Escrow Key escrow system allows authorized

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 May 18, 2004 ECS 235 1

Desirable Properties • Escrow system should not depend on encipherment 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 May 18, 2004 ECS 235 2

Components • User security component – Does the encipherment, decipherment – Supports the key escrow component • Key escrow component – Manages storage, use of data recovery keys • Data recovery component – Does key recovery May 18, 2004 ECS 235 3

Example: EES, Clipper Chip • Escrow Encryption Standard – Set of interlocking components – Designed to balance need for law enforcement access to enciphered traffic with citizens’ right to privacy • Clipper chip prepares per-message escrow information – Each chip numbered uniquely by UID – Special facility programs chip • Key Escrow Decrypt Processor (KEDP) – Available to agencies authorized to read messages May 18, 2004 ECS 235 4

User Security Component • Unique device key kunique • Nonunique family key kfamily • Cipher is Skipjack – Classical cipher: 80 bit key, 64 bit input, output blocks • Generates Law Enforcement Access Field (LEAF) of 128 bits: – { UID || { ksession } kunique || hash } kfamily – hash: 16 bit authenticator from session key and initialization vector May 18, 2004 ECS 235 5

Programming User Components • Done in a secure facility • Two escrow agencies needed – – Agents from each present Each supplies a random seed and key number Family key components combined to get kfamily Key numbers combined to make key component enciphering key kcomp – Random seeds mixed with other data to produce sequence of unique keys kunique • Each chip imprinted with UID, kunique, kfamily May 18, 2004 ECS 235 6

The Escrow Components • During initialization of user security component, process creates ku 1 and ku 2 where kunique = ku 1 ku 2 – First escrow agency gets { ku 1 } kcomp – Second escrow agency gets { ku 2 } kcomp May 18, 2004 ECS 235 7

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, obtain sending device’s UID • Authorization, LEAF taken to escrow agencies May 18, 2004 ECS 235 8

Agencies’ Role • Each validates authorization • Each supplies { kui } kcomp, corresponding key number • KEDP takes these and LEAF: – Key numbers produce kcomp – kcomp produces ku 1 and ku 2 – ku 1 and ku 2 produce kunique – kunique and LEAF produce ksession May 18, 2004 ECS 235 9

Problems • hash too short – LEAF 128 bits, so given a hash: • 2112 LEAFs show this as a valid hash • 1 has actual session key, UID • Takes about 42 minutes to generate a LEAF with a valid hash but meaningless session key and UID; in fact, 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 May 18, 2004 ECS 235 10

Yaksha Security System • Key escrow system meeting all 5 criteria • Based on RSA, central server – Central server (Yaksha server) generates session key • Each user has 2 private keys – – Alice’s modulus n. A, public key e. A First private key d. AA known only to Alice Second private key d. AY known only to Yaksha central server d. AA d. AY = d. A mod n. A May 18, 2004 ECS 235 11

Alice and Bob • Alice wants to send message to Bob – Alice asks Yaksha server for session key – Yaksha server generates ksession – Yaksha server sends Alice the key as: CA = (ksession)d. AYe. A mod n. A – Alice computes (CA)d. AA mod n. A = ksession May 18, 2004 ECS 235 12

Analysis • Authority can read only one message per escrowed key – Meets requirement 5 (temporal one), because “time” interpreted as “session” • Independent of message enciphering key – Meets requirement 1 – Interchange algorithm, keys fixed • Others met by supporting infrastructure May 18, 2004 ECS 235 13

Alternate Approaches • Tie to time – Session key not given as escrow key, but related key is – To derive session key, must solve instance of discrete log problem • Tie to probability – Oblivious transfer: message received with specified probability – Idea: translucent cryptography allows fraction f of messages to be read by third party – Not key escrow, but similar in spirit May 18, 2004 ECS 235 14

Key Revocation • Certificates invalidated before expiration – Usually due to compromised key – May be due to change in circumstance (e. g. , someone leaving company) • Problems – Entity revoking certificate authorized to do so – Revocation information circulates to everyone fast enough • Network delays, infrastructure problems may delay information May 18, 2004 ECS 235 15

CRLs • Certificate revocation 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 May 18, 2004 ECS 235 16

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 “nonrepudiation”) – 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 May 18, 2004 ECS 235 17

Common Error • 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 May 18, 2004 ECS 235 18

Classical Digital Signatures • Require trusted third party – Alice, Bob each share keys with trusted party Cathy • To resolve dispute, judge gets { m }k. Alice, { m }k. Bob, and has Cathy decipher them; if messages matched, contract was signed Alice { m }k. Alice Bob { m }k. Alice Cathy { m }k. Bob May 18, 2004 ECS 235 19

Public Key Digital Signatures • Alice’s keys are d. Alice, e. Alice • Alice sends Bob m || { m }d. Alice • In case of dispute, judge computes { { m }d. Alice }e. Alice • and if it is m, Alice signed message – She’s the only one who knows d. Alice! May 18, 2004 ECS 235 20

RSA Digital Signatures • Use private key to encipher 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 encipher • Changing public keys causes forgery May 18, 2004 ECS 235 21

Attack #1 • Example: Alice, Bob communicating – n. A = 95, e. A = 59, d. A = 11 – n. B = 77, e. B = 53, d. B = 17 • 26 contracts, numbered 00 to 25 – Alice has Bob sign 05 and 17: • c = md. B mod n. B = 0517 mod 77 = 3 • c = md. B mod n. B = 1717 mod 77 = 19 – Alice computes 05 17 mod 77 = 08; corresponding signature is 03 19 mod 77 = 57; claims Bob signed 08 – Judge computes ce. B mod n. B = 5753 mod 77 = 08 • Signature validated; Bob is toast May 18, 2004 ECS 235 22

Attack #2: Bob’s Revenge • Bob, Alice agree to sign contract 06 • Alice enciphers, then signs: (me. B mod 77)d. A mod n. A = (0653 mod 77)11 mod 95 = 63 • Bob now changes his public key so he can make it appear that Alice signed contract 13: – Computes r such that 13 r mod 77 = 06; say, r = 59 – Computes re. B mod (n. B) = 59 53 mod 60 = 7 – Replace public key e. B with 7; corresponding private key d. B = 43 • Bob claims contract was 13. Judge computes: – (6359 mod 95)43 mod 77 = 13 – Verified; now Alice is toast May 18, 2004 ECS 235 23

El Gamal Digital Signature • • Relies on discrete log problem Choose p prime, g, d < p; compute y = gd mod p Public key: (y, g, p); private key: d To sign contract m: – – Choose k relatively prime to p– 1, and not yet used Compute a = gk mod p Find b such that m = (da + kb) mod p– 1 Signature is (a, b) • To validate, check that – yaab mod p = gm mod p May 18, 2004 ECS 235 24

Example • Alice chooses p = 29, g = 3, d = 6 y = 36 mod 29 = 4 • Alice wants to send Bob signed contract 23 – – Chooses k = 5 (relatively prime to 28) This gives a = gk mod p = 35 mod 29 = 11 Then solving 23 = (6 11 + 5 b) mod 28 gives b = 25 Alice sends message 23 and signature (11, 25) • Bob verifies signature: gm mod p = 323 mod 29 = 8 and yaab mod p = 4111125 mod 29 = 8 – They match, so Alice signed May 18, 2004 ECS 235 25

Attack • Eve learns k, corresponding message m, and signature (a, b) – Extended Euclidean Algorithm gives d, the private key • Example from above: Eve learned Alice signed last message with k = 5 m = (da + kb) mod p– 1 = (11 d + 5 25) mod 28 so Alice’s private key is d = 6 May 18, 2004 ECS 235 26

Key Points • Key management critical to effective use of cryptosystems – Different levels of keys (session vs. interchange) • Keys need infrastructure to identify holders, allow revoking – Key escrowing complicates infrastructure • Digital signatures provide integrity of origin and content Much easier with public key cryptosystems than with classical cryptosystems May 18, 2004 ECS 235 27

Overview • Basics • Passwords – Storage – Selection – Breaking them • Other methods • Multiple methods May 18, 2004 ECS 235 28

Basics • Authentication: binding of identity to subject – Identity is that of external entity (my identity, Matt, etc. ) – Subject is computer entity (process, etc. ) May 18, 2004 ECS 235 29

Establishing Identity • One or more of the following – What entity knows (eg. password) – What entity has (eg. badge, smart card) – What entity is (eg. fingerprints, retinal characteristics) – Where entity is (eg. In front of a particular terminal) May 18, 2004 ECS 235 30

Authentication System • (A, C, F, L, S) – A information that proves identity – C information stored on computer and used to validate authentication information – F complementation function; f : A C – L functions that prove identity – S functions enabling entity to create, alter information in A or C May 18, 2004 ECS 235 31

Example • Password system, with passwords stored on line in clear text – A set of strings making up passwords –C=A – F singleton set of identity function { I } – L single equality test function { eq } – S function to set/change password May 18, 2004 ECS 235 32

Passwords • Sequence of characters – Examples: 10 digits, a string of letters, etc. – Generated randomly, by user, by computer with user input • Sequence of words – Examples: pass-phrases • Algorithms – Examples: challenge-response, one-time passwords May 18, 2004 ECS 235 33

Storage • Store as cleartext – If password file compromised, all passwords revealed • Encipher file – Need to have decipherment, encipherment keys in memory – Reduces to previous problem • Store one-way hash of password – If file read, attacker must still guess passwords or invert the hash May 18, 2004 ECS 235 34

Example • UNIX system standard hash function – Hashes password into 11 char string using one of 4096 hash functions • As authentication system: – – – A = { strings of 8 chars or less } C = { 2 char hash id || 11 char hash } F = { 4096 versions of modified DES } L = { login, su, … } S = { passwd, nispasswd, passwd+, … } May 18, 2004 ECS 235 35

Anatomy of Attacking • Goal: find a A such that: – For some f F, f(a) = c C – c is associated with entity • Two ways to determine whether a meets these requirements: – Direct approach: as above – Indirect approach: as l(a) succeeds iff f(a) = c C for some c associated with an entity, compute l(a) May 18, 2004 ECS 235 36

Preventing Attacks • How to prevent this: – Hide one of a, f, or c • Prevents obvious attack from above • Example: UNIX/Linux shadow password files – Hides c’s – Block access to all l L or result of l(a) • Prevents attacker from knowing if guess succeeded • Example: preventing any logins to an account from a network – Prevents knowing results of l (or accessing l) May 18, 2004 ECS 235 37

Dictionary Attacks • Trial-and-error from a list of potential passwords – Off-line: know f and c’s, and repeatedly try different guesses g A until the list is done or passwords guessed • Examples: crack, john-the-ripper – On-line: have access to functions in L and try guesses g until some l(g) succeeds • Examples: trying to log in by guessing a password May 18, 2004 ECS 235 38

Using Time Anderson’s formula: • P probability of guessing a password in specified period of time • G number of guesses tested in 1 time unit • T number of time units • N number of possible passwords (|A|) • Then P ≥ TG/N May 18, 2004 ECS 235 39

Example • Goal – – Passwords drawn from a 96 -char alphabet Can test 104 guesses per second Probability of a success to be 0. 5 over a 365 day period What is minimum password length? • Solution – N ≥ TG/P = (365 24 60 60) 104/0. 5 = 6. 31 1011 – Choose s such that sj=0 96 j ≥ N – So s ≥ 6, meaning passwords must be at least 6 chars long May 18, 2004 ECS 235 40

Approaches: Password Selection • Random selection – All elements of A equally likely to be selected – ICBS: maximizes time to guessing password • Be careful—it may not be really “random” • Remembering these is hard – Write down transformed password, apply transformation to recover • Example: “Capitalize 3 rd letter, append digit 2”; written down is “Swqgle 3” so password is “Sw. Qgle 32” May 18, 2004 ECS 235 41

Pronounceable Passwords • Generate phonemes randomly – Phoneme is unit of sound, eg. cv, vc, cvc, vcv – Examples: helgoret, juttelon are; przbqxdfl, zxrptglfn are not • Problem: too few • Solution: key crunching – Run long key through hash function and convert to printable sequence – Use this sequence as password May 18, 2004 ECS 235 42

User Selection • Problem: people pick easy to guess passwords – Based on account names, user names, computer names, place names – Dictionary words (also reversed, odd capitalizations, control characters, “elite-speak”, conjugations or declensions, swear words, Torah/Bible/Koran/… words) – Too short, digits only, letters only – License plates, acronyms, social security numbers – Personal characteristics or foibles (pet names, nicknames, job characteristics, etc. May 18, 2004 ECS 235 43

Picking Good Passwords • “Ll. Mm*2^Ap” – Names of members of 2 families • “Oo. He. O/FSK” – Second letter of each word of length 4 or more in third line of third verse of Star-Spangled Banner, followed by “/”, followed by author’s initials • What’s good here may be bad there – “DMC/MHmh” bad at Dartmouth (“Dartmouth Medical Center/Mary Hitchcock memorial hospital”), ok here • Why are these now bad passwords? May 18, 2004 ECS 235 44

Proactive Password Checking • Analyze proposed password for “goodness” – Always invoked – Can detect, reject bad passwords for an appropriate definition of “bad” – Discriminate on per-user, per-site basis – Needs to do pattern matching on words – Needs to execute subprograms and use results • Spell checker, for example – Easy to set up and integrate into password selection system May 18, 2004 ECS 235 45