Foundations of Network and Computer Security

1
Foundations of Network and Computer Security

• John Black
• Lecture 15
• Oct 3rd 2007

CSCI 6268/TLEN 5831, Fall 2007
2
Announcements

• Midterm date(s) announced
• Midterm will be on Oct 22nd and 24th
• (Split midterm, obviously)
• Project 0 assigned today
• Due Oct 19th in class
• CAETE students may email project 0 directly to
  the grader,
  martin.cochran_at_colorado.edu
• Non-CAETE students may NOT do this

3
Digital Signatures

• Digital Signatures are authentication in the
  asymmetric key model
• MAC was in the symmetric key model
• Once again, Alice wants to send an authenticated
  message to Bob
• This time they dont share a key
• The security definition is the same
• ACMA model

4
We Can Use RSA to Sign

• RSA gives us a signing primitive as well
• Alice generates her RSA keys
• Signing key sk (d,n)
• Verification key vk (e,n)
• Distributes verification key to the world
• Keeps signing key private
• To sign message M 2 Zn
• Alice computes sig Md mod n
• Alice sends (M, sig) to Bob
• To verify (M, sig)
• Bob checks to ensure M sige mod n
• If not, he rejects
• Once again, dont do this use PSS or similar

5
Efficiency

• Why is this inefficient?
• Signature is same size as message!
• For MACs, our tag was small that was good
• Hash-then-sign
• We normally use a cryptographic hash function on
  the message, then sign the hash
• This produces a much smaller signature
• 2nd-preimage resistance is key here
• Without 2nd-preimage resistance, forgeries would
  be possible by attacking the hash function

6
Lets Sum Up

• 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

7
Next Up SSL

• Next well look at how to put all this together
  to form a network security protocol
• We will use SSL/TLS as our model since its
  ubiquitous
• But first, well digress to talk about OpenSSL,
  and our first part of the project (a warm-up)

8
OpenSSL

• Was SSLeay
• Open Source
• Has everything weve talked about and a lot more
• Most everything can be done on the command line
• Ungainly, awkward, inconsistent
• Mostly because of history
• Have fun, its the only game in town
• http//www.openssl.org/

9
Brief Tutorial

• This is a grad class you can figure it out from
  the man page, but
• Syntax is
• openssl ltcmdgt ltparmsgt
• cmd can be enc, rsautl, x509, and more
• Well start with the enc command (symmetric
  encryption)
• Lets look at the enc command in more detail

10
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 dont specify filenames, reads from and
  writes to stdin/stdout
• Looks like garbage, of course
• If you dont 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

11
enc (cont)

• openssl aes-128-cbc P
• enter aes-128-cbc encryption password
• 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 didnt 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 FB7D6E2490318E5CFC113751C
  10402A4 iv 6ED946AD35158A2BD3E7B5BAFC9A83EA

salt39A9CF66C733597E keyFB7D6E2490318E5CFC113751
C10402A4 iv 6ED946AD35158A2BD3E7B5BAFC9A83EA
12
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
  doesnt 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

13
Passphrase-Based enc
Passphrase
hash function
salt
iv, key (128 bits each)
plaintext
AES-128-CBC
ciphertext
salt

• Things to think about
• How to decrypt? Is the IV needed in the
  ciphertext?
• Is the passphrase safe even though the salt and
  iv are known?

14
So How to Encrypt

• Lets 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__mTRQi¹KÓàg5kE
• Whats up with the garbage?
• Of course the AES outputs arent ASCII!
• Use base64 option

15
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

16
Example base64

• Lets 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/tdjfZnPrDmSjBBO7InU8Mo4ttzTk8eY
• Well always use this option when dealing with
  portability issues
• Like sending ciphertext over email

17
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
• Lets decrypt the string
• U2FsdGVkX1/tdjfZnPrDmSjBBO7InU8Mo4ttzTk8eY
• which Ive placed into a file called test.enc
• openssl enc -d -in test.enc
• U2FsdGVkX18FZENOZFZdYvLoqPdpRTgZw2CZIQs6bMQ

18
Hunh?

• It just gave back the ciphertext?!
• We didnt specify an encryption algorithm
• Default is the identity map (get used to it)
• Lets try again
• openssl aes-128-cbc -d -in test.enc
• enter aes-128-cbc decryption password
• bad magic number
• Ok, now whats wrong?

19
Error messages not useful

• We forgot to undo the base64
• The error msg didnt 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 its your turn

20
Project 0

• Ill 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)
• Dont do it by hand
• Full description on our web page
• Due Oct 19th, in class

21
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 Im used to SSL)
• Used for web applications (https)
• But also used many other places that arent as
  well-known

22
TLS Sketch

• Lets start by trying to design TLS ourselves and
  see what else well 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

23
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 wont try DoS)
• Server generates RSA key pair for encryption
• pkS, skS
• S subscript stands for Server

24
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
• Whats wrong here?

25
Our First Protocol Problems

• There are tons of problems here
• We dont know how to encrypt 0,1, only how to
  encrypt elements of Zn
• Ok, say we solve that problem (there are ways)
• Its really SLOW to use RSA on big messages
• Ok, we mentioned this before lets use symmetric
  cryptography to help us
• There is no authentication going on here!
• Adversary could alter pkS on the way to the
  client
• Wed better add some authentication too
• Lets try again

26
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

27
Second Stab (cont)

• Problems?
• Good news were a lot more efficient now since
  most crypto is done with symmetric key
• Good news were doing some authentication now
• Bad news Man-in-the-Middle attack still possible
• Frustratingly close
• If we could get pkS to the client, wed be happy

28
Man in the Middle

• Lets 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 doesnt 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

29
MitM Attack
hello
hello
pkS
pkA
A
S
C
(Kenc, Kmac) under pkA
(Kenc, Kmac) under pkS
Welcome under (Kenc, Kmac)
Welcome under (Kenc, Kmac)
CC under (Kenc, Kmac)
CC under (Kenc, Kmac)
30
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

31
Certificates Basic Idea

• Enter the Certification Authority (CA)
• Some trusted entity who signs Ss public key
• Well-known ones are Verisign, RSA
• Lets assume the entity is called CA
• CA generates keys vkCA and skCA
• CA signs pkS using skCA
• CAs vkS is embedded in all browsers
• Same problem with corrupted browsers as before,
  but the scaling problem is gone

32
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

33
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

34
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
  xxxxxx 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
  didnt expect that to happen, you will get a
  similar warning
• And you should be suspicious

35
Key Fingerprints

• The key fingerprint we just saw was a hash of the
  public key
• Can use this when youre on the road to verify
  that its 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!

36
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