James Leinweber

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"
2
Encryption for IT Staff

• James Leinweber
• WI State Lab of Hygiene BadgIRT

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

• James Leinweber
• WI State Lab of Hygiene BadgIRT

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 ..."
4
Encryption for IT Staff

• James Leinweber
• WI State Lab of Hygiene BadgIRT

an NSA employee, asked about DES "Real
systems are so insecure that the NSA needn't
bother breaking the crypto"
5
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 shouldnt try this at home -(

6
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 wont become either cryptographers (designers)
  or cryptanalysts (breakers)

7
Outline

• Warmup
• Two cipher examples, todays 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, dos and
  donts,

8
Warm up

• Introduction and Notation

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

10
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

11
Notation persons

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

12
Notation - math

• p, q large prime numbers
• xor exclusive or 1 xor 1 0
• mod modular arithmetic 5 mod 3 2
• exponentiation 2(24) 1 65537
• string concatenation ab
  ab
• ltgt vectors or lists
  lt1,2,sha1gt
• text slice/block, annotation

13
Notation - crypto

• M plaintext message (file, packet, )
• C encrypted ciphertext of M
• k, k1, k2, k3 secret symmetric keys
• KAs Alices private (secret) key,
• KBp Bobs public key
• E(k,M) encrypt plaintext M via key k
• Using whatever algorithm were working with
• D(k,C) decrypt ciphertext C via key k

14
man in the middle attacks

• Instead of Alice lt-gt Bob, we might have
• Alice lt-gt Victor lt-gt 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!

15
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

16
8 cryptographic primitives (building blocks)

• Part One

17
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

18
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

19
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

20
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

21
Safe variants of DES

• DESX E(k1, M xor k2) xor k3
• k2 and k3 provide pre- and post- whitening, like
  unix password salt.
• net strength 2120 as fast as DES
• Extensively used by Microsoft in Win2K
• 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 k3k1
• If k1k2k3, degenerates to DES
• IBM bank hardware interoperated that way
• net strength 296 sluggish but oddly popular

22
2 block cipher usage modes

• What if our message isnt 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)

23
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

24
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
• C0 E(k, M0 xor IV) M0 D(k,
  C0) xor IV
• Middle, blocks j xor prior ciphertext
• Cj E(k, Mj xor Cj-1) Mj D(k,
  Ck) xor Cj-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

25
3 Diffie Hellman key exchange

• From 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 gw mod p is easy
• z 24 mod 11 z 5
• Inverse, finding w given z, g, p is hard
• 3 2 w mod 11 w ?

26
Diffie-Hellman details

• 1. start large prime p, generator g
• 1 lt g lt p. These can be public, and can be
  reused.
• 2. Alice pick x, send A gx mod p
• picks a random x, computes A, sends ltA,p,ggt to
  Bob. X is secret, Message ltA,p,ggt is
  unencrypted.
• 3. Bob pick y, send B gy 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 (xy) mod p
• Alice SBx mod p. Bob SAy mod p.
• Victor, eavesdropping on p,g,A,B, cant find S

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

28
Public Key realized

• A flurry of candidates for one way trapdoor
  functions were proposed. Three survive
• Factoring, discrete logarithms, elliptic curves
• Its 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

29
Public key RSA (factoring)

• Choose p, q large random primes. Let Npq
• p and q are 350-2000 bits (10155-10600)
• 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 ltdgt, public key is ltN,egt
• Alice discards p,q, or keeps them secret with d
• Encrypt C Me mod N
• Decrypt M Cd mod N

30
Pubkey ElGamal (discrete log)

• choose large random prime p, and random g, x both
  less than p. Let y gx mod p.
• private key is x public key is ltp,g,ygt
• encrypt
• choose new, previously unused random k,
  relatively prime to p-1.
• let a gk mod p, b ((yk) M) mod p.
• Ciphertext C lta, bgt
• decrypt M b/(ax) mod p

31
Pubkey Elliptic curves

• Elliptic curve cryptography is based on the
  integer solutions to equations of the form
• Y2 X3 aX 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

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

33
Two popular hashes

• MD5 128 bits (RFC
  1321)
• Derived from the RC4 stream cipher.
• Dont 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.

34
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

35
7 Digital Signature Algorithms

• Goal validate Alices message to Bob
• Authenticate sender
• Prevent tampering
• May provide non-repudiation
• Tactic encipher a message hash H via a public
  key algorithm. HSHA1 is popular.
• RSA example (PGP, rfc2437, PKCS1, X9.31)
• Alice send SIG E(KAs, H(M))
• Bob compare H(M) ? D(KAp, SIG)

36
NIST DSA, slide 1 of 3 signing

• Alice create secret key x, public key ltp,q,g,ygt
• p 512-1024 bit prime, q 160 bit prime factor
  of p-1
• Choose a random large x for secret key, with x lt
  q
• g f((p-1)/q) mod p, with f lt p-1 such that g
  gt 1
• y gx mod p
• Using SHA-1 as H(), compute signature ltr,sgt
• choose random k lt q
• Let r (gk mod p) mod q, s ((H(M) xr)/k)
  mod q

37
NIST DSA, 2 of 3 verifying

• Bob
• Receive message M with signature ltr,sgt
• obtain public DSA key of Alice ltp,q,g,ygt
• Compute
• w 1/s mod qu1 (H(M) w) mod q, u2
  (rw) mod qv ((gu1 yu2) mod p) mod q
• If vr, then Alices signature of M is valid

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

39
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

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

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

42
Decomposing Applications and Protocols

• Part two

43
Signed, encrypted e-mail PGP

• Alice sending e-mail M to Bob, with Bcc to self
• Choose a signing algorithm (RSA) and
  private/public key pair (ltKAs, KApgt), a block
  cipher (IDEA), a hash algorithm (SHA1), and a
  compression algorithm (ZLIB)
• Seed CPRNG with entropy
• Set up block cipher. Generate
• a random 128 bit session key k
• a random 64 bit initialization vector IV

44
PGP e-mail Alice to Bob (2 of 7)

• Compute signature hash message, encrypt (RSA)
  with Alices private key
• SIG Ersa(KAs, SHA1(M))
• Compress and encrypt M
• C Eidea-cbc(k, IV, zlib(M))
• Encrypt the session key with each recipients
  (Bob, Alice), RSA public key
• Ersa(KBp, k) Ersa(KAp, k)

45
PGP e-mail Alice to Bob (3 of 7)

• Assemble a multipart nested message
• lt ltE(KBp, k), E(KAp, k)gt,
• ltidea, IV, zlib, Cgt,
• lt'rsa', H(KAp), sha1, SIG gt gt
• ascii-encode the result, e-mail it, and archive
  it.

46
PGP e-mail 4 Bob receiving

• Bob locates his copy of the session key, decrypts
  it with his private RSA key
• k Drsa(KBs, ...)
• Bob decrypts ciphertext, decompresses it
• M Expand( Didea-cbc(k, IV, C) )
• Bob checks the signature, using the hash
  algorithm and Alices public key KAp
• SHA1(M) ? Drsa(KAp, SIG)

47
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

48
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 Andersons attack. Dont 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

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

50
Digital Envelopes reprise

• Tweak our our PGP example
• put Alices 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 Microsofts Encrypting File
  System
• Recent service packs add AES cipher

51
Passphrase protection how

• Alice chooses a secret passphrase
• 4-10 words, with at least 20 good characters
• Run the encryption by
• Pick a random seed and cipher IV
• Derive K from HMAC(seed, SHA1, passphrase)
• C Ecbc(K, IV, M)
• Result is ltseed, IV, Cgt
• K isn't stored! lost passphrase lost M
• Securely erase M, K
• Disk blocks, memory, swap space, file system
  slack space,

52
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

53
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
• lt blob, ltalgorithm, signaturegtgt, with blob
• ltversion, serialNumber, algorithm,
• issuer, validity_period, subject_name,
  subject_public_key, gt
• How you identify them
• Certificate ltissuer, serial_numbergt
  (Theresa)
• Subject ltsubject_name, public_keygt
  (Alice, Bob)

54
Digital Certificates CA (2 of 4)

• Certificates are created when a subject requests
  a Certificate Authority (CA) to sign a ltname,
  public key, gt 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)

55
Certificates 3 chains and uses

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

56
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 ltissuer, serial_number, revoke_timestampgt
• PKIX group may define on-line revocation
• The certificate user should check the entire
  chain for revocations!
• Which is really hard, and really slow

57
Public Key trust models

• If Alice doesnt know Bob, they need Theresa to
  introduce them.
• 3 typical models
• Centralized Theresa holds everyones keys
• Kerberos key distribution center (KDC)
• Hierarchical shes a root certificate authority
• TLS, S/MIME, SSH
• Distributed Alice and Bob happen to trust her
• PGP, SSH, Thawte e-mail user names

58
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

59
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 dont understand whom they are trusting
• Most e-commerce sites look like man-in-the-middle
  attacks
• Commercial roots charge high prices

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

61
Distributed trust PGP

• Example web of trust
• Alices 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

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

63
TLS record protocol

• Alices record protocol takes messages to be
  transmitted, fragments them into blocks of 214
  bytes, compresses, applies an HMAC, encrypts,
  and sends
• A record can contain multiple messages
• the usual crypto components
• Bobs record protocol receives, decrypts,
  verifies, decompresses, and reassembles

64
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

65
TLS Handshake 1 of 2

• A-gtB client hello
• ltversion, timestamp, client random, session id,
  ltlist of cipher suitesgt, ltlist of compressionsgtgt
• B-gtA server hello
• ltselected_version, server_timestamp,
  server_random, selected_session,
  selected_cipher_suite, selected_compressiongt
• ltserver certificategt?
  (usual)
• ltserver key exchangegt?
  (Diffie-Hellman)
• ltclient certificate requestgt?
  (authenticate client)

66
TLS Handshake 2 of 2

• A-gtB client finished
• ltcertificategt?
  (if server requested)
• ltClient Key Exchangegt
  (required)
• ltCertificate Verifygt? (demonstrate client
  secret key)
• change cipher spec
• ltfinishedgt (repeat parameters
  under cipher)
• B-gtA server finished
• change cipher spec
• ltfinishedgt (repeat parameters
  under cipher)
• Now application messages start

67
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 264 bytes

68
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 currentpending
• initialize pending before using it
• TLS bootstraps with current ltnull,null,nullgt

69
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

70
TLS key exchange

• Shared Pre-master-secret is from one of
• Diffie-Hellman key exchange
• Client secret sent under servers certificate
  public key
• Kerberos (see RFC 2712)
• Joint master secret computed as
• PRF(pre-master-secret, master secret,
  client_random server_random)

71
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
• Were skipping the 40-bit export degradation
  details

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

73
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

74
SSH v2 some details

• packets ltpayload, random padding, MACgt
• 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

75
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

76
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

77
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

78
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

79
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 (PKCS7) format, or multipart MIME

80
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

81
Guidance

• Part three

82
Equivalent Key lengths?
83
Safe key lengths review in 2007

• symmetric block cipher keys 128 bit
• 14 more symmetric bits 20 years of Moores 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)

84
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 Alices computer
• log her credit card number, passphrases,
• break into Bobs server, steal his entire DB
• break into a processing firm, steal 5M cards (Feb
  2003)

85
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

86
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

87
One time pad snake oil

• Purveyors invariably deviate from OTP
• Reuse the random key bits.
• but two time pads are worthless
• Victor will xor the two messages, removing the
  key.
• (the xord plaintext has enough redundancy to
  break)
• Have psuedo-random key bits
• Thats an ordinary stream cipher
• and probably a really bad one, too
• (a popular variable size key stream cipher is RC4)

88
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 lt 7.1, no unauthorized ADK attacks
• Get rid of plaintext (Telnet, FTP, )

89
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
• Dont upload to a key server for a few months
• Do print a revocation certificate before upload

90
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

91
TLS/SSL advice

• Turn off SSLv2
• and IE should turn on TLS
• Recent codebase (OpenSSL gt 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

92
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 mans Kerberos / single sign-on
• Be wary of end-user port forwarding

93
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 youve never used
  it before
• Use tripwire for policy updates, not twadmin
• report files do not sign, do mail off-host

94
Crypto politics

• Most countries regulate crypto (US ITAR)
• Wassenaar its 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,

95
Things we didnt 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
• ...

96
For Further reference

• NIST
• http//csrc.nist.gov/
• RSA
• http//www.rsasecurity.com/rsalabs/
• Counterpane
• http//www.counterpane.com/
• This presentation
• http//www.doit.wisc.edu/lockdown/
• http//www.slh.wisc.edu/lockdown/