1/9/03 Crypto for IT Staff Mad-Sage1 Goals Lay out some basic crypto concepts –Yes, there will be...

1/9/03 Crypto for IT Staff Mad-Sage 1

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– Tonight’s focus is on the crypto

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


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


Warm up

Introduction and Notation


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.


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


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)


Notation - crypto

M = 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


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

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


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 are needed 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


Commonly used block ciphers

• RC2, 3DES, 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


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!


Safe variants of DES

1. 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)))– If k1=k2=k3, degenerates to DES– Often used with just two keys: k3=k1– net strength ~ 2^112; sluggish but oddly popular


Some 3DES cryptanalysis points

• Due to a meet in the middle attack, 3DES 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, 2DES wouldn’t be enough stronger than 1DES

• E-D-E resists the class of differential attacks better than E-E-E


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


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


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!


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 ciphertextC[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.


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


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


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


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


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


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

u1 = (H(M) * w) mod q, u2 = (r*w) mod qv = ((g^u1 * y^u2) 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

• 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


Summary: crypto primitives

• 5 basic primitives– Symmetric secret key block ciphers (3DES, AES, …)– Diffie-Hellman key exchange– Public key encryption (RSA, ElGamal, Elliptic)– Hash functions (MD5, SHA1, …)– 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)


Decomposing Applications and Protocols

Part two


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 (SHA1), and a compression algorithm (ZLIB)

2. Seed CPRNG with entropy, 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(K{As}, SHA1(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)


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

<‘sha1’, SIG > >

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


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

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– Used only on small, random things: session keys and

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


Interlude: Microsoft EFS

• Tweak our 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– Win2K and XP use DESX as the cipher– Recent service packs added AES


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, SHA1, passphrase)– C = E{cbc}(K, IV, M)

3. Result is <seed, IV, C>4. Securely erase M, K

– Disk blocks, memory, swap space, file system slack space, …


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


digital certificates: (1 of 4)

• 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 find 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 has to verify some things

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

• Anyone can be a CA– Win2k and OpenSSL can issue certificates– Trust issues later, in part 3


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


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!


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


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 compromize at U. of Upsala

– Microsoft Windows 2000 domain controllers are 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 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


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 trustAlice’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)

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


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


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)

• 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

• Initialized with null-null-null• Change_cipher_state sets current=pending

– You have to initialize before you can use


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

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


TLS: cipher suites

• One mandatoryTLS_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– 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)


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

• Key exchange on UDP port 500


IPSEC: crypto & usage

• The (by now) usual crypto:– DH key exchange – 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 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

• similar to PGP e-mail

• public keys are in certificates

• signatures are always detached– multipart MIME


Tripwire

• Host intrusion detection– due to failure of security, HW, OS, Admin,…

• DB of – inode info (owners, permissions, modification

times, device, …)– Hashes (MD5, SHA1, Haval, CRC32, …)

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


Crypto in Modern Unix

• Salted MD5 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


Vendor example: RedHat

• Packages, ISO images, Security Bulletins– MD5 hashes (going to SHA1)– GPG signatures of the hashes

• RedHat network: – administrators do password login over HTTPS– client hosts must register a certificate– signed update packages arrive via TLS


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: 112-128 bit – 14 more symmetric bits ~ 20 years of Moore’s law

• Public key algorithms– RSA, ElGamal : 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 ElGamal/DSA)


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


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

• … and probably a really bad one, too


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– In 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 personal 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• OpenSSL users should be on at least

0.9.6g 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


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


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.


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

• ...


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

• Inkjet cartridges, cell phone batteries, DVD, …


For Further reference

• NIST http://csrc.nist.gov/

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

• Counterpanehttp://www.counterpane.com/

• This presentation will be available RSN– watch mad-sage for an announcement

1/9/03 Crypto for IT Staff Mad-Sage1 Goals Lay out some basic crypto concepts –Yes, there will be...

Documents

Transcript of 1/9/03 Crypto for IT Staff Mad-Sage1 Goals Lay out some basic crypto concepts –Yes, there will be...