Lecture 18: Security

Reading: Chapter 8

(Some material thanks toWilliam Perrizo)

?

CMSC 23300/33300

Computer Networks

http://dsl.cs.uchicago.edu/Courses/CMSC33300

2

Taxonomy of Network Security

Privacy: prevent unauthorized release of information Authentication: verify identity of a remote participant Integrity: assure message is unaltered

All based on encryption Key distribution is a cross-cutting problem

Security

Cryptography

algorithms

Public

key

(e.g., RSA)

Secret

key

(e.g., DES,AES, IDEA)

Message

digest

(e.g., MD5)

Security

services

AuthenticationPrivacy Message

integrity

3

Need for Security

Some people who cause security problems and why

4

The Encryption Model (for a Symmetric-key Cipher)

5

Cryptographic Algorithms

Secret key DES: Data Encryption Standard Other more recent variations: AES-Advanced

Encryption Standard; IDEA-Int’l Data Encryption Alg) Public key

RSA method (Rivest, Shamir, Adleman) Message Digest (keyless)

MMD5: based on cryptographic checksum

6

Cryptographic Functions

Cryptography algorithms can be used to implement a number of functions, including Privacy: prevent unauthorized release of information Authentication: verify identity of a remote participant

(including service to which a request is to be sent) Integrity: assure message is unaltered

Other functions are also of interest, e.g. Nonrepudiation Authorization …

7

DES (Data Encryption Standard)

Key needs to be secret but not the algorithm itself DES makes the algorithm so complex that none of the

structure of the plaintext remains in the ciphertext (attacker must get key)

Derives its security from complexity (not completely secure these days)

Can be broken if the attacker finds the factors of a number which is the product of two large primes

Computationally costly – at least it was! With a Beowulf cluster of 3000 high end PCs, could be

cracked in ~ 6 months

8Plaintext

Encrypt withsecret key

Ciphertext

Plaintext

Decrypt withsecret key

Initial bitpermutation

Rnd 1

Rnd 2

Rnd 16

56-bitkey

Final Permutation(inverse of original)

… 64-bit key(56 + 8-bit parity)

64-bit block of plaintext

Block1

IV

DES

Cipher1

Block2

DES

Block3

DES

Block4

DES

+

Cipher2

Cipher3

Cipher4

+++

CBC: cipher block chainingRepeat for large messages

Initialization Vector

+

F

L

i – 1

R

i – 1

R

i

K

i

L

i

Differentsubkey each round = XOR

Li = Ri-1

Ri = Li-1 F(Ri-1 , Ki)

CombinerFunction (a mess)

DES

9

Encrypt using public key and Decrypt using private key, both 512-bit keys.

Encryption: c = memod n Decryption: m = cdmod n

n = p*q, (p and q large prime numbers - each roughly 256 bits).

e is relatively prime to (p - 1) x (q - 1) (encryption key)

d = e-1mod ((p - 1) x (q - 1)) (decryption key)

public key = (e, n)

private key = (d, n)

Ignoring the mod functions, subsituting c=me into cd gives med = mee-1 =m

So it remains to show that the same arithmetic holds under the mod functions. Why?

Plaintext

Encrypt with

Ciphertext

Plaintext

Decrypt with

Public keyc = memod n

Private keym = cdmod n

RSA is too slow to be very useful in encrypting data messages (n ~ 2512 ~ 1051)It’s used to encrypt small things, e.g., secret keys, hash values.

RSA

10

Hash Functions Hash functions always map a data

space, S, into a fixed-size hash space, H E.g., size M at right

In DBMSs the goal is to reduce size and to provide a fast look up function E.g., mod functions

In Security the goal is to produce a functional value that does not reveal the domain data value from which it was computed I.e., inverse function is uncomputable

data-value(from S)

hashfctn

hash-value space, H

2

0

M-1

11

Cryptographic Checksums or Message Digests

Complex hash functions that compute a fixed length checksum from arbitrarily long messages Regular checksums protect the receiver from accidental changes to the

message. Cryptographic checksums protect the receiver from malicious changes to

the message One-way function

Given a cryptographic checksum for a message, it is virtually impossible to figure out what message produced that checksum; it is not computationally feasible to find two messages that hash to the same cryptographic checksum

If you have checksum of a message and you can compute same checksum from that message, then it is highly likely this message produced the checksum you were given

12

MD5

Roughly MD5 goes like this: Pad message to multiple of 512B 1st pass: 512B segments digested 2nd pass: similar but uses different fctn 3rd pass: yet another fctn (XOR based) 4th pass: another fctn (XOR,OR,NOT based) Resulting in a mangled digest which is: added to digest from previous stage! …

Transform

Initial“digest“(constant)

Message (padded)

Transform

Transform

Message digest

512 bits512 bits 512 bits■ ■ ■

13

3-way handshake (DES based)

Assume secret key, sk, has been exchanged

Client: select a random number x, encrypts (using sk) it and sends it

Client Server

C-id, DES(x,sk)

DES(x+1,sk) DES(y,sk)

DES(y+1,sk)

DES(sk,SessKey)

Server: decrypt (with sk); add 1; encrypt (with sk).

Gen random number y, encrypt; send bothClient: decrypt 1st part to verify x+1

(client now has authenticated server).

Decrypt 2nd part; add 1; encrypt; send.

Server: Send client a Session Key (sk encrypted)

to be used for all data messages

(so sk will be less vulnerable)

Server: Decrypt to verify y+1

(server now has authenticated client).

Authentication: Method 1

14

Assume A shares secret key, ska, with AS;

B shares secret key, skb, with AS

A (unencrypted) identifies itself and B to ASAS B

DES((T,L,SK,A),skb)DES((A,T),SK)

A,B

DES((T,L,SK,B),ska)DES((T,L,SK,A),skb

DES(T+1,SK)

A

AS sends a 2-part message to A:

DES((TimeStamp, LifeTime, SessKey, B), ska)

DES((TimeStamp, LifeTime, SessKey, A), skb)

B, upon seeing that A and T are the same in both (decrypts passed-along message 1st to get SessionKey, SK, to decrypt other part), replies with DES(T+1, SessKey)

A decrypts 1st part with its secret key, ska;

passes 2nd part, with DES((A, T), SessKey) to B

When is B authenticated to A? Vice versa?

A variation of T3P is used in Kerberos

(MIT developed TCP/IP-based security system)

Authentication: Method 2Trusted 3rd Party (Auth. Server, AS)

15

Authentication: Method 3Public Key Authentication (uses RSA)

A B

RSA(x, BPubKey)

x

A generates random number, x Sends RSA((x, BPublicKey) to B

B decrypts with BPrivateKey. Sends x back to A.

A can authenticate itself to B in the same way.

16

Message Integrity Protocols

Sometimes two participants do not care whether an eavesdropper is able to read the message,

but they are worried about an imposter claiming to be one of them (i.e., they want to ensure the integrity of their messages)

One way: encrypt using DES and cipher block chaining, then use CBC residue (last CBC block) as a hash or

checksum or message integrity code (MIC) If the receiver cannot reproduce the attached MIC using

the secret key then either the message was not sent by sender or it was modified since it was transmitted

17

Message Integrity Protocols#1 of 3: Digital Signature using RSA

Participant is the only one with the private key so he uses this key to produce the signature Any other participant can verify this signature using the public key

Thus, to send a message, encrypt with private key To verify a signature, you decrypt using public key of purported

sender RSA is ~3 orders of magnitude slower than DES Observe that this use of RSA keys is just the opposite of its use

in privacy For integrity, sender encrypts with its private key (rather than with

receiver’s public key) Receiver decrypts with sender’s public key (rather than with

receiver private key)

18

Message Integrity Protocols using MD5

Keyed MD5 Assumes sender and receiver already share a secret key, k

Sender runs MD5 over the concatenation of the message, m, and

key, k transmits m + MD5(m+k) (+ means concatenation)

Receiver runs MD5 on m (all but final 64 bits of what was received)

concatenated with k – i.e., MD5(m+k). If result matches (the last 64-bits of what was received)

then m was sent by key holder There are many variations of this protocol!

19

2nd MD5 Message Integrity Protocol: MD5 with RSA Signature

m + RSA[MD5(m), PrivateKey] is sent (where m is message it wants to protect integrity of) I.e., sender doesn’t sign entire message, just checksum

The receiver verifies the message by Running MD5 algorithm on the received message Decrypting the signed checksum with the sender’s

public key Comparing the two checksums

If they match, the message was not modified since the time the sender computed the MD5 checksum and signed it

20

Public Key Distribution (X.509)

Key Distribution: get keys to people so they can be sure the key is legitimate I.e., it belongs to the entity it’s purported to belong to

Can’t just use email or use a bulletin board Without A’s public key B has no way to authenticate the key

as having come from A Can exchange public keys in person

Has limitations too – have to be together in person Basic solution is to use Digital Certificates (DC)

A document, digitally signed by X, that says “I certify that public key in this document belongs to entity Y”

X = anyone with the public key of the entity named

21

Public Key Distribution, contd.

Usually X=Certification Authority Administrative entity in business of issuing certificates

DCs are only useful to participant already holding X’s public key (to decrypt the signature)

Thus, DCs do not solve the key distribution problem entirely

Once you have a public key for one entity, you can start to accumulate more public keys from participants who have DCs from X

22

Digital Certificate Chain of Trust

If X certifies that a public key belongs to Y, and then Y goes on to certify that another public key belongs to Z, then a chain of certificates from X to Z exists even though X and Z may never have met

Z can provide his public key to A, and the complete chain of certificates (the certificate for Ys PK issued by X and the certificate for Zs PK issued by Y)

If A has PK for X he can use the chain to verify that they are legitimate

A popular way to build chains of trust is to arrange them in a tree structure

23

Digital Certificate Chain of Trust

IPRA (Internet Policy Registration Authority)

PCA-1

CA/ \

user user

CA |

user

CA |

user

PCA-n

CA CA

CA

user

user

What is being certified? Binding between identity and public key (Is Jon Smith a well-defined identity?)

Certificates must be used in a well-defined name space (e.g., email names) E.g., the Domain Name Space (DNS)

24

Certificate Standards

E.g., X.509, which specifies components such as The name of the entity The public key of the entity The name of the certificate authority A digital signature (many different digital signature algs) Expiration time

Possession of a certificate says nothing about your identity: certificates can and must be freely copied and distributed to be useful

To prove that you are the entity named in the certificate you need to show you have the private key corresponding to the public key contained in that certificate: the authentication problem

25

Certificate Revocation

If your Private Key is stolen you need to revoke your certificate There may be many certificates asserting that you are

the owner of the public key corresponding to that private key

Person who has your private key has everything he needs to impersonate you

CAs issue certificate revocation lists (CRL), a digitally signed list of revoked certificates Periodically updated and made public

26

Example Systems

Components required to build a secure system include cryptographic algorithms, authentication protocols, and key distribution mechanisms.

Some systems that use these components are: IP Security (IPSEC) operates at the network layer (IP

layer) Transport Layer Security (TLS) (built from the older -

Secure Socket Layer or SSL) Secure Shell (SSH) application-level secure remote login

facility

27

Secure Shell (SSH)

Secure remote login and file transfer Provides strong client/server authentication Also supports message integrity and confidentiality

SSH version 2 has 3 protocols E.g., SSH-TRANS provides encrypted channel on top of TCP as

follows: Upon remote login, Client authenticates server using RSA Client and Server establish session key to encrypt data Client authenticates itself to Server

Supports other TCP applications (e.g., Xwindows, IMAP mail reader...) through SSH tunnels

Applicationclient

Applicationserver

SSH SSHForwarded connection

Direct connection

Host A Host B

28

IETF Transport Layer Security (TLS)

Looks to the user just like TCP, except that it provides privacy, integrity and authentication.

When HTTP is used over TLS, it is known as HTTPS (secure HTTP) In fact, HTTPS is just exactly HTTP over TLS

instead of TCP (port=443 instead of 80) TLS is broken down into two parts

(handshake & record protocols) Handshake protocol to negotiate parameters

Crypto algorithms, certificate, session keys, init vectors…)

Two RTTs

Application (e.g., HTTP)

Secure transport layer

TCP

IP

Subnet

Client Server

Hello

Hello[Certificate,Keys,CertificateRequest]HelloDone

Finish

Data

29

TLS, contd.

Record protocol defines set of formats/procs by which app messages are fragmented or coalesced into the right sized blocks for: optimal compression integrity protection using a hash such as MD5 encryption passing to lower layer (TCP) for transmission

TLS offers “resume session” feature - very useful for HTTP. TLS does not specify key infrastructure. TLS uses a single CA, whose public key is included in web

browsers Therefore it is popular for credit card applications.

30

Taxonomy of Network Security

Privacy: prevent unauthorized release of information Authentication: verify identity of a remote participant Integrity: assure message is unaltered

All based on encryption Key distribution is a cross-cutting problem

Security

Cryptography

algorithms

Public

key

(e.g., RSA)

Secret

key

(e.g., DES,AES, IDEA)

Message

digest

(e.g., MD5)

Security

services

AuthenticationPrivacy Message

integrity

31

Caveat

“If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology."

— Bruce Schneier

32

Further Reading

Security Engineering: A Guide to Building Dependable Distributed Systems, by Ross Anderson

Security: Secret & Lies, Digital Security in a Networked World, by Bruce Schneier