Foundations of Network and Foundations of Network and Computer - - PowerPoint PPT Presentation

Foundations of Network and Foundations of Network and Computer Security Computer Security

J 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

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

salt=39A9CF66C733597E key=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 hash function AES-128-CBC iv, key (128 bits each) salt salt iv, ciphertext Things to think about:

• How to decrypt?
• Is the passphrase safe even though the salt and iv are known?

plaintext

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

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

C A S

hello hello pkS pkA (Kenc, Kmac) under pkA (Kenc, Kmac) under pkS “Welcome” under (Kenc, Kmac) CC# under (Kenc, Kmac) “Welcome” 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