Crypto for Policy Staff v5

Document Sample
Crypto for Policy Staff v5 Powered By Docstoc
					        Introduction to Digital Cryptography

                   James Leinweber

                Badger Incident Response Team
              Wisconsin State Laboratory of Hygiene

Summer 2008                Crypto for Policy Staff    1
• Goal:
    – become educated lay users of cryptography implemented
      by trained professionals
• Warmup
• Part I: 8 Cryptographic primitives
    – Block ciphers, public keys, message digests, ...
• Part II: Understanding protections and protocols
         • EFS, Bitlocker, Pointsec, TLS, IPSEC, S/MIME, PGP, ...

• Part III: Some guidance on usage

Summer 2008                    Crypto for Policy Staff              2
                    Warm up

              Introduction and Notation

Summer 2008          Crypto for Policy Staff   3
              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.

Summer 2008               Crypto for Policy Staff               4
               A better (Renaissance) Cipher
 M: blaise is much harder
 C: izlali qf nfcp zezvql

•Depends on a secret key (holstein)‫‏‬
•Incorporates feedback (autokey)‫‏‬
•Ciphers the same letter differently
•“a”‫‏‬is‫‏‬weak‫ –‏‬it leaks plain and key text

 Summer 2008              Crypto for Policy Staff      5
                    Notation – persons
A is for Alice
     (sender, client)‫‏‬
B is for Bob
    (receiver, server)‫‏‬
V is for Victor
    (antagonist / villain / eavesdropper / bad guy / black hat)‫‏‬
T is for Theresa
   (a trusted third party)‫‏‬

Summer 2008                   Crypto for Policy Staff              6
                       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
[ ] = text slice/block,     { } = annotation

Summer 2008                  Crypto for Policy Staff   7
                       Notation - crypto
C = encrypted ciphertext of M
k, k1, k2, k3 = secret symmetric keys
E(k,M) = encrypt plaintext M via key k
         Using whatever algorithm we’re working with

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

Summer 2008                    Crypto for Policy Staff   8
               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!
    – particularly useful: certificates & HMAC's

Summer 2008                  Crypto for Policy Staff   9
              A few acronyms and sources
• PKCS Public Key Cryptography Standard (RSA Labs)‫‏‬
• NIST National Institute of Standards and Technologies
• FIPS Federal Information Processing Standard
• RFC Internet Engineering Task Force candidates for
• NSA National Security Agency

Summer 2008              Crypto for Policy Staff          10
              8 cryptographic primitives
                   (building blocks)‫‏‬

                       Part One

Summer 2008            Crypto for Policy Staff   11
      1: symmetric secret key block ciphers
    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.
    works on chunks of message, usually 64 or 128 bits
    output size of gobbledegook ~ input size of message
Summer 2008             Crypto for Policy Staff           12
              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
• 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
Summer 2008               Crypto for Policy Staff               13
               How to make a block cipher
• Claude Shannon, c. 1945
    – use multiple rounds of interleaved confusion (change bits)
      and diffusion (spread bits out)‫‏‬
• Implemention: by substitution & permutation
    – easy in either hardware or software
         • using a combination of table lookups, circular shifts, and boolean
           logic (and, or, xor)
    – secret key: creates different internal algorithm state

Summer 2008                      Crypto for Policy Staff                        14
              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 in 1997. Withdrawn!
• CAST-128                                              (RFC-2144)‫‏‬
    – 64 bit blocks, 128 bit key, 16 rounds
    – good 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 variants (key size / rounds):
          128 bit key / 10 rounds , 192 bit / 12, 256 bit / 14
Summer 2008                   Crypto for Policy Staff                      15
                  Safe variants of DES
•     DESX: E(k1, M xor k2) xor k3
    –    k2 and k3 provide pre- and post- whitening
    –    net strength ~ 2^120; 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: k3=k1
    –    If k1=k2=k3, degenerates to DES (IBM bank hardware)
    –    net strength ~ 2^96; sluggish but oddly popular

Summer 2008                 Crypto for Policy Staff             16
              2: block cipher usage modes
• What‫‏‬if‫‏‬our‫‏‬message‫‏‬isn‟t‫ 821‏‬bits?
    – Too short: pad, ideally with random bits
    – Too long: chop into multiple blocks
• Do we care about:
    – interblock feedback?              (files: yes)‫‏‬
    – error propagation?               (DVD,military radios: yes)
    – random access?                   (disk partition or DB: yes)‫‏‬
• 4-7 modes in common use
         • AES has 23 proposed modes            (NIST SP 800-38a)

Summer 2008                   Crypto for Policy Staff                 17
modes to know:                               ECB CBC CTR
ECB - electronic code book mode
    – Encrypt each block independently
        • Bad: Victor can deduce message structure, build a code book, and
          fiddle entire blocks as a man in the middle
CBC - cipher block chaining mode (feedback)‫‏‬
    – Whiten plaintext block with previous ciphertext
        • Use random bits as initialization vector for the first block
    C[j] = E(k, M[j] xor C[j-1])            M[j] = D(k, C[j]) xor C[j-1]
CTR - counter mode (random access)‫‏‬
    – Encrypt the position, xor with the data (stream cipher)‫‏‬
    C[j] = M[j] xor E(k, j)                 M[j] = C[j] xor E(k, j)‫‏‬
Summer 2008                      Crypto for Policy Staff                     18
               Why you care about the mode

    Original         block cipher, ECB mode          CBC mode

Summer 2008                Crypto for Policy Staff              19
              avoiding the ECB mode break
• don't use ECB
   – use a real NIST mode, CBC by default
        • unless you need random access

• compress before encrypting
   – e.g. on small files or messages
   – reduced redundancy = increased entropy
• use a bigger block size: 128 bits
   – 64 bits is now too small
        • 64 bit keys can be brute forced
        • Don't want to enable other classes of attacks based on trying all
          possible plaintexts instead
Summer 2008                      Crypto for Policy Staff                      20
   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 = g^w mod p is easy
        z = 2^4 mod 11 … z = 5
   Inverse, finding w given z, g, p is hard
        3 = 2^ w mod 11 … w = ?

Summer 2008                      Crypto for Policy Staff
               Diffie-Hellman details
1. start: large prime p, generator g
   1 < g < p. These can be public, and can be reused.
2. Alice: pick x,   send A = g^x mod p
   picks a random x, computes A, sends <A,p,g> to Bob.
     X is secret, Message <A,p,g> is unencrypted.
3. Bob: pick y,     send B = g^y mod p
   picks a random secret y, computes B , sends B to Alice.
4. Both: compute      S = g ^ (x*y) mod p
   Alice: S=B^x mod p.       Bob: S=A^y mod p.
Summer 2008              Crypto for Policy Staff         22
               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
• Needs a one way trapdoor function
    – Something easy to compute but hard to invert, unless you
      possess an extra secret

Summer 2008               Crypto for Policy Staff            23
                      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

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

Summer 2008                      Crypto for Policy Staff                         24
              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
Summer 2008              Crypto for Policy Staff        25
              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

Summer 2008                    Crypto for Policy Staff       26
                   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
    – not susceptible to quadratic number sieve (factoring)‫‏‬

Summer 2008                   Crypto for Policy Staff          27
              5: cryptographic hash functions
• Also known as message digest algorithms
    – E.g. MD5, SHA-1, Haval, RIPEM-160, SHA-256, ...
• Design goals:
    – fast, fixed size output, one-way (exponential work to
         • NB: CRC32 flunks all the crypto properties
• Used for:       identifying blob contents
    – messages, files, IP packets, PGP keys, certificates ...
• hash size should be 2x block cipher key size.
    – the birthday attack brute forces an N-bit hash function
      in only sqrt(2^N) average work factor (operations)‫‏‬
Summer 2008                     Crypto for Policy Staff         28
              Example Message Digests
• Obsolete:
    – MD5: 128 bits                                   (RFC 1321)‫‏‬
         • Derived from the RC4 stream cipher; broken
    – SHA1: 160 bits                                  (FIPS 180-1)‫‏‬
         • An NSA tweak of SHA0, a stronger cousin of MD5
         • weakening rapidly; NIST will withdraw it in 2010
• Current:
    – SHA-256, SHA-384, SHA-512
         • NIST designs for use with AES block ciphers
• Future: NIST opened a design competition 10/2007
Summer 2008                 Crypto for Policy Staff                   29
                         lifecycle of a hash function
 Stage             Expert Reaction           Programmer Reaction               Slashdot Reaction
 Initial Proposal Skepticism                 wait for experts before adding to SHA-what?
 Peer Review       moderate effort to        adventurous use for specific      name-dropped at cocktail parties
                   break for easy pub        purposes

 General           serious attacks;          even Microsoft is using it        flame anyone suggesting it may be
 Acceptance        (international fame!)                                       broken in our lifetime
 Minor             turgid pre-prints; call   start hunting replacements        compare complexity to number of
 Weakness          for new hashes                                              protons in universe

 Serious           tense CRYPTO rump migrate to new hash functions             point out that no actual collisions
 Weakness          sessions; full break      immediately, where necessary      have been found
                   considered inevitable
 First collision   uncork champagne;         compare colliding inputs at co-   but it's really the second pre-image
                   peruse details            workers computer                  attack that counts
 easy PC           how adorable. busy        send each other colliding X.509 we always knew it would be broken
 collisions        on new hashes             certificates as pranks
 hand collisions fun party trick for next boggle                               try to remember doing long division
                   faculty mixer                                               by hand

Summer 2008                                         Crypto for Policy Staff                                           30
                           6: HMAC
• Keyed hash based message authentication code
  (RFC 2104)‫‏‬
    – detects most 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
Summer 2008                 Crypto for Policy Staff        31
              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
• RSA example: (PGP, rfc2437, PKCS#1, X9.31)‫‏‬
    – Alice: send      SIG =         E(K{As}, H(M))‫‏‬
    – Bob: compare H(M) =? D(K{Ap}, SIG)‫‏‬
• Skipping DSA and Elliptic curve details today
Summer 2008                 Crypto for Policy Staff    32
    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
• 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

Summer 2008                 Crypto for Policy Staff                33
  A good CPRNG is very important
• 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
    – older PkZip archives with 3+ files
    – Inadequate Debian Linux OpenSSL seeding
• linear congruential is not a CPRNG
                        Y = a * X + b mod N
Summer 2008                   Crypto for Policy Staff      34
              Summary: crypto primitives
• 5 basic primitives
    – Symmetric secret key block ciphers (3DES,‫‏‬AES,‫‏)…‏‬
    – Diffie-Hellman key exchange
    – Public key encryption (RSA, ElGamal, Elliptic)‫‏‬
    – Message digest / hash functions (SHA-256,‫‏)…‏‬
    – Cryptographic psuedo random number generators
• 3 more things we built from those:
    – Block cipher usage modes (CBC, CTR)‫‏‬
    – HMAC                  (from hash + secret key + usage)‫‏‬
    – Digital signatures                    (from hash + public key)‫‏‬
Summer 2008                Crypto for Policy Staff                 35
   Understanding Protections and Protocols

                    Part two

Summer 2008        Crypto for Policy Staff   36
               Digital Envelope Technique
• Protect the data using a block cipher & mode
    – Using a new, randomly generated block cipher key
• Encrypt the block cipher key using a public key algorithm
  and your public half key
    – Multiple times to multiple public keys, typically
         • Required for multiple recipient encrypted e-mail
         • Desired for data recovery scenarios

• Used universally for offline algorithms
    – EFS, Bitlocker, PGP, S/MIME, ...
         • EFS: DESX/cbc cipher, RSA pubkey/RSA sig, SHA1 hash
         • S/MIME v3: 3DES/cbc, ElGamal pubkey, DSA sig, SHA1
Summer 2008                     Crypto for Policy Staff          37
          Digital Envelope: primitive roles
• Block cipher in CBC (file) or CTR (disk) mode
    – Strong and fast: protects the message
    – Block cipher key, block cipher initialization vector, padding,
      intermediate values, ...
• Hash functions
    – digest of message (if signed)‫‏‬
    – identification of public half keys
• Public key algorithms
    – encrypt block cipher key, sign message hash
Summer 2008                  Crypto for Policy Staff              38
    Digital envelope: crypto advice reprised
• Compressing plaintext files improves crypto strength
• 100% of current 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
• remember: public keys are slow, weak, and long-lived
    – so public keys are much longer than block cipher keys
         • 128 bit block key needs a 2048 bit public key
    – we only use public keys on small, random things:
                 session keys, message hashes
Summer 2008                   Crypto for Policy Staff            39
           Passphrase protection:                  how
1.   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)‫‏‬
         • Probably iterated a few hundred times
     –   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
Summer 2008                Crypto for Policy Staff             40
              Passphrase protection:                  why
• Needed to protect private half keys
    – SSH,‫‏‬Digital‫‏‬Certificates,‫‏‬EFS,‫‏‬PGP,‫‏‏…‏‬
• Other uses (PGP):
    – file encryption without public keys
    – broadcast e-mail
• Related uses: Unix password storage, obfuscated DB
• Victor will try to brute force the passphrase
    – 20 characters of monocase English words is only 26 bits of
Summer 2008                 Crypto for Policy Staff           41
                       digital certificates
• bind 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, …>

• Certificates are signed by other certificates
    – Root certificates are self-signed
         • Hopefully by a trusted authority
Summer 2008                     Crypto for Policy Staff                   42

    – Beware of expired or revoked signatures
                  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

Summer 2008                    Crypto for Policy Staff   43
              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
         • E.g. v4 kadmind compromise at U. of Uppsala
    – Microsoft Windows domain controllers are scary compared
      to a classic MIT style KDC

Summer 2008                    Crypto for Policy Staff          44
                   Hierarchical trust – PKI
• Pro:
    – Can work well across cooperating organizations
• Con:
    – Infrastructure part is still dicey
         • Too many roots, e.g. 150 by IE6
         • Revocations are highly problematic
         • Lots of sloppiness with constraints (verified purposes)
    – Users‫‏‬don‟t‫‏‬understand‫‏‬whom‫‏‬they‫‏‬are‫‏‬trusting
         • Most e-commerce sites look like man-in-the-middle attacks
    – Commercial roots charge absurdly high prices
Summer 2008                      Crypto for Policy Staff               45
              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?

Summer 2008                Crypto for Policy Staff            46
                Distributed trust – PGP
• Example: web of trust
      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
Summer 2008                Crypto for Policy Staff       47
Online encryption: TLS SSH IPSEC WPA2
• Details vary, but crypto substrate is identical
    – Shared secret, block cipher, HMAC integrity
    – Used to wrap actual higher level data
         • HTTP, IMAP, SMTP, terminal, X, TCP, UDP
    – Modular frameworks with plugable
• Alice and Bob negotiate a mutually acceptable
  cipher suite
Summer 2008              Crypto for Policy Staff    48
    – rfc3268: tls_dhe_rsa_with_aes_128_cbc_sha

              Part three

Summer 2008   Crypto for Policy Staff   49
        Equivalent key lengths versus time
  symmetric elliptical / hash public key       year
      40            80            99           1961
      56           112           526           1982
      64           128           745           1994
      80           160           1536          2010
     128           256           2048          2013
     256           512          15424          2030+

Summer 2008          Crypto for Policy Staff           50
• 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 will soon be 2048/224)
    – Elliptic curve public keys: 224 bit
• The state of the (civilian) break:
    – Symmetric: 65 bit RC5 in 2002
    – Elliptic:    109 bit in 2002
    – RSA:         640 bit in 2005 (sort of 700 in 2007)‫‏‬
Summer 2008                 Crypto for Policy Staff                    51
                            Keys & risks
• Long keys don't make you safe
    – safety depends on key handling, environment
    – still, 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 (TJ Max)
         • break into a processing firm, steal 5M cards (Feb 2003)

Summer 2008                      Crypto for Policy Staff             52
                               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
         • usually accompanied by an obsession with exaggerated key sizes
    – Touting one time pads

Summer 2008                      Crypto for Policy Staff                    53
              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
Summer 2008               Crypto for Policy Staff           54
                    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 xor’d plaintext has enough redundancy to break)

       Have psuedo-random key bits
    •     That‟s‫‏‬an‫‏‬ordinary‫‏‬stream‫‏‬cipher‫‏‬
          •   … and probably a really bad one, too
          (RC4 is a popular real stream cipher, with variable key size)

Summer 2008                       Crypto for Policy Staff                 55
                   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 2009: 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
• only (export) sign keys you have verified in-person

Summer 2008                 Crypto for Policy Staff     56
              xkcd # 364

Summer 2008    Crypto for Policy Staff   57
                        TLS/SSL advice
• Turn off SSLv2
   – and older IE's should turn on TLS
• Recent codebase
• 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

Summer 2008                     Crypto for Policy Staff
                        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

Summer 2008                Crypto for Policy Staff   59
                            HIDS advice
• You do want some host intrusion detection
    – Tripwire, OSSEC, AIDE, Samhain, ...
• Do improve the configuration
    – Tripwire: private tmp directory, syslog reporting
• Do tune the policy file
    – Ok‫‏‬to‫‏‬start‫‏‬with‫‏‬a‫‏‬default‫‏‬if‫‏‬you‟ve‫‏‬never‫‏‬used‫‏‬it‫‏‬before
    – Don't gratuitously reinitialize the signature DB
         • Use tripwire for policy updates, not twadmin
• report files: do not sign, do mail off-host

Summer 2008                     Crypto for Policy Staff           60
               Digital Signatures at UW
• Vendor security bulletins are signed by PGP
   – Verify those before following their advice
   – Microsoft, Apple, Redhat, Cisco, Oracle, ...
• For important e-mail, use DoIT personal certificates and
   – Store the certificate private key on an Aladdin eToken
• A growing need for signatures (with external timestamps)
  on digital research documents

Summer 2008                Crypto for Policy Staff            61
       Encrypting sensitive data: in motion
• Avoid plaintext protocols ...
   – Telnet, FTP, SMTP, IMAP, LDAP, rsync, CIFS, X, ...
• ... unless wrapped in crypto tunnels
• Use VPN's
   – Cisco/DoIT, or private
• Future problem points – things getting too weak
   – Kerberos only protects authentication, and only by DES
   – Microsoft PPTP encryption is only 40-bit
   – WEP is easily broken (but WPA2 is OK)‫‏‬
Summer 2008                   Crypto for Policy Staff         62
       Encrypting sensitive data:                          at rest
• Password vaults can be encrypted
   – Apple keychain, Pwsafe, ...
• Database columns can be encrypted
   – Though oracle keeps changing its API
• Files can be encrypted
   – PGP, S/MIME, Microsoft EFS, Apple FileVault, ...
        • Issue: business processes need ADK's for continuity

• Disk partitions can be encrypted
   – Microsoft Bitlocker, Mcafee safeboot, truecrypt, ...

Summer 2008                     Crypto for Policy Staff              63
                 Multifactor authentication
• Needs 2+ of
   – Something you have
        • Mag stripe card, number token, smart card, USB certificate store, one
          time password list, digital certificate, ...
        • These always have crypto inside
   – Something you are (ID only)‫‏‬
        • Fingerprint, IRIS pattern, voiceprint, ...
   – Something you know
        • Passphrase, PIN, password

• Required for LOA 3 applications, PCI-DSS

Summer 2008                       Crypto for Policy Staff                   64
                          Crypto politics
• Most countries regulate crypto (US: ITAR)‫‏‬
    – Wassenaar:‫‏‬it‟s‫‏‬dual‫‏‬use‫‏/‏‬munition‫‏‬tech
    – key escrow controversies (US, UK)‫‏‬
         • 80 bit Skipjack reduced to 64 by a 16 bit 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, …

Summer 2008                     Crypto for Policy Staff      65
                    crypto politics 2
• US export restrictions exported R&D too
   – Sun imported Solaris crypto from Russia
   – OpenSSH done in Canada
   – GnuPG done in Germany
• Scary (for the NSA): Chinese attacks on SHA1
• current crypto, e.g. PGP, is strong enough ...
   – 1999: FBI put keystroke logger on N. S. Scarfo, 1999
   – Secret Service uses a grid for guessing passphases
   – 2007: Boucher case in Vermont has PGP vs 5th amend

Summer 2008               Crypto for Policy Staff           66
• Elliptic curve public key / signing details.
    – Which will probably be the favorite by 2013
• 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

• ...

Summer 2008                      Crypto for Policy Staff   67
                       Remember ...
• beware the man in the middle
• your weakest link usually isn't the crypto
   – attackers will instead go after the end points, the key
     handling, the side channels, the CPRNG
• key handling
   – only use pubkeys on hashes and random secret keys
   – ordinary security: good passphrase on a carefully
     maintained online system. medium security: +sneakernet to
     offline-only system. high security: + 24/7 armed guards and
     key splitting.

Summer 2008                 Crypto for Policy Staff            68
                 for further reference
• Bruce
• This presentation


Summer 2008               Crypto for Policy Staff   69

Shared By: