Docstoc

Crypto for IT Staff

Document Sample
Crypto for IT Staff Powered By Docstoc
					                                 Goals
• Lay out some basic crypto concepts
     – only occasional formulas

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


2/13/08             Crypto for IT Staff   FDLLUG      1
                           Non Goals
• We won‟t become either cryptographers
  (designers) or cryptanalysts (breakers)
• Not a tutorial on the protocols & apps
     – our focus will be on the crypto only

• Skipping or simplifying many implementation
  details
• Hardly any history
• No proofs

2/13/08             Crypto for IT Staff   FDLLUG   2
                                   Outline
• Warmup
          • Two cipher examples, tonight’s notations

• 8 Cryptographic primitives
          • Block ciphers, public key algorithms, …

• Decomposing applications and protocols
          • PGP, Certificates, TLS (SSL), SSH, IPSEC,…

• Guidance
          • key lengths, snake oil, trust models, do’s and don’ts, …


2/13/08                 Crypto for IT Staff      FDLLUG                3
                     Warm up


          Introduction and Notation




2/13/08     Crypto for IT Staff   FDLLUG   4
              An (old) Cipher example
     M: I came, I saw, I conquered.
     C: L fdph, L vdz, L frqtxhuhg.

•Start with a plaintext message (M), encrypt (via a
monoalphabetic circular shift), obtaining obfuscated
ciphertext (C).
•Decrypt the ciphertext C back to plaintext M via the
opposite shift

•Very easily broken, via letter frequency statistics plus the
word boundaries.

2/13/08            Crypto for IT Staff   FDLLUG                 5
           A better (Renaissance) Cipher
 M: blaise is much harder
 K: HOLSTE IN BLAI SEISMU
 C: izlali qf nfcp zezvql

•Depends on a secret key (holstein)
•Incorporates feedback (autokey)
•Ciphers the same letter differently
      •E.g. „h‟ becomes p,z; „z‟ comes from l,h,r
•“a” is weak – it leaks plain and key text

 2/13/08          Crypto for IT Staff   FDLLUG      6
                    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)

2/13/08              Crypto for IT Staff   FDLLUG              7
                   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


2/13/08           Crypto for IT Staff       FDLLUG         8
                       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 k
          Using whatever algorithm we’re working with

D(k,C) = decrypt ciphertext C via key k
2/13/08                Crypto for IT Staff    FDLLUG    9
                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

2/13/08                Crypto for IT Staff        FDLLUG   10
            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
    standards (“Request for Comments”)

• NSA National Security Agency aka “No Such Agency”




2/13/08             Crypto for IT Staff   FDLLUG           11
          8 cryptographic primitives
               (building blocks)

                          Part One




2/13/08       Crypto for IT Staff    FDLLUG   12
          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
2/13/08             Crypto for IT Staff   FDLLUG           13
              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
2/13/08              Crypto for IT Staff   FDLLUG                14
               How to make a block cipher
• use multiple rounds of interleaved confusion
  and diffusion
     – Claude Shannon, c. 1945
     – cryptographically strong
     – easy in either hardware or software
          • confusion (change bits) and diffusion (spread bits out) can be
            done with a combination of table lookups, circular shifts, and
            boolean logic (and, or, xor)
     – secret key is used to create internal algorithm state


2/13/08                 Crypto for IT Staff      FDLLUG                 15
           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
2/13/08               Crypto for IT Staff      FDLLUG             16
                     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


2/13/08                 Crypto for IT Staff    FDLLUG              17
              2: block cipher usage modes
• What if our message isn‟t 128 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)
2/13/08                 Crypto for IT Staff        FDLLUG          18
  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


2/13/08             Crypto for IT Staff   FDLLUG               19
 Mode CBC: Cipher Block Chaining
• Start, block 0: xor a random initialization vector
     – Unlike key, IV is not secret
     C[0] = E(k, M[0] xor IV)                  M[0] = D(k, C[0]) xor IV
• Middle, blocks j: xor prior ciphertext
     C[j] = E(k, M[j] xor C[j-1])              M[j] = D(k, C[k]) xor C[j-1]
• 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
2/13/08                  Crypto for IT Staff         FDLLUG               20
                Why you care about the mode




     Original         block cipher, ECB mode      CBC mode




2/13/08              Crypto for IT Staff       FDLLUG        21
           avoiding the ECB mode break
• don't use ECB
    – use CBC if you don't have a better idea

• compress before encrypting
    – reduces redundancy = increases entropy

• use a bigger block size: 128
    – 64 bits is now too small
    – block size matters just as much as key size!



2/13/08             Crypto for IT Staff   FDLLUG     22
   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 = ?
2/13/08                Crypto for IT Staff    FDLLUG
                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.
• assume Victor gets p,g,A,B - he still can‟t get S
2/13/08             Crypto for IT Staff       FDLLUG      24
               4: Public Key: proposed
Diffie & Hellman also analyzed the possibilities of
  asymmetric cryptosystems
• Alice would use one key to encrypt, Bob would
  use a different key to decrypt.
• Allows 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

2/13/08            Crypto for IT Staff   FDLLUG           25
                      Public Key: realized
• A flurry of candidates for one way trapdoor
  functions were proposed. Three survived:
     – Factoring, discrete logarithms, elliptic curves
          • It’s all number theory: modular exponentiation in finite fields
            and groups

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

2/13/08                 Crypto for IT Staff      FDLLUG                  26
             Public key: RSA (factoring)
• Choose p, q large random primes. Let N=p*q
     – p and q are 350-2000 bits (10^155-10^600)
• Choose e relatively prime to (p-1)*(q-1)
     – e can be reused; 65537 is popular.
• Compute d = 1/e mod (p-1)*(q-1)
• Private key is <d>,               public key is <N,e>
     – Alice discards p,q, or keeps them secret with d
• Encrypt: C = M^e mod N
• Decrypt: M = C^d mod N
2/13/08             Crypto for IT Staff      FDLLUG       27
             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

2/13/08             Crypto for IT Staff        FDLLUG        28
                 Pubkey: Elliptic curves
• Elliptic curve cryptography is based on the
  integer solutions to equations of the form:
                Y^2 = X^3 +a*X + b
     (coefficients a and b are from a finite field)

• The trapdoor problem is scalar multiplication, g
  = s * f, for curves f,g
• Not yet widely used; details omitted.
• Appeal is shorter key sizes
     – not susceptible to quadratic number sieve (factoring)
2/13/08              Crypto for IT Staff    FDLLUG             29
          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
       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, …


2/13/08             Crypto for IT Staff   FDLLUG                 30
                 Two obsolete hashes
• MD5: 128 bits                              (RFC 1321)
     – Derived from the RC4 stream cipher.
     – completely 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
• 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)
     – NIST now has SHA-256, SHA-384, SHA-512 for AES.
2/13/08             Crypto for IT Staff   FDLLUG             31
          lifecycle of a hash function




2/13/08        Crypto for IT Staff   FDLLUG   32
                            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
2/13/08            Crypto for IT Staff   FDLLUG         33
           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.
RSA example: (PGP, rfc2437, PKCS#1, X9.31)
     – Alice: send        SIG =            E(K{As}, H(M))
     – Bob: compare H(M) =? D(K{Ap}, SIG)
2/13/08              Crypto for IT Staff           FDLLUG   34
          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


2/13/08             Crypto for IT Staff            FDLLUG                 35
                NIST DSA, 2 of 3: verifying
Bob:
          Receive message M with signature <r,s>
          obtain public DSA key of Alice: <p,q,g,y>

Compute:
          w = 1/s mod q
          u1 = (H(M) * w) mod q, u2 = (r*w) mod q
          v = ((g^u1 * y^u2) mod p) mod q

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


2/13/08                Crypto for IT Staff   FDLLUG   36
              NIST DSA, 3 of 3: comments
• DSA annoyances
     – 1024 bit p / 160 bit q is already too small
          • NIST is preparing 2048 / 224
     – 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)
2/13/08                Crypto for IT Staff    FDLLUG        37
     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
2/13/08             Crypto for IT Staff   FDLLUG                38
   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
     – older PkZip archives with 3+ files

2/13/08               Crypto for IT Staff      FDLLUG       39
             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: ECB, CBC, …
     – HMAC                      (from hash + secret key + usage)
     – Digital signatures                 (from hash + public key)
2/13/08             Crypto for IT Staff       FDLLUG             40
   Decomposing Applications and Protocols


                           Part two




2/13/08       Crypto for IT Staff     FDLLUG   41
             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 (<K{As}, K{Ap}>), 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
2/13/08                 Crypto for IT Staff   FDLLUG   42
    PGP e-mail: Alice to Bob (2 of 7)
•         Compute signature: hash message, encrypt
          (RSA) with Alice‟s private key:
             SIG = E{rsa}(K{As}, SHA1(M))
         Compress and encrypt M
           C = E{idea-cbc}(k, IV, zlib(M))
•          Encrypt the session key with each recipients
          (Bob, Alice), RSA public key:
           E{rsa}(K{Bp}, k)          E{rsa}(K{Ap}, k)


2/13/08               Crypto for IT Staff      FDLLUG     43
    PGP e-mail: Alice to Bob (3 of 7)
         Assemble a multipart nested message:
    < <E(K{Bp}, k), E(K{Ap}, k)>,
      <„idea‟, IV, „zlib‟, C>,
      <'rsa', H(K{Ap}), „sha1‟, SIG > >
         ascii-encode the result, e-mail it, and archive it.




2/13/08                Crypto for IT Staff   FDLLUG        44
               PGP e-mail 4: Bob receiving
         Bob locates his copy of the session key,
          decrypts it with his private RSA key:
                    k = D{rsa}(K{Bs}, ...)
         Bob decrypts ciphertext, decompresses it
             M = Expand( D{idea-cbc}(k, IV, C) )
         Bob checks the signature, using the hash
          algorithm and Alice‟s correct public key K{Ap}:
             SHA1(M) =? D{rsa}(K{Ap}, SIG)
2/13/08               Crypto for IT Staff   FDLLUG      45
              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

2/13/08             Crypto for IT Staff   FDLLUG        46
             PGP mail 6: crypto remarks
• Compressing plaintext 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
     – we only use public keys on small, random things:
                session keys, message hashes

2/13/08               Crypto for IT Staff   FDLLUG                47
                            PGP: v4 keys
• Our example used v3 RSA Legacy keys
     – A single RSA key pair was used for both encryption
       and signing
     – Symmetric block cipher was always IDEA
• 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, …

2/13/08                  Crypto for IT Staff        FDLLUG   48
              Digital Envelopes : reprise
• Tweak our our PGP example:
     – put Alice‟s key into a digital certificate
     – make Bob the file system recovery agent
     – let the message M be a disk file
     – Choose DESX as the block cipher

• We'd be very near to Microsoft‟s windows 2000
  Encrypting File System
     – service packs have added AES as cipher choice


2/13/08              Crypto for IT Staff    FDLLUG     49
                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)
     –      C = E{cbc}(K, IV, M)
3.        Result is <seed, IV, C>
     –      K isn't stored!     lost passphrase = lost M
4.        Securely erase M, K
     –      Disk blocks, memory, swap space, file system slack
            space, …
2/13/08                  Crypto for IT Staff     FDLLUG          50
             Passphrase protection: why
• Needed to protect private keys
     – SSH, Digital Certificates, EFS, PGP, …

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

• Victor will try to brute force the passphrase
     – 20 characters of monocase English words is only 26
       bits of entropy


2/13/08             Crypto for IT Staff      FDLLUG         51
                 digital certificates: (1 of 4)
• binds a distinguished name to a public key with
  a digital signature
     – X.509 v3 / RFC 3280 (April 2002)
     – Roughly, a nested structure
     < blob, <algorithm, signature>>, with blob
          <version, serialNumber, algorithm,
           issuer, validity_period, subject_name, subject_public_key, …>

• How you look them up:
     Certificate: <issuer, serial_number>                      (Theresa)
     Subject: <subject_name, hashed public_key>              (Alice, Bob)
2/13/08                  Crypto for IT Staff      FDLLUG                   52
             Digital Certificates: CA (2 of 4)
• Certificates are created when a subject requests
  a Certificate Authority (CA) to sign a <name,
  public key, …> blob.
     – The CA must to verify:
          • possession of private key, appropriate … stuff for name
• Certificate subjects (names) vary
     – email address, DNS name, IP address, …
• Anyone can be a CA
     – Windows, OS-X, and OpenSSL all issue certificates
                  (Trust issues coming up soon)
2/13/08                 Crypto for IT Staff     FDLLUG                53
             Certificates 3: chains and uses
• Alice‟s certificate is signed by a chain of 0 or more
  intermediate certificates
• The certificate from the last intermediate CA is signed by
  a root certificate
     – a root certificate is one that signed itself
• Constraint fields control permitted uses
          • Encryption, message signing, code signing, certificate
            signing
          • format is extensible; if you don't recognize a field, you ignore
            it. Unless it's flagged critical – reject the certificate.

2/13/08                 Crypto for IT Staff       FDLLUG                  54
               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!
2/13/08            Crypto for IT Staff   FDLLUG            55
                  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

2/13/08                Crypto for IT Staff     FDLLUG     56
              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 domain controllers are scary
       compared to a classic MIT style KDC

2/13/08                Crypto for IT Staff    FDLLUG         57
                    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
     – Users don‟t understand whom they are trusting
          • Most e-commerce sites look like man-in-the-middle attacks
     – Commercial roots charge high prices
2/13/08                  Crypto for IT Staff       FDLLUG               58
              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?

2/13/08                 Crypto for IT Staff   FDLLUG              59
                 Distributed trust – PGP
• Example: web of trust
     Alice‟s key is signed by Theresa, whose key was signed
       by Tori, signed by Talia – and Bob trusts all three.
• Pro:
     – distributed, end users control it, in live use
     – Infrastructure is a ring of keyservers – cheap!
• Con:
     – There may not be any trust path
     – Be wary of fake keys and junk signatures
     – Requires highly trained and careful users
2/13/08              Crypto for IT Staff   FDLLUG        60
                               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, …
2/13/08                 Crypto for IT Staff       FDLLUG                 61
                 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


2/13/08            Crypto for IT Staff   FDLLUG   62
                 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




2/13/08            Crypto for IT Staff   FDLLUG   63
              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)
     <client certificate request>?         (authenticate client)
2/13/08              Crypto for IT Staff   FDLLUG              64
                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
2/13/08               Crypto for IT Staff        FDLLUG              65
                 TLS: connection state
• 4 pieces
     – Current and pending states
     – Independently for read and write directions
• Each piece contains 3 algorithms , along with
  their parameters (e.g. block cipher CBC IV)
     – MAC, compression, block cipher
• Change_cipher_state sets current=pending
     – initialize pending before using it
     – TLS bootstraps with current = null-null-null
2/13/08              Crypto for IT Staff    FDLLUG    66
               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

2/13/08             Crypto for IT Staff   FDLLUG       67
                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


2/13/08               Crypto for IT Staff   FDLLUG   68
                   TLS: key exchange
• Shared Pre-master-secret is from one of
     – Diffie-Hellman key exchange
     – Client secret sent under server‟s certificate public key
     – Kerberos (see RFC 2712)

• Joint master secret computed as:
     PRF(pre-master-secret, „master secret‟, client_random
      || server_random)
     – HMAC (in the record protocol) prevents MITM
       corruption; these new nonces prevent replay attacks

2/13/08             Crypto for IT Staff   FDLLUG              69
               TLS: cipher suites
• One mandatory
     TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

• Other RFCs add more, e.g. from #3268:
     TLS_DHE_RSA_WITH_AES_128_CBC_SHA

• We‟re skipping the 40-bit export degradation
  details




2/13/08        Crypto for IT Staff   FDLLUG      70
                         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)


2/13/08                Crypto for IT Staff   FDLLUG       71
                     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




2/13/08                  Crypto for IT Staff       FDLLUG       72
                SSH v2: some details
• packets <payload, random padding, MAC>
     – 1. Compress 2. Encrypt 3. HMAC 4. Pad.

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

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



2/13/08            Crypto for IT Staff   FDLLUG     73
                  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



2/13/08              Crypto for IT Staff   FDLLUG      74
                       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


2/13/08             Crypto for IT Staff   FDLLUG   75
                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 flow
     – all traffic between two hosts
     – tunnel entire subnets between gateways
2/13/08              Crypto for IT Staff   FDLLUG   76
                 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




2/13/08             Crypto for IT Staff   FDLLUG   77
                              S/MIME v3
• Digital envelope (similar to PGP e-mail)
     – public keys are in X509v3 certificates
          • might be ephemeral
     – encryption: ElGamal (optionally RSA)
     – signing: DSA (optionally RSA)
          • s/mime v2 uses only RSA
     – hash: SHA1 (optionally MD5)

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

2/13/08                Crypto for IT Staff   FDLLUG   78
                              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

2/13/08             Crypto for IT Staff     FDLLUG            79
                  Guidance


                     Part three




2/13/08   Crypto for IT Staff     FDLLUG   80
          Equivalent key lengths versus time




2/13/08           Crypto for IT Staff   FDLLUG   81
 Safe key lengths … review in 2011
• 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)
2/13/08               Crypto for IT Staff    FDLLUG           82
                             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)
2/13/08                 Crypto for IT Staff      FDLLUG               83
                                 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
2/13/08                 Crypto for IT Staff      FDLLUG                84
              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
2/13/08              Crypto for IT Staff   FDLLUG            85
                    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)

2/13/08                  Crypto for IT Staff      FDLLUG                   86
             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, …)
2/13/08                Crypto for IT Staff   FDLLUG      87
                   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

2/13/08             Crypto for IT Staff   FDLLUG         88
                 kxcd # 364




2/13/08   Crypto for IT Staff   FDLLUG   89
              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
  creating an exportable signature
     – don't upload; send it (encrypted) to the key owner

• Note: smaller keyrings perform better

2/13/08             Crypto for IT Staff   FDLLUG            90
                          PGP usage
• sign e-mail & usenet postings in-line
     – compose as plain text
     – line wrap before signing

• sign program archives detached




2/13/08             Crypto for IT Staff   FDLLUG   91
                         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
2/13/08                 Crypto for IT Staff      FDLLUG
                          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


2/13/08             Crypto for IT Staff    FDLLUG   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 you‟ve never used it
       before
     – Use tripwire for policy updates, not twadmin
• report files: do not sign, do mail off-host

2/13/08              Crypto for IT Staff   FDLLUG             94
                           Crypto politics
• Most countries regulate crypto (US: ITAR)
     – Wassenaar: it‟s dual use / munition tech
     – key escrow controversies (US, UK)
          • 80 bit Skipjack and the LEAF
• Victor is using it too
     – mafia uses PGP, botnets have code signing
• Commercial abuse
     – DCMA: block fair use / consumer rights
     – Prevent interoperability / competition
          • Inkjet cartridges, cell phone batteries, DVD, …
2/13/08                 Crypto for IT Staff     FDLLUG        95
                  crypto politics 2
• US export restrictions exported R&D too
  – Sun imported Solaris crypto from Russia
  – OpenSSH done in Canada
  – GPG 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
2/13/08 amend    Crypto for IT Staff FDLLUG                96
                   Things we didn‟t cover
• 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

• ...
2/13/08                 Crypto for IT Staff      FDLLUG   97
                       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.
2/13/08             Crypto for IT Staff   FDLLUG                98
                 for further reference
• NIST        http://csrc.nist.gov/
• RSA         http://www.rsa.com/rsalabs/
• Bruce       http://www.schneier.com/
• This presentation
     https://mywebspace.wisc.edu/jeleinwe/web



                           Questions?

2/13/08            Crypto for IT Staff   FDLLUG   99

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:10/14/2011
language:English
pages:99