390 likes | 405 Views
Learn about the fundamental concepts of network security, including cryptography, authentication, key exchange, and intruder threats. Understand encryption methods, key distribution, and public key cryptography like RSA. Discover how to protect user and network resources from unauthorized access and attacks.
E N D
Network Security • introduction • cryptography • authentication • key exchange • Reading: Tannenbaum, section 7.1 Ross/Kurose, Ch 7 (which is incomplete)
Network Security Intruder may • eavesdrop • remove, modify, and/or insert messages • read and playback messages
Important issues: • cryptography: secrecy of info being transmitted • authentication: proving who you are and having correspondent prove his/her/its identity
Security in Computer Networks User resources: • login passwords often transmitted unencrypted in TCP packets between applications (e.g., telnet, ftp) • passwords provide little protection
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
Encryption 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 in message 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
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: 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
RSA (continued) 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)
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 Question: how does a receiver know that remote communicating entity is who it is claimed to be?
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?
Authentication Using Nonces 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
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
Security: conclusion key concerns: • encryption • authentication • key exchange 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