Docstoc

Lecture 4 - PowerPoint 2

Document Sample
Lecture 4 - PowerPoint 2 Powered By Docstoc
					Foundations of Network and
    Computer Security

          John Black

          Lecture #12
          Oct 6th 2005


     CSCI 6268/TLEN 5831, Fall 2005
            Announcements
• Project #0 assigned today
  – Due Oct 18th in class
  – CAETE students may email project #0 directly
    to the grader,
         martin.cochran@colorado.edu
  – Non-CAETE students may NOT do this
• Quiz #2 is next class
  – I‟ll have a special OH 9:30-10:30am before
    the quiz, and (as usual) I‟ll answer email over
    the weekend
 Let‟s Sum Up From Last Time
• Symmetric Key Model
  – Encryption
     • ECB (bad), CBC, CTR
        – All these are modes of operation built on a blockcipher
  – Authentication (MACs)
     • CBC MAC, XCBC, UMAC, HMAC
• Asymmetric Key Model
  – Encryption
     • RSA-OAEP
        – Assumes factoring product of large primes is hard
  – Authentication
     • RSA signatures
        – Usually hash-then-sign
             Next Up: SSL
• Next we‟ll look at how to put all this
  together to form a network security
  protocol
• We will use SSL/TLS as our model since
  it‟s ubiquitous
• But first, we‟ll digress to talk about
  OpenSSL, and our first part of the project
  (a warm-up)
                   OpenSSL
• Was SSLeay
• Open Source
• Has everything we‟ve talked about and a lot
  more
• Most everything can be done on the command
  line
• Ungainly, awkward, inconsistent
  – Mostly because of history
  – Have fun, it‟s the only game in town
• http://www.openssl.org/
              Brief Tutorial
• This is a grad class; you can figure it out
  from the man page, but…
  – Syntax is
  % openssl <cmd> <parms>
  – cmd can be „enc‟, „rsautl‟, „x509‟, and more
  – We‟ll start with the „enc‟ command (symmetric
    encryption)
  – Let‟s look at the enc command in more detail
          OpenSSL enc command
•   openssl enc -ciphername [-in filename] [-out filename] [-pass arg] [-e] [-d] [-
    a] [-K key] [-iv IV] [-p] [-P]
•   -ciphername can be
     – des-ecb (yuk!), des-cbc (hmm), des (same as des-cbc), des-ede3-cbc, des3
       (same), aes-128-cbc, bf, cast, idea, rc5
     – Can omit the „enc‟ command if specifying these… kind of hokey
•   If you don‟t specify filenames, reads from and writes to stdin/stdout
     – Looks like garbage, of course
•   If you don‟t specify a password on the command line, it prompts you for one
     – Why are command-line passwords bad?
     – You can use environment variables but this is bad too
     – You can point to a file on disk… less bad
•   What does the password do?
     – Password is converted to produce IV and blockcipher key
                             enc (cont)
% openssl aes-128-cbc –P
enter aes-128-cbc encryption password:
   salt=39A9CF66C733597E
   key=FB7D6E2490318E5CFC113751C10402A4
   iv =6ED946AD35158A2BD3E7B5BAFC9A83EA

• salt is a random number generated for each encryption in order to
  make the key and iv different even with the same password
    – Begins to get confusing… didn‟t we just change the IV before?
    – Use this mode only when deriving a new key for each encryption
        • Eg, when encrypting a file on disk for our own use
    – If key is fixed, we specify it and the iv explicitly
        % openssl aes-128-cbc –K FB7D6E2490318E5CFC113751C10402A4 –iv
          6ED946AD35158A2BD3E7B5BAFC9A83EA
  Understanding Passwords vs. a
      Specified IV and Key
• So there are two modes you can use with enc
  – 1) Specify the key and IV yourself
     • This means YOU are in charge of ensuring the IV doesn‟t
       repeat
        – Use a good random number source or
        – Use a counter (which you have to maintain… headache!)
  – 2) Use a passphrase
     • OpenSSL uses randomness for you by generating a salt
       along with the IV and AES key
     • Passphrases are less secure (more guessable) in general
• Either way, we get non-deterministic encryption
    Passphrase-Based enc
                        Passphrase


   salt              hash function

                                iv, key (128 bits each)

                     AES-128-CBC                  plaintext



  salt              iv, ciphertext


Things to think about:
• How to decrypt?
• Is the passphrase safe even though the salt and iv are known?
            So How to Encrypt
• Let‟s encrypt the file „test‟
% cat test
hi there
% openssl aes-128-cbc -in test
enter aes-128-cbc encryption password:
Verifying - enter aes-128-cbc encryption password:
Salted__mTR&Qi¦¹K¯¿Óàg&5&kE


• What‟s up with the garbage?
   – Of course the AES outputs aren‟t ASCII!
   – Use –base64 option
                         base64
• This is an encoding scheme (not cryptographic)
  – Translates each set of 6 bits into a subset of ASCII
    which is printable
  – Makes „garbage‟ binary into printable ASCII
       • Kind of like uuencode
  –   Of course this mapping is invertible
  –   For encryption we want to do this after we encrypt
  –   For decryption, we undo this before we decrypt
  –   This is the –a flag for „enc‟ but –base64 works as well
      and is preferable
             Example: base64
• Let‟s encrypt file „test‟ again, but output
  readable ciphertext
% openssl aes-128-cbc -in test -base64
enter aes-128-cbc encryption password:
Verifying - enter aes-128-cbc encryption password:
U2FsdGVkX1/tdjfZnPrD+mSjBBO7InU8Mo4ttzTk8eY=

• We‟ll always use this option when dealing
  with portability issues
   – Like sending ciphertext over email
                    Decrypting
• The command to decrypt is once again
  „enc‟
  – This makes no sense; get used to it
  – Use the –d flag to tell enc to decrypt
  – Let‟s decrypt the string
  U2FsdGVkX1/tdjfZnPrD+mSjBBO7InU8Mo4ttzTk8eY=

  which I‟ve placed into a file called „test.enc‟
  % openssl enc -d -in test.enc
  U2FsdGVkX18FZENOZFZdYvLoqPdpRTgZw2CZIQs6bMQ=
                       Hunh?
• It just gave back the ciphertext?!
   – We didn‟t specify an encryption algorithm
   – Default is the identity map (get used to it)
   – Let‟s try again
% openssl aes-128-cbc -d -in test.enc
enter aes-128-cbc decryption password:
bad magic number


• Ok, now what‟s wrong?
    Error messages not useful
• We forgot to undo the –base64
  – The error msg didn‟t tell us that (get used to it)
  – One more try:
  % openssl aes-128-cbc -d -in test.enc -base64
  enter aes-128-cbc decryption password:
  hi there


  – It was all worth it, right?
  – Now it‟s your turn
                   Project #0
• I‟ll give you a ciphertext, you find the
  password
  – Password is a three-letter lowercase alpha
    string
  – Main purpose is to get you to figure out where
    openssl lives on your computer(s)
  – Don‟t do it by hand
  – Full description on our web page
     • Due Oct 18th, in class
           Back to SSL/TLS
• SSL
  – Secure Socket Layer
     • Designed by Paul Kocher, consulting for Netscape
• TLS
  – Transport Layer Security
     • New version of SSL, and probably what we should
       call it (but I‟m used to SSL)
• Used for web applications (https)
  – But also used many other places that aren‟t
    as well-known
                TLS – Sketch
• Let‟s start by trying to design TLS ourselves and
  see what else we‟ll need
  – This will end up being only a sketch of the very
    complex protocol TLS actually is

• We want:
  – Privacy, authentication
  – Protection against passive and active adversaries

• We have:
  – Symmetric/asymmetric encryption and authentication
  – Collision-resistant hash functions
                   A First Stab
• First we need a model
  – Client/Server is the usual one
  – Client and Server trust each other
  – No shared keys between client and server
     • Assuming a shared key is not realistic in most settings
  – Adversary is active (but won‟t try DoS)
• Server generates RSA key pair for encryption
  – pkS, skS
  – S subscript stands for “Server”
          A First Stab (cont)
• Now client C comes along and wants to
  communicate with server S
  – C sends SSL HELLO to initiate session
  – S responds by sending pkS
  – C sends credit card number encrypted with
    pkS
  – S decrypts credit card number with skS and
    charges the purchase
• What‟s wrong here?
   Our First Protocol: Problems
• There are tons of problems here
  – We don‟t know how to encrypt {0,1}*, only how to
    encrypt elements of Zn*
     • Ok, say we solve that problem (there are ways)
  – It‟s really SLOW to use RSA on big messages
     • Ok, we mentioned this before… let‟s use symmetric
       cryptography to help us
  – There is no authentication going on here!
     • Adversary could alter pkS on the way to the client
     • We‟d better add some authentication too
• Let‟s try again…
              Second Stab
• C says Hello
• S sends pkS to C
• C generates two 128-bit session keys
  – Kenc, Kmac, used for encryption and MACing
• C encrypts (Kenc, Kmac) with pkS and sends
  to S
• S recovers (Kenc, Kmac) using skS and both
  parties use these “session keys” to encrypt
  and MAC all further communication
         Second Stab (cont)
• Problems?
  – Good news: we‟re a lot more efficient now
    since most crypto is done with symmetric key
  – Good news: we‟re doing some authentication
    now
  – Bad news: Man-in-the-Middle attack still
    possible
  – Frustratingly close
    • If we could get pkS to the client, we‟d be happy
            Man in the Middle
• Let‟s concretely state the problem
  – Suppose an adversary A generates pkA and skA
  – Now S sends pkS to C, but A intercepts and sends pkA
    to C instead
  – C responds with (Kenc, Kmac) encrypted under pkA and
    sends to S
  – A intercepts, decrypts (Kenc, Kmac) using skA and re-
    encrypts with pkS then sends on to S
     • A doesn‟t have to use (Kenc, Kmac) here… any keys would do
  – Idea is that A proxies the connection between C and
    S and reads/alters any traffic he wishes
                      MitM Attack
           hello                                hello



            pkA                                pkS



C    (Kenc, Kmac) under pkA
                                   A    (Kenc, Kmac) under pkS
                                                                      S

    “Welcome” under (Kenc, Kmac)       “Welcome” under (Kenc, Kmac)



     CC# under (Kenc, Kmac)              CC# under (Kenc, Kmac)
          How do we Stop This?
• Idea:
   – Embed pkS in the browser
      • A cannot impersonate S if the public key of S is already held
        by C
      • Problems:
          – Scalability (100,000 public keys in your browser?)
          – Key freshening (if a key got compromised and it were already
            embedding in your browser, how would S update?)
          – New keys (how do you get new keys? A new browser?)
          – Your crypto is only as reliable as the state of your browser
            (what if someone gets you to install a bogus browser?)

• (Partial) Solution: Certificates
         Certificates: Basic Idea
• Enter the “Certification Authority” (CA)
  – Some trusted entity who signs S‟s public key
     •   Well-known ones are Verisign, RSA
     •   Let‟s assume the entity is called “CA”
     •   CA generates keys vkCA and skCA
     •   CA signs pkS using skCA
     •   CA‟s vkS is embedded in all browsers
          – Same problem with corrupted browsers as before, but
            the scaling problem is gone
                 New Protocol
• C sends Hello
• S sends pkS and the signature of CA on pkS
   – These two objects together are called a “certificate”
• C verifies signature using vkCA which is built in to
  his browser
• C generates (Kenc, Kmac), encrypts with pkS and
  sends to S
• S decrypts (Kenc, Kmac) with skS
• Session proceeds with symmetric cryptography
        SSH (A Different Model)
• SSH (Secure SHell)
  – Replacement for telnet
  – Allows secure remote logins
• Different model
  –   Too many hosts and too many clients
  –   How to distribute pk of host?
  –   Can be done physically
  –   Can pay a CA to sign your keys (not likely)
  –   Can run your own CA
       • More reasonable, but still we have a bootstrapping problem
        SSH: Typical Solution
• The most common “solution” is to accept initial
  exposure
  – When you connect to a host for the first time you get a
    warning:
     • “Warning: host key xxxxxx with fingerprint xx:xx:xx is not in
       the .ssh_hosts file; do you wish to continue? Saying yes may
       allow a man-in-the-middle attack.” (Or something like that)
     • You take a risk by saying “yes”
     • If the host key changes on your host and you didn‟t expect
       that to happen, you will get a similar warning
         – And you should be suspicious
            Key Fingerprints
• The key fingerprint we just saw was a
  hash of the public key
  – Can use this when you‟re on the road to verify
    that it‟s the key you expect
     • Write down the fingerprint on a small card and
       check it
     • When you log in from a foreign computer, verify
       the fingerprint
  – Always a risk to log in from foreign computers!
           X.509 Certificates
• X.509 is a format for a certificate
  – It contains a public key (for us, at least), email
    address, and other information
  – In order to be valid, it must be signed by the
    CA
  – In this class, our grader Martin, will be the CA

				
DOCUMENT INFO