AuthenticationAuthentication

Question:Question: how does a receiver know that remote how does a receiver know that remote communicating entity is who it is claimed to be?communicating entity is who it is claimed to be?

Approach 1:Approach 1: peer-peer key-based authentication peer-peer key-based authentication A, B (only) know secure key for encryption/decryption A, B (only) know secure key for encryption/decryption A sends encrypted msf to B and B decrypts: A sends encrypted msf to B and B decrypts:

A to B: msg = encrypt("I am A")A to B: msg = encrypt("I am A")

B computes: if decrypt(msg)=="I am A"B computes: if decrypt(msg)=="I am A"

then A is verifiedthen A is verified

else A is fradulentelse A is fradulent

failure scenarios? failure scenarios?

Authentication Using Nonces Authentication Using Nonces

to prove that A is alive, B sends "once-in-a-lifetime-only" number (nonce) to A, to prove that A is alive, B sends "once-in-a-lifetime-only" number (nonce) to A, which A encodes and returns to Bwhich A encodes and returns to B

A to B: msg = encrypt("I am A")A to B: msg = encrypt("I am A")B compute: if decrypt(msg)=="I am A"B compute: if decrypt(msg)=="I am A" then A is OK so farthen A is OK so farB to A: once-in-a-lifetime value, nB to A: once-in-a-lifetime value, nA to B: msg2 = encrypt(n)A to B: msg2 = encrypt(n)B computes: if decrypt(msg2)==nB computes: if decrypt(msg2)==n then A is verifiedthen A is verified else A is fradulentelse A is fradulent

note similarities to three way handshake and initial sequence number choice note similarities to three way handshake and initial sequence number choice problems with nonces? problems with nonces?

Authentication Using Public KeysAuthentication Using Public Keys

B wants to authenticate A B wants to authenticate A

A has made its encryption key EA known A has made its encryption key EA known

A alone knows DA A alone knows DA

symmetry:symmetry: DA( EA(n) ) = EA ( DA(n) ) DA( EA(n) ) = EA ( DA(n) )

A to B: msg = "I am A"A to B: msg = "I am A"

B to A: once-in-a-lifetime value, B to A: once-in-a-lifetime value, nn

A to B: msg2 = DA(A to B: msg2 = DA(nn))

B computes: if EA (DA(B computes: if EA (DA(nn))== ))== nn

then A is verifiedthen A is verified

else A is fradulentelse A is fradulent

Digital Signatures Using Public Digital Signatures Using Public KeysKeys

Goals of digital signatures:Goals of digital signatures: sender cannot repudiate message never sent ("I never sent that") sender cannot repudiate message never sent ("I never sent that") receiver cannot fake a received message receiver cannot fake a received message

Suppose A wants B to "sign" a message M Suppose A wants B to "sign" a message M

B sends DB(M) to AB sends DB(M) to A

A computes if EB ( DB(M)) == MA computes if EB ( DB(M)) == M

then B has signed Mthen B has signed M

Question:Question: can B plausibly deny having sent M? can B plausibly deny having sent M?

Symmetric key exchange: trusted Symmetric key exchange: trusted serverserver

Problem:Problem: how do distributed entities agree on a key? how do distributed entities agree on a key?

Assume:Assume: each entity has its own single key, which each entity has its own single key, which only it and trusted server knowonly it and trusted server know

Server:Server: will generate a one-time session key that A and B will generate a one-time session key that A and B

use to encrypt communication use to encrypt communication will use A and B's single keys to communicate will use A and B's single keys to communicate

session key to A, B session key to A, B

Symmetric Key exchange: trusted Symmetric Key exchange: trusted serverserver

Preceding scenario: Preceding scenario:

1.1. A sends encrypted msg to S, containing A, B, nonce RA: EA(A,B,RA) A sends encrypted msg to S, containing A, B, nonce RA: EA(A,B,RA)

2. 2. S decrypts using DA, generates one time session key, K, sends S decrypts using DA, generates one time session key, K, sends nonce, key, and B-encrypted encoding of key to A: nonce, key, and B-encrypted encoding of key to A: EA(RA,B,K,EB(K,A)) EA(RA,B,K,EB(K,A))

3. 3. A decrypts msg from S using DA and verifies nonce. Extracts K, A decrypts msg from S using DA and verifies nonce. Extracts K, saves it and sends EB(K,A) to B. saves it and sends EB(K,A) to B.

4. 4. B decrypts msg using DB, extracts K, generates new nonce RB, B decrypts msg using DB, extracts K, generates new nonce RB, sends EK(RB) to A sends EK(RB) to A

5. 5. A decrypts using K, extracts RB, computes RB-1 and encrypts using A decrypts using K, extracts RB, computes RB-1 and encrypts using K. Sends EK(RB-1) to B K. Sends EK(RB-1) to B

6. 6. B decrypts using K and verifies RB-1 B decrypts using K and verifies RB-1

Public key exchange: trusted Public key exchange: trusted serverserver

public key retrieval subject to man-in-middle attack public key retrieval subject to man-in-middle attack locate all public keys in trusted server locate all public keys in trusted server everyone has server's encryption key (ED public) everyone has server's encryption key (ED public) suppose A wants to send to B using B's "public" key suppose A wants to send to B using B's "public" key

Clipper Chip: technical aspectsClipper Chip: technical aspects

US gov't proposed federal information processing US gov't proposed federal information processing standard (voluntary) standard (voluntary)

obviously need to encrypt many things passed over obviously need to encrypt many things passed over phone line phone line

encryption technique for Clipper (skipjack algorithm) encryption technique for Clipper (skipjack algorithm) highly classified highly classified

voluntarily installed in telecommunications equipment voluntarily installed in telecommunications equipment (existing products) (existing products)

call setup:call setup: A and B want to communicate A and B want to communicate A, B use standard public key techniques to agree on A, B use standard public key techniques to agree on

a session key a session key session key encrypted using clipper chips unit key session key encrypted using clipper chips unit key encrypted session key and unencrypted unit ID put encrypted session key and unencrypted unit ID put

into LEAF (Law Enforcement Access Field) which is into LEAF (Law Enforcement Access Field) which is sent sent note: LEAF redundant, A and B know session K note: LEAF redundant, A and B know session K session key transmitted so it can be intercepted! session key transmitted so it can be intercepted!

session communication encrypted using session key session communication encrypted using session key

Privacy issuesPrivacy issues

Clipper I:Clipper I: device manufacturers split unit chip key in device manufacturers split unit chip key in half: half:

unit chip key hardwired into tamper proof, non unit chip key hardwired into tamper proof, non reverse-engineerable chip reverse-engineerable chip

half in escrow at NIST, half at Treasury half in escrow at NIST, half at Treasury gov't wants to wiretap machine with known unit ID gov't wants to wiretap machine with known unit ID

gov't (e.g., FBI) presents court orders to both agencies, gov't (e.g., FBI) presents court orders to both agencies, gets unit chip key gets unit chip key

uses chip key to determine session key from LEAF uses chip key to determine session key from LEAF decrypts using session key decrypts using session key

U.S. Export Laws U.S. Export Laws

Cryptography products are munitionsCryptography products are munitions

19921992 - - 40 bit key products can be exported 40 bit key products can be exported

1996 - 1996 - software key escrowsoftware key escrow 64bit key products can be exported provided key is registered 64bit key products can be exported provided key is registered

with with escrow agentescrow agent in US in US

1996 -1996 - key recovery key recovery all encrypted msgs include session key encrypted using all encrypted msgs include session key encrypted using

recovery agentrecovery agent key key

Other countries:Other countries: most - nonemost - none France - must escrow key for encryptionFrance - must escrow key for encryption

Protection against Intruders: Protection against Intruders: FirewallsFirewalls

Firewall:Firewall: network components (host/router+software) network components (host/router+software) sitting between inside ("us") and outside ("them) sitting between inside ("us") and outside ("them)

Packet filtering firewallsPacket filtering firewalls:: drop packets on basis of drop packets on basis of source or destination address (i.e., IP address, port) source or destination address (i.e., IP address, port)

Application gateways:Application gateways: application specific code application specific code intercepts, processes and/or relays application intercepts, processes and/or relays application specific packets specific packets e.g., email of telnet gateways e.g., email of telnet gateways application gateway code can be security hardened application gateway code can be security hardened can log all activity can log all activity

Security: Internet activitySecurity: Internet activity

IP layer:IP layer: authentication of header: receiver can authenticate sender using authentication of header: receiver can authenticate sender using

messageauthentication code (MAC) messageauthentication code (MAC) encryption of contents: DES, RFC 1829 encryption of contents: DES, RFC 1829

API API SSL - secure socket layer: support for authentication and encryption SSL - secure socket layer: support for authentication and encryption

port numbers: 443 for http with SSL, 465 for smtp with SSL port numbers: 443 for http with SSL, 465 for smtp with SSL

Application LayerApplication Layer Privacy Enhanced Mail (PEM)Privacy Enhanced Mail (PEM) secure http: supports many authentication, encryption schemes secure http: supports many authentication, encryption schemes

Secure EmailSecure Email

PEMPEM : : operates on top of SMTPoperates on top of SMTP

ASCIIASCII msg authentication - MD2, MD5msg authentication - MD2, MD5 msg encryption - RSA, DESmsg encryption - RSA, DES authenticated encrypted msgs and encrypted authenticated encrypted msgs and encrypted

authenticated msgsauthenticated msgs

PGP (Pretty Good Privacy):PGP (Pretty Good Privacy): secure file transfer (incl. secure file transfer (incl. email) email) binary filesbinary files

Security: conclusionSecurity: conclusionkey concerns:key concerns: encryption encryption authentication authentication key exchange key exchange

also:also: increasingly an important area as network connectivity increases increasingly an important area as network connectivity increases digital signatures, digital cash, authentication, increasingly important digital signatures, digital cash, authentication, increasingly important an important social concern an important social concern further reading: further reading:

Crypto Policy Perspectives: S. Landau et al., Aug 1994 CACM Crypto Policy Perspectives: S. Landau et al., Aug 1994 CACM Internet Security, R. Oppliger, CACM May 1997 Internet Security, R. Oppliger, CACM May 1997 www.eff.org www.eff.org