Lockdown 2003 Encryption for IT Staff1 James Leinweber WI State Lab of Hygiene & BadgIRT Kerckhoff's second requirement (La Cryptologie militaire, 1883)

Lockdown 2003 Encryption for IT Staff 1

Encryption for IT Staff

James Leinweber

WI State Lab of Hygiene & BadgIRT

Kerckhoff's second requirement (La Cryptologie militaire, 1883) "... compromise of the system [algorithms] should not inconvenience the correspondents"



James Leinweber


John von Neumann (1951): "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin."



James Leinweber


Bruce Schneier (preface to Applied Cryptography, 1996): "There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments ..."



James Leinweber


an NSA employee, asked about DES:

"Real systems are so insecure that the NSA needn't bother breaking the crypto"


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 :-(


Non Goals• No proofs

• Hardly any history

• Skipping or simplifying many implementation details

• Not a tutorial on the protocols & apps– our focus is on the cryptography

• We won’t become either cryptographers (designers) or cryptanalysts (breakers)


Outline• Warmup

• Two cipher examples, today’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, …


Warm up

Introduction and Notation


An (old) Cipher exampleM: 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.


A better (Renaissance) CipherM: 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


Notation – personsA is for Alice

(sender, client)

B is for Bob (receiver, server)

V is for Victor (villain / eavesdropper / spy / bad guy / black

hat)

T is for Theresa

(a trusted third party)


Notation - mathp, 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,’sha1’>

[ ] = text slice/block, { } = annotation


Notation - cryptoM = plaintext message (file, packet, …)

C = encrypted ciphertext of M

k, k1, k2, k3 = secret symmetric keys

K{As} = Alice’s private (secret) key,

K{Bp} = Bob’s public key

E(k,M) = encrypt plaintext M via key kUsing whatever algorithm we’re working with

D(k,C) = decrypt ciphertext C via key k


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 and analyze it– inject packets, or delete packets– change packet contents– replay packet streams

• Lots of effort goes into preventing this!


A few acronyms and sources• NIST

National Institute of Standards and Technologies

• FIPS Federal Information Processing Standard

(Available from NIST)

• RFC Request For Comments

Internet Engineering Task Force candidates for standards


8 cryptographic primitives (building blocks)

Part One


1: symmetric secret key block ciphers

SymmetricA enciphers and B deciphers with the same key

Secret KeyThe security depends only on how well A and B protect

their shared key.

Blockworks on chunks of message, usually 64 or 128 bits

Cipheroutput size of gobbledegook ~ input size of message


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, on average, to break a single N-bit key


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– key gets expanded into internal state


Some well known block ciphers• DES: Data Encryption Standard (FIPS 46-2)

– 64 bit blocks, 56 bit keys, 16 S-P rounds– Unsafe: publicly brute forced 1997. Withdrawn!

• CAST-128 (RFC-2144)– 64 bit blocks, 128 bit key, 16 rounds– currently a good choice for interoperability

• IDEA: International Data Encryption Algorithm– 64 bit blocks, 128 bit key, 8 Rounds (patent 2007)

• AES: Advanced Encryption Standard (FIPS 197)– 128 bit blocks; 3 key size / round variants: 128 bit key / 10 rounds , 192 / 12, 256 / 14


Safe variants of DES1. DESX: E(k1, M xor k2) xor k3

– k2 and k3 provide pre- and post- whitening, like unix password salt.

– net strength ~ 2^120; as fast as DES– Extensively used by Microsoft in Win2K

2. 3DES: E(k3, D(k2, E(k1, M)))– E-D-E resists differential attacks better than E-E-E– Often used with just two keys: k3=k1– If k1=k2=k3, degenerates to DES

• IBM bank hardware interoperated that way

– net strength ~ 2^96; sluggish but oddly popular


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 care about:– interblock feedback?– error propagation?

• Military radios: yes. Computers: no.

– random access?

• 4-7 modes in common use• AES has 23 proposed modes (NIST SP 800-38a)


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


Mode CBC: Cipher Block Chaining• Start, block 0: xor a random initialization vector

– Block worth of salt / whitening bits (128 bits for AES)– 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 ciphertextC[j] = E(k, M[j] xor C[j-1]) M[j] = D(k, C[k]) xor C[j-1]

• Last block: – online (M size unknown): adopt a padding convention

• TLS: always pad, padding char = length of padding

– offline (M size known): ciphertext stealing gimmick?• needs to swap the order of the last two blocks


3: Diffie – Hellman key exchangeFrom 1976 paper "New Directions in Cryptography"

• An on-line protocol for Alice and Bob to generate a shared secret S– Widely used: 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 hard3 = 2^ w mod 11 … w = ?


Diffie-Hellman details1. 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 ppicks 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 ppicks 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 pAlice: S=B^x mod p. Bob: S=A^y mod p.

• Victor, eavesdropping on p,g,A,B, can’t find S


4: Public Key: proposedDiffie & Hellman also analyzed the

possibilities of asymmetric cryptosystems• Alice would use one key to encrypt, Bob

would use a different key to decrypt.• Allows offline key exchange, and digital

signature protocols• Needs a one way trapdoor function

– Something easy to compute but hard to invert, unless you possess an extra secret


Public Key: realized• A flurry of candidates for one way trapdoor

functions were proposed. Three survive:– Factoring, discrete logarithms, elliptic curves

• It’s all number theory: modular exponentiation in finite fields and groups

• But: they are all slow and weak– 1000x slower than block ciphers, or worse– Solutions much faster than key guessing exist– significantly vulnerable to known text attacks


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ê mod N• Decrypt: M = C^d mod N


Pubkey: ElGamal (discrete log)• choose large random prime p, and random

g, x both less than p. Let y = g^x mod p.• private key is x; public key is <p,g,y>• 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


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 much shorter key sizes


5: cryptographic hash functions• Also known as message digest algorithms

– E.g. MD5, SHA-1, Haval, RIPEM-160, …

• Design goals:– fast, fixed size output, one-way (exponential

work to invert), strongly collision free, avalanche property, …

– NB: CRC32 flunks all the crypto properties

• Used for: identifying blob contents – messages, files, packets, PGP keys, digital

certificates, …


Two popular hashes• MD5: 128 bits (RFC 1321)

– Derived from the RC4 stream cipher.– Don’t use it in new apps

• SHA1: 160 bits (FIPS 180-1)– An NSA tweak of SHA, a stronger cousin of MD5– Currently a good choice

• hash size should be 2x 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.


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, sha1, record_seq_no || C)

• An alternative: last block from CBC-mode cipher


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=SHA1 is popular.

• RSA example: (PGP, rfc2437, PKCS#1, X9.31)– Alice: send SIG = E(K{As}, H(M))– Bob: compare H(M) =? D(K{Ap}, SIG)


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


NIST DSA, 2 of 3: verifyingBob:

Receive message M with signature <r,s>

obtain public DSA key of Alice: <p,q,g,y>

Compute: w = 1/s mod q

u1 = (H(M) * w) mod q, u2 = (r*w) mod qv = ((gû1 * yû2) mod p) mod q

If v=r, then Alice’s signature of M is valid


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) (FIPS 186)– X9.31 (an RSA variant) (FIPS 186-1)– Elliptic curves (FIPS 186-2)


8: cryptographic pseudorandom number generating functions

• We need good choices for p,q,k,x,y,IV,...

• Design goals:– can't invert, can't deduce seed, can't predict

runs, no bit correlations, no weak seeds, …

• you must seed it with real entropy – best: disk spindle speed jitter, thermal noise– tolerable: I/O latencies (keyboard, mouse, …)– unacceptable: time of day || process id


A good CPRNG is very important• linear congruential is not a CPRNG

Y = a * X + b mod N

• often the weakest link in a cryptosystem! – guessing Bell Labs passwords on a pdp-11– Netscape 2 doing SSLv2– PGP 6 doing DH/DSS on NT4 prior to sp4– numerous CERT advisories:

• weak TCP sequence numbers and DNS packet ID's

– PkZip archives with 3+ files?• Next version has real crypto from RSA, Inc.


Summary: crypto primitives• 5 basic primitives

– Symmetric secret key block ciphers (DESX, AES, …)– Diffie-Hellman key exchange– Public key encryption (RSA, ElGamal, Elliptic)– Hash functions (MD5, SHA1, …)– Cryptographic 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)


Decomposing Applications and Protocols

Part two


Signed, encrypted e-mail: PGPAlice sending e-mail M to Bob, with Bcc to self

1. Choose a signing algorithm (RSA) and private/public key pair (<K{As}, K{Ap}>), a block cipher (IDEA), a hash algorithm (SHA1), and a compression algorithm (ZLIB)

2. Seed CPRNG with entropy

3. Set up block cipher. Generate:• a random 128 bit session key k• a random 64 bit initialization vector IV


PGP e-mail: Alice to Bob (2 of 7)3. Compute signature: hash message,

encrypt (RSA) with Alice’s private key: SIG = E{rsa}(K{As}, SHA1(M))

3. Compress and encrypt M C = E{idea-cbc}(k, IV, zlib(M))5. Encrypt the session key with each

recipients (Bob, Alice), RSA public key: E{rsa}(K{Bp}, k) E{rsa}(K{Ap}, k)


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>,

<'rsa', H(K{Ap}), ‘sha1’, SIG > >

7. ascii-encode the result, e-mail it, and archive it.


PGP e-mail 4: Bob receiving1. 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}:

SHA1(M) =? D{rsa}(K{Ap}, SIG)


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


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– So our public keys are much longer than our one time

use block cipher session keys– We only use public keys on small, random things:

session keys, message hashes


PGP: v4 keys• Our example used v3 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, 3DES, AES, …


Digital Envelopes : reprise• Tweak our our PGP example:

– put Alice’s key into a digital certificate– make Bob the file system recovery agent– let the message M be a disk file– Choose DESX as the block cipher

• We'd be very near to Microsoft’s Encrypting File System– Recent service packs add AES cipher


Passphrase protection: how1. Alice chooses a secret passphrase

– 4-10 words, with at least 20 good characters

2. Run the encryption by:– Pick a random seed and cipher IV– Derive K from HMAC(seed, SHA1, passphrase)– C = E{cbc}(K, IV, M)

3. Result is <seed, IV, C>– K isn't stored! lost passphrase = lost M

4. Securely erase M, K– Disk blocks, memory, swap space, file system slack

space, …


Passphrase protection: why• Needed to protect private keys

– SSH, Digital Certificates, EFS, PGP, …

• Other uses (PGP): – file encryption without public keys– broadcast e-mail (e.g. by FIRST)

• Victor will try to brute force the passphrase– 20 characters of monocase English text is

only 24 bits of entropy


digital certificates: (1 of 4)• binds a distinguished name to a public key with

a digital signature– X.509 v3 / RFC 3280 (April 2002)– Roughly, a nested structure

< blob, <algorithm, signature>>, with blob<version, serialNumber, algorithm,

issuer, validity_period, subject_name, subject_public_key, …>

• How you identify them:Certificate: <issuer, serial_number> (Theresa)

Subject: <subject_name, public_key> (Alice, Bob)


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 must to verify:

• possession of private key, appropriate … stuff for name

• Certificate subjects (names) vary– email address, DNS name, IP address, …

• Anyone can be a CA– Win2k and OpenSSL can issue certificates

(Trust issues coming up soon)


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– a root certificate is one that signed itself

• Constraint fields control permitted uses• Encryption

• message signing

• code signing

• certificate signing


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!– Which is really hard, and really slow


Public Key trust models• If Alice doesn’t know Bob, they need

Theresa 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, Thawte e-mail user names


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. v4 kadmind compromise at U. of Uppsala

– Microsoft Windows 2003 domain controllers are still scary compared to an MIT style KDC


Hierarchical trust – PKI• Pro:

– Can work well across cooperating organizations

• Con:– Infrastructure part is still missing

• Too many roots, e.g. 150 in IE6

• Revocations are highly problematic

• Lots of sloppiness with 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


Ellison/Schneier: 10 risks of PKI• 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?


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


TLS / SSL• History:

– Netscape designed Secure Sockets Layer, SSL v2, SSL v3

• Primarily to protect web e-commerce

• IETF tweaked to Transport Layer Security– aka SSL 3.1, RFC 2246 (Jan 1999)

• SSLv2 was experimental, SSLv3 was draft. Both are expired.

• Goal: an encrypted communication channel riding atop TCP but below Applications– HTTPS, SPOP, FTPS, LDAP, IMAP, …


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


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


TLS: Handshake 1 of 21. 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)

<client certificate request>? (authenticate client)


TLS: Handshake 2 of 23. 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)

• Now application messages start


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


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

• Change_cipher_state sets current=pending– initialize pending before using it– TLS bootstraps with current = <null,null,null>


TLS: PRF stream gizmo• Needs a stream of pseudo random bits

– for cipher initialization– handshake yields fixed size shared secrets

• PRF stream mixes (xor):iterated HMAC(secret, MD5, label || seed)iterated HMAC(secret, SHA1, label || seed)

• The hope is that even if MD5 or SHA1 were cracked, the PRF might still be secure


TLS: key exchange• Shared Pre-master-secret is from one of

– Diffie-Hellman key exchange– Client secret sent under server’s certificate

public key– Kerberos (see RFC 2712)

• Joint master secret computed as:PRF(pre-master-secret, ‘master secret’,

client_random || server_random)


TLS: cipher suites• One mandatory

TLS_DHE_DSS_WITH_3DES_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


SSH v2: about• Provides secure services over untrusted

networks– remote login, remote execution, and packet

tunneling• e.g. forwarding X11

– replaces: telnet, ftp, rlogin, rsh, rcp

• Most terminal emulation vendors– SSH; also F-secure, Esker, VanDyke, ...– OpenSSH (Canadian)


SSH v2: architecture• broadly similar to TLS

• e.g. OpenSSH uses crypto from OpenSSL

– transport layer protocol• server authentication, confidentiality, integrity

– user authentication protocol– connection protocol

• multiplexes logical channels


SSH v2: some details• packets <payload, random padding, MAC>

– 1. Compress 2. Encrypted 3. HMAC

• ciphers (cbc mode) chosen from:– IDEA, CAST, 3DES, AES, Twofish, Serpent,

…

• separate HMAC's for read & write– MD5, SHA1– shared secret keys


SSH v2: 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)– wimpier than TLS


IPSEC: about• packet security for IPv6

– optionally backported to IPv4

• Authentication Header protocol #50 (AH)– HMAC's packet headers and data

• Encapsulating Security Protocol #51– ESP encrypts data only

• Key exchange on UDP port 500


IPSEC: crypto & usage• The (by now) usual crypto:

– DH key exchange, or pre-shared password – MD5 or SHA1 hashes for HMAC– block ciphers in CBC mode– optional certificates for authentication

• Can secure:– individual session flows– all traffic between two hosts– tunnel entire subnets between gateways


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


S/MIME v3• Digital envelope (similar to PGP e-mail)

– public keys are in X509v3 certificates• might be ephemeral

– encryption: ElGamal (optionally RSA)– signing: DSA (optionally RSA)

• s/mime v2 uses only RSA

– hash: SHA1 (optionally MD5)

• signatures are always detached– CMS (PKCS#7) format, or multipart MIME


Tripwire• Host intrusion detection

– due to failure of security, HW, OS, Admin,…

• DB of – file meta-info: e.g. unix (owners, permissions,

modification times, device, …) from inode– Hashes of data (MD5, SHA1, Haval, CRC32)

• Passphrase protected private keys sign:– Configuration, Policy file, and DB– Optionally, reports


Guidance

Part three


Equivalent Key lengths?Symmetric Elliptic RSA / DSA Till year

56 112 512 1982

80 160 1464 2013

112 224 2048

128 2304

256 ~15,000


Safe key lengths … review in 2007• symmetric block cipher keys: 128 bit

– 14 more symmetric bits ~ 20 years of Moore’s law

• Public key algorithms– RSA, ElGamal : 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: 65 bit RC5 in 2002 (NSA: 75 bit?)– Elliptic: 108 bit in 2000– RSA: 512 bit in 1999 (503 bit ElGamal/DSA)


Keys & risks• Long keys don't make you safe

– safety depends on key handling, environment– change public keys, passphrases periodically

• non-crypto e-commerce risks are real:– things Victor has done:

• spoof a credit card number and defraud Bob

• install a keystroke trojan on Alice’s computer– log her credit card number, passphrases, …

• break into Bob’s server, steal his entire DB

• break into a processing firm, steal 5M cards (Feb 2003)


Snake oil• Bad crypto is hard to tell from good crypto.

• 3 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


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– Key size (secret) = message size– No protection against errors or substitution – No signatures– requires physical couriers first, and often


One time pad snake oilPurveyors invariably deviate from OTP

1. Reuse the random key bits.• … but 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

• … and probably a really bad one, too

(a popular variable size key stream cipher is RC4)


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 v1.5, no CRC-32 compensation attack

• No SSL v2, no Slapper worm

• No Kerberos v4, no kadmind compromise

• Stay current on software and patches• No PGP < 7.1, no unauthorized ADK attacks

• Get rid of plaintext (Telnet, FTP, …)


PGP usage advice• Your IRT should know gpg

• Large scale use: buy PGP

• E-mail keys:– For 2003: 2048 bit DH/DSS v4 key with CAST– For 2005: 3072 bit RSA v4 key with AES-128

• Key servers– Don’t upload to a key server for a few months– Do print a revocation certificate before upload


PGP key signing practices• Require multiple authentications before

locally signing– E-mail, key-server, organizational web site,

phone call

• Require in person verification of both identity (e.g. passport) and key fingerprint before uploading an exportable signature

• Note: smaller keyrings perform better


TLS/SSL advice• Turn off SSLv2

– and IE should turn on TLS

• Recent codebase (OpenSSL >= 0.9.6g)

• Can tunnel fine with private certificates• you don't have to buy commercial certificates

• On the web:– provides good confidentiality– … but typically only mediocre authentication– … the real security depends on the end-points


SSH advice• Get onto v2 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


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


Crypto politics• Most countries regulate crypto (US: ITAR)

– Wassenaar: it’s dual use / munition tech– 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

• Inkjet cartridges, cell phone batteries, DVD, …


Things we didn’t cover• Elliptic curve public key / signing 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 / side channel attacks– game the timings, power consumption,…

• the worst direct risks to SSL & smart cards

• ...


For Further reference• NIST

http://csrc.nist.gov/

• RSA http://www.rsasecurity.com/rsalabs/

• Counterpanehttp://www.counterpane.com/

• This presentationhttp://www.doit.wisc.edu/lockdown/…

http://www.slh.wisc.edu/lockdown/

Documents

Lockdown 2003 Encryption for IT Staff1 James Leinweber WI State Lab of Hygiene & BadgIRT Kerckhoff's second requirement (La Cryptologie militaire, 1883)