Foundations of Network and Computer Security

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 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 salt hash function iv, key (128 bits each) plaintext AES-128-CBC iv, ciphertext salt • 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 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)

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

Foundations of Network and Computer Security