Network Security Network Security introduction cryptography authentication key exchange Reading: Tannenbaum, section 7.1 Ross/Kurose, Ch 7 (which is incomplete) Intruder may eavesdrop remove, modify, and/or insert messages read and playback messages Security in Computer Networks Important issues: cryptography: secrecy of info being transmitted authentication: proving who you are and having correspondent prove his/her/its identity User resources: login passwords often transmitted unencrypted in TCP packets between applications (e.g., telnet, ftp) passwords provide little protection
Encryption Network resources: often completely unprotected from intruder eavesdropping, injection of false messages mail spoofs, router updates, ICMP messages, network management messages Bottom line: intruder attaching his/her machine (access to OS code, root privileges) onto network can override many system-provided security measures users must take a more active role plaintext: unencrypted message ciphertext: encrypted form of message Intruder may intercept ciphertext transmission intercept plaintext/ciphertext pairs obtain encryption decryption algorithms A simple encryption algorithm Substitution cipher: abcdefghijklmnopqrstuvwxyz poiuytrewqasdfghjklmnbvczx replace each plaintext character inmessage with matching ciphertext character: plaintext: Charlotte, my love ciphertext: iepksgmmy, dz sgby key is pairing between plaintext characters and ciphertext characters symmetric key: sender and receiver use same key 26! (approx 10^26) different possible keys: unlikely to be broken by random trials substitution cipher subject to decryption using observed frequency of letters 'e' most common letter, 'the' most common word
DES: Data Encryption Standard encrypts data in 64-bit chunks encryption/decryption algorithm is a published standard everyone knows how to do it substitution cipher over 64-bit chunks: 56-bit key determines which of 56! substitution ciphers used substitution: 19 stages of transformations, 16 involving functions of key decryption done by reversing encryption steps sender and receiver must use same key Key Distribution Problem Problem: how do communicant agree on symmetric key? N communicants implies N keys Trusted agent distribution: keys distributed by centralized trusted agent any communicant need only know key to communicate with trusted agent for communication between i and j, trusted agent will provide a key We will cover in more detail shortly
Public Key Cryptography separate encryption/decryption keys receiver makes known (!) its encryption key receiver keeps its decryption key secret to send to receiver B, encrypt message M using B's publicly available key, EB send EB(M) to decrypt, B applies its private decrypt key DB to receiver message: computing DB( EB(M) ) gives M knowing encryption key does not help with decryption; decryption is a non-trivial inverse of encryption only receiver can decrypt message Question: good encryption/decryption algorithms RSA: public key encryption/decryption RSA (continued) RSA: a public key algorithm for encrypting/decrypting Entity wanting to receive encrypted messages: choose two prime numbers, p, q greater than 10^100 compute n=pq and z = (p-1)(q-1) choose number d which has no common factors with z compute e such that ed = 1 mod z, i.e., integer-remainder( (ed) / ((p-1)(q-1)) ) = 1, i.e., ed = k(p-1)(q-1) +1 three numbers: e, n made public d kept secret to encrypt: divide message into blocks, {b_i} of size j: 2^j < n encrypt: encrypt(b_i) = b_i^e mod n to decrypt: b_i = encrypt(b_i)^d to break RSA: need to know p, q, given pq=n, n known factoring 200 digit n into primes takes 4 billion years using known methods
RSA example choose p=3, q=11, gives n=33, (p-1)(q-1)=z=20 choose d = 7 since 7 and 20 have no common factors compute e = 3, so that ed = k(p-1)(q-1)+1 (note: k=1 here) plaintext e=3 ciphertext char # #^3 #^3 mod 33 S 19 6859 28 U 21 9261 21 N 14 2744 5 cipherte xt d=7 plaintex t c c^7 c^7 mod char 33 28 13492928512 19 S 21 1801 21 N Further notes on RSA why does RSA work? crucial number theory result: if p, q prime then b_i^((p-1)(q-1)) mod pq = 1 using mod pq arithmetic: (b^e)^d = b^{ed} = b^{k(p-1)(q-1)+1} for some k = b b^(p-1)(q-1) b^(p-1)(q-1)... b^(p-1)(q-1) = b 1 1... 1 = b Note: we can also encrypt with d and encrypt with e. this will be useful shortly How to break RSA? Brute force: get B's public key for each possible b_i in plaintext, compute b_i^e for each observed b_i^e, we then know b_i moral: choose size of b_i "big enough"
Authentication man-in-the-middle: intercept keys, spoof identity: Question: how does a receiver know that remote communicating entity is who it is claimed to be? Authentication Using Nonces Approach 1: peer-peer key-based authentication A, B (only) know secure key for encryption/decryption A sends encrypted msf to B and B decrypts: A to B: msg = encrypt("i am A") B computes: if decrypt(msg)=="i am A" then A is verified else A is fradulent failure scenarios? to prove that A is alive, B sends "once-in-a-lifetime-only" number (nonce) to A, which A encodes and returns to B A to B: msg = encrypt("i am A") B compute: if decrypt(msg)=="i am A" then A is OK so far B to A: once-in-a-lifetime value, n A to B: msg2 = encrypt(n) B computes: if decrypt(msg2)==n then A is verified else A is fradulent note similarities to three way handshake and initial sequence number choice problems with nonces?
Authentication Using Public Keys B wants to authenticate A A has made its encryption key EA known A alone knows DA symmetry: DA( EA(n) ) = EA ( DA(n) ) A to B: msg = "I am A" B to A: once-in-a-lifetime value, n A to B: msg2 = DA(n) B computes: if EA (DA(n))== n then A is verified else A is fradulent Digital Signatures Using Public Keys Goals of digital signatures: sender cannot repudiate message never sent ("I never sent that") receiver cannot fake a received message Suppose A wants B to "sign" a message M B sends DB(M) to A A computes if EB ( DB(M)) == M then B has signed M Question: can B plausibly deny having sent M? Symmetric key exchange: trusted server Problem: how do distributed entities agree on a key? Assume: each entity has its own single key, which only it and trusted server know Server: will generate a one-time session key that A and B use to encrypt communication will use A and B's single keys to communicate session key to A, B
Symmetric Key exchange: trusted server Preceding scenario: 1. A sends encrypted msg to S, containing A, B, nonce RA: EA(A,B,RA) 2. S decrypts using DA, generates one time session key, K, sends nonce, key, and B-encrypted encoding of key to A: EA(RA,B,K,EB(K,A)) 3. A decrypts msg from S using DA and verifies nonce. Extracts K, saves it and sends EB(K,A) to B. 4. B decrypts msg using DB, extracts K, generates new nonce RB, sends EK(RB) to A 5. A decrypts using K, extracts RB, computes RB-1 and encrypts using K. Sends EK(RB-1) to B 6. B decrypts using K and verifies RB-1 Public key exchange: trusted server public key retrieval subject to man-in-middle attack locate all public keys in trusted server everyone has server's encryption key (ED public) suppose A wants to send to B using B's "public" key Clipper Chip: technical aspects US gov't proposed federal information processing standard (voluntary) obviously need to encrypt many things passed over phone line encryption technique for Clipper (skipjack algorithm) highly classified voluntarily installed in telecommunications equipment (existing products) call setup: A and B want to communicate A, B use standard public key techniques to agree on a session key session key encrypted using clipper chips unit key encrypted session key and unencrypted unit ID put into LEAF (Law Enforcement Access Field) which is sent note: LEAF redundant, A and B know session K session key transmitted so it can be intercepted! session communication encrypted using session key
Privacy issues Clipper I: device manufacturers split unit chip key in half: unit chip key hardwired into tamper proof, non reverse-engineerable chip half in escrow at NIST, half at Treasury gov't wants to wiretap machine with known unit ID gov't (e.g., FBI) presents court orders to both agencies, gets unit chip key uses chip key to determine session key from LEAF decrypts using session key U.S. Export Laws Cryptography products are munitions 1992-40 bit key products can be exported 1996 - software key escrow 64bit key products can be exported provided key is registered with escrow agent in US 1996 - key recovery all encrypted msgs include session key encrypted using recovery agent key Other countries: most - none France - must escrow key for encryption Protection against Intruders: Firewalls Firewall: network components (host/router+software) sitting between inside ("us") and outside ("them) Packet filtering firewalls: drop packets on basis of source or destination address (i.e., IP address, port) Application gateways: application specific code intercepts, processes and/or relays application specific packets e.g., email of telnet gateways application gateway code can be security hardened can log all activity
Security: Internet activity IP layer: authentication of header: receiver can authenticate sender using messageauthentication code (MAC) encryption of contents: DES, RFC 1829 API SSL - secure socket layer: support for authentication and encryption port numbers: 443 for http with SSL, 465 for smtp with SSL Application Layer Privacy Enhanced Mail (PEM) secure http: supports many authentication, encryption schemes Secure Email PEM : operates on top of SMTP ASCII msg authentication - MD2, MD5 msg encryption - RSA, DES authenticated encrypted msgs and encrypted authenticated msgs PGP (Pretty Good Privacy): secure file transfer (incl. email) binary files key concerns: encryption authentication key exchange Security: conclusion also: increasingly an important area as network connectivity increases digital signatures, digital cash, authentication, increasingly important an important social concern further reading: Crypto Policy Perspectives: S. Landau et al., Aug 1994 CACM Internet Security, R. Oppliger, CACM May 1997 www.eff.org