Goals • Lay out some basic crypto concepts – Yes, there will be occasional formulas and details • Analyze their roles in some common protocols and applications – Roughly, the crypto architecture of the ‘Net • Become educated lay users of crypto implemented by trained professionals ™ – No, you shouldn’t try this at home : -) 1/9/03 Crypto for IT Staff Mad-Sage 1
Non Goals • No proofs • Hardly any history • Skipping or simplifying many implementation details • Not a tutorial on the protocols & apps – Tonight’s focus is on the crypto • We won’t become either cryptographers (designers) or cryptanalysts (breakers) 1/9/03 Crypto for IT Staff Mad-Sage 2
Outline • Warmup • Two cipher examples, tonight’s notations • 8 Cryptographic primitives • Block ciphers, public key algorithms, … • Decomposing applications and protocols • PGP, Certificates, TLS (SSL), SSH, IPSEC, … • Guidance • key lengths, snake oil, trust models, do’s and don’ts, … 1/9/03 Crypto for IT Staff Mad-Sage 3
Warm up Introduction and Notation 1/9/03 Crypto for IT Staff Mad-Sage 4
An (old) Cipher example M: I came, I saw, I conquered. C: L fdph, L vdz, L frqtxhuhg. • Start with a plaintext message (M), encrypt (via a monoalphabetic circular shift), obtaining obfuscated ciphertext (C). • Decrypt the ciphertext C back to plaintext M via the opposite shift • Very easily broken, via letter frequency statistics plus the word boundaries. 1/9/03 Crypto for IT Staff Mad-Sage 5
A better (Renaissance) Cipher M: blaise is much harder K: HOLSTE IN BLAI SEISMU C: izlali qf nfcp zezvql • Depends on a secret key (holstein) • Incorporates feedback (autokey) • Ciphers the same letter differently • E. g. ‘h’ becomes p, z; ‘z’ comes from l, h, r • “a” is weak – it leaks plain and key text 1/9/03 Crypto for IT Staff Mad-Sage 6
Notation – persons A is for Alice (sender, client) B is for Bob (receiver, server) V is for Victor (an eavesdropper / spy / bad guy / black hat) T is for Theresa (a trusted third party) 1/9/03 Crypto for IT Staff Mad-Sage 7
Notation - crypto M = plaintext message (file, packet, …) C = encrypted ciphertext of M k, k 1, k 2, k 3 = secret symmetric keys K{As} = Alice’s private (secret) key, K{Bp} = Bob’s public key E(k, M) = encrypt plaintext M via key k Using whatever algorithm we’re working with D(k, C) = decrypt ciphertext C via key k 1/9/03 Crypto for IT Staff Mad-Sage 8
Notation - math p, q = large prime numbers xor = exclusive or 1 xor 1 = 0 mod = modular arithmetic 5 mod 3 = 2 ^ = exponentiation 2^(2^4) + 1 = 65537 || = string concatenation “a”||”b” = “ab” <> = vectors or lists <1, 2, ’sha 1’> [ ] = text slice/block, { } = annotation 1/9/03 Crypto for IT Staff Mad-Sage 9
8 cryptographic primitives (building blocks) Part One 1/9/03 Crypto for IT Staff Mad-Sage 10
1: symmetric secret key block ciphers Symmetric A enciphers and B deciphers with the same key Secret Key The security depends only on how well A and B protect their shared key. Block works on chunks of message, usually 64 or 128 bits Cipher output size of gobbledegook ~ input size of message 1/9/03 Crypto for IT Staff Mad-Sage 11
Block cipher design goals • Avalanche – 1 bit change in input flips 50% of output bits • Non-correlation – No input bit correlates with any output bit. No pair of input bits … No triple of input bits … • Full dependency – Each output bit depends on all input bits • Key dependent, with hardly any weak keys • No attacks easier than guessing for the key – 2^(N-1) tries are needed to break a single N-bit key 1/9/03 Crypto for IT Staff Mad-Sage 12
How to make a block cipher • use multiple rounds of interleaved confusion (via substitution) and diffusion (via permutation) – Claude Shannon, c. 1945 • cryptographically strong • easy in either hardware or software – 1 byte table lookups do substitution – circular shifts with and/or/xor do permutation 1/9/03 Crypto for IT Staff Mad-Sage 13
Commonly used block ciphers • RC 2, 3 DES, IDEA, CAST, AES, … – What our data are actually protected by • Pro: – Fast, Strong • Con: – Alice and Bob will need an out-of-band method for sharing a secret key 1/9/03 Crypto for IT Staff Mad-Sage 14
DES – Data Encryption Standard • 64 bit blocks, 56 bit key, 16 S-P rounds – Details are complex; see FIPS 46 -2 – The first good civilian block cipher to be widely used. • Proposed by IBM in 1972, modified by NSA, adopted by NIST in 1976. – Initially controversial. The NSA changed the S-boxes and reduced the key size. Civilian verdict after 30 years of cryptanalysis: actually, they improved it. • Brute forced (publicly): 1997. – NIST had finally put out an RFP seeking AES … • Unsafe: Moore’s Law has killed 56 bit keys! 1/9/03 Crypto for IT Staff Mad-Sage 15
Safe variants of DES 1. DESX: E(k 1, M xor k 2) xor k 3 – – – k 2 and k 3 provide pre- and post- whitening, like unix password salt. net strength ~ 2^120; as fast as DES Extensively used by Microsoft in Win 2 K 2. 3 DES: E(k 3, D(k 2, E(k 1, M))) – – – 1/9/03 If k 1=k 2=k 3, degenerates to DES Often used with just two keys: k 3=k 1 net strength ~ 2^112; sluggish but oddly popular Crypto for IT Staff Mad-Sage 16
Some 3 DES cryptanalysis points • Due to a meet in the middle attack, 3 DES only offers 2^112 resistance to an attacker with 2^56 dictionary temp space – Unknown if 3 keys is actually stronger than 2 • Due to the same attack, 2 DES wouldn’t be enough stronger than 1 DES • E-D-E resists the class of differential attacks better than E-E-E 1/9/03 Crypto for IT Staff Mad-Sage 17
3 more good block ciphers • IDEA: International Data Encryption Algorithm – 64 bit blocks, 128 bit key, 8 Rounds – But: patented until 2008, and the Swiss want royalties • CAST-128 – 64 bit blocks, 128 bit key, 16 rounds – RFC-2144; a good choice for interoperability • AES Advanced Encryption Standard (FIPS 197) – Belgian Rijndael cipher won the design competition – Block size is 128 bit, has 3 key size/round variations 128 bit / 10 rounds , 192 / 12, 256 / 14 1/9/03 Crypto for IT Staff Mad-Sage 18
2: block cipher usage modes • What if our message isn’t 64 bits? – Too short: pad, ideally with random bits – Too long: chop into multiple blocks • Do we want inter-block feedback? • Do we care about error propagation? – Military radios: yes. Computers: no. • 4 -7 modes in common use – AES has 23 proposed modes … so far (See NIST SP 800 -38 a) 1/9/03 Crypto for IT Staff Mad-Sage 19
Mode ECB: Electronic Code Book • Encrypt each block independently – Simplest mode, adds no space overhead • Not good for long messages – Victor knows that identical ciphertext came from identical plaintext, which reveals message structure – Victor can conduct known text attacks to build a code book – If Victor is a man in the middle, he can fiddle whole blocks undetected 1/9/03 Crypto for IT Staff Mad-Sage 20
man in the middle attacks • Instead of Alice <-> Bob, we might have Alice <-> Victor <-> Bob • Some things Victor can do: – tell different lies to Alice than to Bob – pass their traffic, but record it – inject packets, or delete packets – change packet contents – replay packet streams • Lots of effort goes into preventing this! 1/9/03 Crypto for IT Staff Mad-Sage 21
Mode CBC: Cipher Block Chaining • Start, block 0: xor a random initialization vector – Block worth of salt / whitening bits (64 bits for DES) – Unlike key, IV is not secret C[0] = E(k, M[0] xor IV) M[0] = D(k, C[0]) xor IV • Middle, blocks j: xor prior ciphertext C[j] = E(k, M[j] xor C[j-1]) M[j] = D(k, C[k]) xor C[j-1] • Option: end with a ciphertext stealing gimmick? – Details omitted. Off-line users have a cute ploy with the last two blocks which avoids trailing padding bits. 1/9/03 Crypto for IT Staff Mad-Sage 22
3: Diffie – Hellman key exchange • An on-line protocol for Alice and Bob to generate a shared secret S – Widely used, e. g. in SSH, TLS, IPSEC • Depends on the difficulty of the discrete logarithm problem Computing z = g^w mod p is easy z = 2^4 mod 11 … z = 5 Inverse, finding w given z, g, p is hard 3 = 2^ w mod 11 … w = ? 1/9/03 Crypto for IT Staff Mad-Sage 23
Diffie-Hellman details 1. start: large prime p, generator g, 1 < g < p. These can be public, and can be reused. 2. Alice: pick x, send A = g^x mod p picks a random x, computes A, sends <A, p, g> to Bob. X is secret, Message <A, p, g> is unencrypted. 3. Bob: pick y, send B = g^y mod p picks a random y, computes B , sends B to Alice. Y is also secret, B is again unencrypted. 4. Both: compute S = g ^ (x*y) mod p Alice: S=B^x mod p. Bob: S=A^y mod p. • Victor, eavesdropping on p, g, A, B, can’t find S 1/9/03 Crypto for IT Staff Mad-Sage 24
4: Public Key: proposed Diffie & Hellman also analyzed the possibilities of asymmetric cryptosystems • Alice would use one key to encrypt, Bob would use a different key to decrypt. • allows key exchange and digital signature protocols • Needs a one way trapdoor function – Hard to invert, except when you possess an extra secret 1/9/03 Crypto for IT Staff Mad-Sage 25
Public Key: realized • A flurry of candidates for one way trapdoor functions were proposed. Three survived: – Factoring, discrete logarithms, elliptic curves • It’s all number theory: modular exponentiation in finite fields and groups • But: they are all slow and weak – 1000 x slower than block ciphers, or worse – Solutions much faster than key guessing exist – significantly vulnerable to known text attacks 1/9/03 Crypto for IT Staff Mad-Sage 26
Public key: RSA (factoring) • Choose p, q large random primes. Let N=p*q – p and q are 350 -2000 bits (10^155 -10^600) • Choose e relatively prime to (p-1)*(q-1) – E can be reused; 65537 is popular. • Compute d = 1/e mod (p-1)*(q-1) • Private key is <d>. Public key is <N, e> – Alice discards p, q, or keeps them secret with d • Encrypt: C = M^e mod N • Decrypt: M = C^d mod N 1/9/03 Crypto for IT Staff Mad-Sage 27
Pubkey: El. Gamal (discrete log) • choose large random prime p, and random g, x less than p. Let y = g^x mod p. • private key is x; public key is <y, g, p> • encrypt: – choose new, previously unused random k, relatively prime to p-1. – let a = g^k mod p, b = ((y^k) * M) mod p. – Ciphertext: C = <a, b> • decrypt: M = b/(a^x) mod p 1/9/03 Crypto for IT Staff Mad-Sage 28
Pubkey: Elliptic curves • Elliptic curve cryptography is based on the integer solutions to equations of the form: Y^2 = X^3 +a*X + b (coefficients a and b are from a finite field) • The trapdoor problem is scalar multiplication, g = s * f, for curves f, g • Not yet widely used; details omitted. • Appeal is shorter key sizes 1/9/03 Crypto for IT Staff Mad-Sage 29
5: cryptographic hash functions • Also known as message digest algorithms – E. g. MD 5, SHA-1, Haval, RIPEM-160, … • Design goals: – fast, fixed size output, one-way (exponential work to invert), strongly collision free, avalanche property, … – NB: CRC 32 flunks all the crypto properties • Used for: identifying blob contents – messages, files, packets, PGP keys, … 1/9/03 Crypto for IT Staff Mad-Sage 30
Two popular hashes • MD 5: 128 bits (RFC 1321) – Derived from the RC 4 stream cipher. – Don’t use it in new apps • SHA 1: 160 bits (FIPS 180 -1) – An NSA tweak of SHA, a stronger cousin of MD 5 – Currently a good choice • hash size should be 2 x block cipher key size. – due to a birthday attack, some breaks of an N-bit hash function average only 2^(N/2) operations – Yes, NIST will have longer ones to accompany AES. 1/9/03 Crypto for IT Staff Mad-Sage 31
6: HMAC • Keyed hash based message authentication code (RFC 2104) – detects various man-in-the-middle attacks – Uses a shared secret key k, a hash algorithm H (twice), and special constants ipad, opad. • HMAC(k, H, M) = H((k xor opad) || H((k xor ipad) || M)) • Example from a TLS 1. 0 packet: – HMAC(write_key, sha 1, record_seq_no || C) • An alternative: last block from CBC-mode cipher 1/9/03 Crypto for IT Staff Mad-Sage 32
7: Digital Signature Algorithms • Goal: validate Alice’s message to Bob – Authenticate sender – Prevent tampering – May provide non-repudiation • Tactic: encipher a message hash H via a public key algorithm. H=SHA 1 is popular. • RSA example: (PGP, rfc 2437, PKCS#1, X 9. 31) – Alice: send SIG = E(K{As}, H(M)) – Bob: compare H(M) =? D(K{Ap}, SIG) 1/9/03 Crypto for IT Staff Mad-Sage 33
NIST DSA, slide 1 of 3: signing • Alice: create secret key x, public key <p, q, g, y> – – p 512 -1024 bit prime, q 160 bit prime factor of p-1 Choose a random large x for secret key, with x < q g = f^((p-1)/q) mod p, with f < p-1 such that g > 1 y = g^x mod p • Using SHA-1 as H(), compute signature <r, s> – choose random k < q – Let r = (g^k mod p) mod q, s = ((H(M) + x*r)/k) mod q 1/9/03 Crypto for IT Staff Mad-Sage 34
NIST DSA, 2 of 3: verifying Bob: obtain public DSA key of Alice: <p, q, g, y> Receive message M with signature <r, s> Compute: w = 1/s mod q u 1 = (H(M) * w) mod q, u 2 = (r*w) mod q v = ((g^u 1 * y^u 2) mod p) mod q If v=r, then Alice’s signature of M is valid 1/9/03 Crypto for IT Staff Mad-Sage 35
NIST DSA, 3 of 3: comments • DSA annoyances – 1024 bit p / 160 bit q will soon be too small – Bob is doing more work than Alice • See FIPS 186 -2 “Digital Signature Standard” (DSS) for 3 choices: – DSA (discrete logs) – X 9. 31 (an RSA variant) – Elliptic curves 1/9/03 Crypto for IT Staff (FIPS 186) (FIPS 186 -1) (FIPS 186 -2) Mad-Sage 36
8: cryptographic pseudorandom number generating functions • A good CPRNG is very important. – You did notice how many “random” p, q, k, x, y, IV values we’ve been picking, right? – CPRNG problems are often the weakest link • Design goals: – can't invert, can't deduce seed, can't predict runs, no bit correlations, no weak seeds, … • Seed it with real entropy – Disk spindle speed wobbles, thermal noise 1/9/03 Crypto for IT Staff Mad-Sage 37
Summary: crypto primitives • 5 basic primitives – – – Symmetric secret key block ciphers (3 DES, AES, …) Diffie-Hellman key exchange Public key encryption (RSA, El. Gamal, Elliptic) Hash functions (MD 5, SHA 1, …) Crypto psuedo random number generators • 3 more things we built from those: – Block cipher usage modes: ECB, CBC, … – HMAC (from hash + key + usage) – Digital signatures (from hash + public key) 1/9/03 Crypto for IT Staff Mad-Sage 38
Decomposing Applications and Protocols Part two 1/9/03 Crypto for IT Staff Mad-Sage 39
Signed, encrypted e-mail: PGP Alice sending e-mail M to Bob, with Bcc to self 1. Choose a signing algorithm (RSA), private/public key pair <K{As}, K{Ap}>, a block cipher (IDEA), a hash algorithm (SHA 1), and a compression algorithm (ZLIB) 2. Seed CPRNG with entropy, set up block cipher. Generate: • • 1/9/03 a random 128 bit session key k a random 64 bit initialization vector IV Crypto for IT Staff Mad-Sage 40
PGP e-mail: Alice to Bob (2 of 7) 3. Compute signature: hash message, encrypt (RSA) with Alice’s private key: SIG = E(K{As}, SHA 1(M)) 3. Compress and encrypt M (idea/cbc mode) C = E(k, IV, zlib(M)) 5. Encrypt the session key with each recipients (Bob, Alice), RSA public key: E(K{Bp}, k) E(K{Ap}, k) 1/9/03 Crypto for IT Staff Mad-Sage 41
PGP e-mail: Alice to Bob (3 of 7) 6. Assemble a multipart nested message: < <E(K{Bp}, k), E(K{Ap}, k)>, <‘idea’, IV, ‘zlib’, C>, <‘sha 1’, SIG > > 7. ascii-encode the result, e-mail and archive it. 1/9/03 Crypto for IT Staff Mad-Sage 42
PGP e-mail 4: Bob receiving 1. Bob locates his copy of the session key, decrypts it with his private RSA key: k = D{rsa}(K{Bs}, . . . ) 2. Bob decrypts ciphertext, decompresses it M = Expand( D{idea-cbc}(k, IV, C) ) 3. Bob checks the signature, using the hash algorithm and Alice’s public key K{Ap}: SHA 1(M) =? D{rsa}(K{Ap}, SIG) 1/9/03 Crypto for IT Staff Mad-Sage 43
PGP mail 5: primitive roles • Block cipher in CBC mode – Strong and fast: protects the message • CPRNG – session key, initialization vector, padding, … • Hash functions – Identification of message and key packets • Public key algorithms – distribute session key, sign message hash 1/9/03 Crypto for IT Staff Mad-Sage 44
PGP mail 6: crypto remarks • Compressing plaintext improves strength • 100% of standards are naïve about signing – Signing cryptotext invites repudiation issues and is subject to Anderson’s attack. Don’t do it. – Signing plaintext really needs an IV for strength and a signed recipient name to detect forwarding • Public keys are slow, weak, and long-lived – Used only on small, random things: session keys and hashes 1/9/03 Crypto for IT Staff Mad-Sage 45
PGP: v 4 keys • Our example used v 3 RSA Legacy keys – A single RSA key pair is used for both encryption and signing – Symmetric cipher is always IDEA • Newfangled version 4 keys are better: – separate encryption and signing key pairs • Rubber hose decryption attack: court order – Can use RSA/RSA or Elgamal/DSA (called DH/DSS) – Can use other block ciphers: CAST, 3 DES, AES, … 1/9/03 Crypto for IT Staff Mad-Sage 46
Interlude: Microsoft EFS • Tweak our PGP example: – put Alice’s keys in a certificate – make Bob the file system recovery agent – let message M be a disk file • We'd be very near to Microsoft’s Encrypting File System – Win 2 K and XP use DESX as the cipher – Recent service packs added AES 1/9/03 Crypto for IT Staff Mad-Sage 47
Passphrase protection (1 of 2) 1. Alice chooses a secret passphrase – 4 -10 words, at least 20 chars, stuff 2. Run the encryption by: – – – Pick a random seed and cipher IV K = HMAC(seed, SHA 1, passphrase) C = E{cbc}(K, IV, M) 3. Result is <seed, IV, C> 4. Securely erase M, K – 1/9/03 Disk blocks, memory, swap space, file system slack space, … Crypto for IT Staff Mad-Sage 48
Passphrase protection (2 of 2) • Used by PGP, Tripwire, Digital Certificates to protect private keys • Other PGP uses: – file protection without public keys – broadcast e-mail (e. g. by FIRST) • Victor will try to brute force the passphrase – 20 characters of monocase English words is only 26 bits of entropy 1/9/03 Crypto for IT Staff Mad-Sage 49
digital certificates: (1 of 4) • X. 509 v 3 / RFC 3280 (April 2002) • Roughly, a nested structure < blob, <algorithm, signature>>, with blob <version, serial. Number, algorithm, issuer, validity_period, subject_name, subject_public_key, …> • How you find them: Certificate: <issuer, serial_number> Subject: <subject_name, public_key> 1/9/03 Crypto for IT Staff Mad-Sage (Theresa) (Alice, Bob) 50
Digital Certificates: CA (2 of 4) • Certificates are created when a subject requests a Certificate Authority (CA) to sign a <name, public key, …> blob. – The CA has to verify some things • Certificate subjects vary – email address, DNS name, IP address, … • Anyone can be a CA – Win 2 k and Open. SSL can issue certificates – Trust issues later, in part 3 1/9/03 Crypto for IT Staff Mad-Sage 51
Certificates 3: chains and uses • Alice’s certificate is signed by a chain of 0 or more intermediate certificates • The certificate from the last intermediate CA is signed by a root certificate – Which Theresa self-signed • Constraint fields control permitted uses – Encryption, message signing, code signing, certificate signing, … 1/9/03 Crypto for IT Staff Mad-Sage 52
Certificates 4: Revoking • A certificate might become obsolete or unsafe and need to be revoked before it would expire – Name changes, private key compromised, change of controlling organization, … • The CA needs to periodically publish its X. 509 Certificate Revocation List (CRL) – List of <issuer, serial_number, revoke_timestamp> – PKIX group may define on-line revocation • The certificate user should check the entire chain for revocations! 1/9/03 Crypto for IT Staff Mad-Sage 53
Public Key trust models • If Alice doesn’t know Bob, they need Teresa to introduce them. • 3 typical models – Centralized: Theresa holds everyone’s keys • Kerberos key distribution center (KDC) – Hierarchical: she’s a root certificate authority • TLS, S/MIME, SSH – Distributed: Alice and Bob happen to trust her • PGP, SSH, Thwate e-mail user names 1/9/03 Crypto for IT Staff Mad-Sage 54
Centralized trust – Kerberos • Pro: easy within a single organization • Cons: – Bad for web sites / e-mail / anything else that crosses organizational boundaries – If the central authority is compromised, all users need new keys • E. g. v 4 kadmind compromize at U. of Upsala – Microsoft Windows 2000 domain controllers are scary compared to an MIT style KDC 1/9/03 Crypto for IT Staff Mad-Sage 55
Hierarchical trust – PKI • Pro: – Can work well across cooperating organizations • Con: – Infrastructure part is still missing • Too many roots, e. g. 150 in IE 6 • Revocations are highly problematic • Lots of sloppiness in constraints – Users don’t understand whom they are trusting • Most e-commerce sites look like man-in-the-middle attacks – Commercial roots charge high prices 1/9/03 Crypto for IT Staff Mad-Sage 56
Ellison/Schneier: 10 risks of PKI • • • 1/9/03 Who do we trust, and for what? Who is using my (private) key? How secure is the verifying computer? Which John Robinson is he? Is the CA an authority? Is the user part of the security design? Was it one CA, or a CA plus a Registration Authority? How did the CA identify the certificate holder? How secure are the certificate practices? Why are we using the CA process, anyway? Crypto for IT Staff Mad-Sage 57
Distributed trust – PGP • Example: web of trust Alice’s key is signed by Theresa, whose key was signed by Tori, signed by Talia – and Bob trusts all three. • Pro: – distributed, end users control it, in live use – Infrastructure is a ring of keyservers – cheap! • Con: – There may not be any trust path – Be wary of fake keys and junk signatures – Requires highly trained and careful users 1/9/03 Crypto for IT Staff Mad-Sage 58
TLS / SSL • History: – Netscape designed Secure Sockets Layer, SSL v 2, SSL v 3 • Primarily to protect web e-commerce • IETF tweaked to Transport Layer Security – aka SSL 3. 1, RFC 2246 (Jan 1999) • Goal: an encrypted communication channel riding atop TCP but below Applications – HTTPS, SPOP, FTPS, … 1/9/03 Crypto for IT Staff Mad-Sage 59
TLS: record protocol • Alice’s record protocol takes messages to be transmitted, fragments them into blocks of 2^14 bytes, compresses, applies an HMAC, encrypts, and sends – A record can contain multiple messages – the usual crypto components • Bob’s record protocol receives, decrypts, verifies, decompresses, and reassembles 1/9/03 Crypto for IT Staff Mad-Sage 60
TLS: client protocols • 3 TLS control protocols – Handshake: crypto setup – Alert: errors and shutdown – Change Cipher • Higher level Applications – HTTP, POP, IMAP, SMTP, … – application messages have lower priority 1/9/03 Crypto for IT Staff Mad-Sage 61
TLS: Handshake 1 of 2 1. A->B: client hello <version, timestamp, client random, session id, <list of cipher suites>, <list of compressions>> 2. B->A: server hello <selected_version, server_timestamp, server_random, selected_session, selected_cipher_suite, selected_compression> <server certificate>? (usual) <server key exchange>? (Diffie-Hellman) <server certificate request>? (authenticate client) 1/9/03 Crypto for IT Staff Mad-Sage 62
TLS: Handshake 2 of 2 3. A->B: client finished <certificate>? (if server requested) <Client Key Exchange> (required) <Certificate Verify>? (demonstrate client secret key) [change cipher spec] <finished> (repeat parameters under cipher) 4. B->A: server finished [change cipher spec] <finished> (repeat parameters under cipher) • 1/9/03 Now application messages start Crypto for IT Staff Mad-Sage 63
TLS Handshake: context • An abbreviated protocol reuses sessions – E. g. HTTPS persistent connection – redo cipher (skip certificates, key exchange) • application layer must check the outcome – Abort if the negotiated crypto is too weak • Cipher suite changes / re-initializations – Whenever the application asks – Mandated every 2^64 bytes 1/9/03 Crypto for IT Staff Mad-Sage 64
TLS: connection state • 4 pieces – Current and pending states – Independently for read and write directions • Each piece contains 3 algorithms , along with their parameters (e. g. block cipher CBC IV) – MAC, compression, block cipher • Initialized with null-null • Change_cipher_state sets current=pending – You have to initialize before you can use 1/9/03 Crypto for IT Staff Mad-Sage 65
TLS: PRF stream gizmo • Needs a stream of pseudo random bits – for cipher initialization – from handshakes fixed size shared secrets • PRF stream mixes (xor): iterated HMAC(secret, MD 5, label || seed) iterated HMAC(secret, SHA 1, label || seed) • The hope is that even if MD 5 or SHA 1 were cracked, the PRF might still be secure 1/9/03 Crypto for IT Staff Mad-Sage 66
TLS: key exchange • Pre-master-secret is from one of – Diffie-Hellman key exchange – Client secret sent under server’s certificate public key – Kerberos (see RFC 2712) • Shared master secret computed as: PRF(pre-master-secret, ‘master secret’, client_random || server_random) 1/9/03 Crypto for IT Staff Mad-Sage 67
TLS: cipher suites • One mandatory TLS_DHE_DSS_WITH_3 DES_EDE_CBC_SHA • Other RFCs add more, e. g. from #3268: TLS_DHE_RSA_WITH_AES_128_CBC_SHA • We’re skipping the 40 -bit export degradation details 1/9/03 Crypto for IT Staff Mad-Sage 68
SSH v 2: about • Provides secure services over untrusted networks – remote login, remote execution, and packet tunneling • e. g. forwarding X 11 – replaces: telnet, ftp, rlogin, rsh, rcp • Most terminal emulation vendors – SSH; also F-secure, Esker, Van. Dyke, . . . – Open. SSH (Canadian) 1/9/03 Crypto for IT Staff Mad-Sage 69
SSH v 2: architecture • broadly similar to TLS – transport layer protocol • server authentication, confidentiality, integrity – user authentication protocol – connection protocol • multiplexes logical channels 1/9/03 Crypto for IT Staff Mad-Sage 70
SSH v 2: some details • packets <payload, random padding, MAC> – 1. Compress 2. Encrypted 3. HMAC • ciphers (cbc mode) chosen from: – IDEA, CAST, 3 DES, AES, Twofish, Serpent, … • separate HMAC's for read & write – MD 5, SHA 1 – shared secret keys 1/9/03 Crypto for IT Staff Mad-Sage 71
SSH v 2: initialization • session key exchange: diffie-hellman • public key authentication of server – options: DSA, RSA, various certificates – client must warn if pubkey unknown or changed • PRF iterates H(shared secret || … || label || session ID) 1/9/03 Crypto for IT Staff Mad-Sage 72
IPSEC: about • packet security for IPv 6 – optionally backported to IPv 4 • Authentication Header protocol #50 (AH) – HMAC's packet headers and data • Encapsulating Security Protocol #51 – ESP encrypts data • Key exchange on UDP port 500 1/9/03 Crypto for IT Staff Mad-Sage 73
IPSEC: crypto & usage • The (by now) usual crypto: – DH key exchange – MD 5 or SHA 1 hashes for HMAC – block ciphers in CBC mode – optional certificates for authentication • Can secure: – individual session flows – all traffic between two hosts – tunnel subnets between gateways 1/9/03 Crypto for IT Staff Mad-Sage 74
IPSEC: a few details • Policy database controls packet fate – apply IPSEC, or ignore IPSEC, or reject • Security Association Index database – tracks live connections – AH and ESP use separate associations – read & write directions are also separate 1/9/03 Crypto for IT Staff Mad-Sage 75
S/MIME • similar to PGP e-mail • public keys are in certificates • signatures are always detached – multipart MIME 1/9/03 Crypto for IT Staff Mad-Sage 76
Tripwire • Host intrusion detection – due to failure of security, HW, OS, Admin, … • DB of – inode info (owners, permissions, modification times, device, …) – Hashes (MD 5, SHA 1, Haval, CRC 32, …) • Passphrase protected private keys sign: – Configuration, Policy file, and DB – Optionally, reports 1/9/03 Crypto for IT Staff Mad-Sage 77
Crypto in Modern Unix • Salted MD 5 to store password info • Kernel entropy sources: – /dev/random: blocks until enough – /dev/urandom: stirred pseudo-random • Lot's of application crypto – Kerberos, SSH, TLS, GPG, S/MIME, Tripwire 1/9/03 Crypto for IT Staff Mad-Sage 78
Vendor example: Red. Hat • Packages, ISO images, Security Bulletins – MD 5 hashes (going to SHA 1) – GPG signatures of the hashes • Red. Hat network: – administrators do password login over HTTPS – client hosts must register a certificate – signed update packages arrive via TLS 1/9/03 Crypto for IT Staff Mad-Sage 79
Guidance Part three 1/9/03 Crypto for IT Staff Mad-Sage 80
Equivalent Key lengths? Symmetric Elliptic RSA / DSA Till year 56 112 512 1982 80 160 1464 2013 112 224 2048 128 256 1/9/03 2304 ~15, 000 Crypto for IT Staff Mad-Sage 81
Safe key lengths … review in 2007 • symmetric block cipher keys: 112 -128 bit – 14 more symmetric bits ~ 20 years of Moore’s law • Public key algorithms – RSA, El. Gamal : 2048 -3072 bit (PGP e-mail: 2048) – DSA is 1024/160 (but ought to be 2048/224) – Elliptic curve public keys: 224 bit • The state of the (civilian) break: – Symmetric: 56 bit DES by 1997 (NSA: 75 bit? ) – Elliptic: 108 bit in 2000 – RSA: 512 bit in 1999 (503 bit El. Gamal/DSA) 1/9/03 Crypto for IT Staff Mad-Sage 82
Snake oil • Bad crypto is hard to tell from good crypto. • 4 top snake oil crypto warning signs: – Use of proprietary new technologies with no footnotes to the cryptanalysis literature • The adjective revolutionary is especially suspect – Pretending that overall security depends mostly on the crypto strength • Obsession with exaggerated key sizes – Touting one time pads 1/9/03 Crypto for IT Staff Mad-Sage 83
About those one time pads • … a stream cipher using a random key. – Alice and Bob destroy key material in parallel with each message. • Theoretically unbreakable, as a cipher – Who cares? Our block ciphers are plenty tough! • Lousy as a cryptosystem – – 1/9/03 Key size (secret) = message size No protection against errors or substitution No signatures requires physical couriers first, and often Crypto for IT Staff Mad-Sage 84
One time pad snake oil Purveyors invariably deviate from OTP 1. Reuse the random key bits. • Two time pads are worthless • Victor will xor the two messages, removing the key. (the xor’d plaintext has enough redundancy to break) 2. Have psuedo-random key bits • That’s an ordinary stream cipher • 1/9/03 … and probably a really bad one, too Crypto for IT Staff Mad-Sage 85
Choosing protocols, in general • Go back at most 1 version / 2 years – Often protocols change for security reasons – Current code gets better auditing. In 2002: • No SSH v 1. 5, no CRC-32 compensation attack • No SSL v 2, no Slapper worm • No Kerberos v 4, no kadmind compromise • Stay current on software and patches • No PGP < 7. 1, no unauthorized ADK attacks • Get rid of plaintext (Telnet, FTP, …) 1/9/03 Crypto for IT Staff Mad-Sage 86
PGP usage advice • Your IRT should know gpg • Large scale use: buy PGP • E-mail keys: – For 2003: 2048 bit DH/DSS v 4 key with CAST – In 2005: 3072 bit RSA v 4 key with AES-128 • Key servers – Don’t upload to a key server for a few months – Do print a revocation certificate before upload 1/9/03 Crypto for IT Staff Mad-Sage 87
PGP key signing practices • Require multiple authentications before locally signing – E-mail, key-server, organizational web site, phone call • Require in personal verification of both identity (e. g. passport) and key fingerprint before uploading an exportable signature • Note: smaller keyrings perform better 1/9/03 Crypto for IT Staff Mad-Sage 88
TLS/SSL advice • Turn off SSLv 2 • Open. SSL users should be on at least 0. 9. 6 g from August (0. 9. 7 is just out). • Tunneling works just fine with private certificates on the client and server • you don't have to buy commercial certificates • On the web it provides good confidentiality, but only mediocre authentication 1/9/03 Crypto for IT Staff Mad-Sage 89
SSH advice • Get onto v 2 protocol only ASAP • For remote execution, use pubkey authentication – Much safer than rhosts, rsh, etc. – Can be restricted to a single command • Consider ssh-agent / keychain – The poor man’s Kerberos / single sign-on • Be wary of end-user port forwarding 1/9/03 Crypto for IT Staff Mad-Sage 90
Tripwire advice • You do want some host intrusion detection • Do tweak the configuration – give it a private tmp directory – turn on syslog reporting • Do tune the policy file – Ok to start with the default if you’ve never used it before – Use tripwire for policy updates, not twadmin • report files: do not sign, do mail off-host 1/9/03 Crypto for IT Staff Mad-Sage 91
HIPAA advice • Plan to encrypt more stuff – e-mail, probably with S/MIME. – Files on laptops, PDA's etc. • Do a threat analysis, and start mitigating – Nice template in job aid #1 from appendix C of Microsoft's Security Operations Guide for Windows 2000 Server • Work off the ’ 98 draft security regulation until CMS releases the final one. 1/9/03 Crypto for IT Staff Mad-Sage 92
Things we didn’t cover • Elliptic curve public key details. – Which will probably be the favorite by 2010 • Exotic key handling – Key splitting (J of N holders to reconstruct) • Financial stuff: SET, Micropayments, … • Covert channel attacks, tamper resistance • . . . 1/9/03 Crypto for IT Staff Mad-Sage 93
Crypto politics • Most countries regulate crypto (US: ITAR) – Wassenaar: its dual use / munitions – key escrow controversies (US, UK) • 80 bit Skipjack and the LEAF • Victor is using it too – mafia uses PGP, botnets have code signing • Commercial abuse – DCMA: block fair use / consumer rights – Prevent interoperability / competition 1/9/03 • Inkjet cartridges, cell phone batteries, DVD, … Crypto for IT Staff Mad-Sage 94
For Further reference • NIST http: //csrc. nist. gov/ • RSA http: //www. rsasecurity. com/rsalabs/ • Counterpane http: //www. counterpane. com/ • This presentation will be available RSN – watch mad-sage for an announcement 1/9/03 Crypto for IT Staff Mad-Sage 95
Скачать презентацию Goals Lay out some basic crypto concepts
e0a9087db8127d37be3e3a7ca881ca0f.ppt