1 / 44

Network Security

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.

Download Presentation

Network Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Network Security • introduction • cryptography • authentication • key exchange • Reading: Tannenbaum, section 7.1 Ross/Kurose, Ch 7 (which is incomplete)

  2. Network Security Intruder may • eavesdrop • remove, modify, and/or insert messages • read and playback messages

  3. Important issues: • cryptography: secrecy of info being transmitted • authentication: proving who you are and having correspondent prove his/her/its identity

  4. Security in Computer Networks User resources: • login passwords often transmitted unencrypted in TCP packets between applications (e.g., telnet, ftp) • passwords provide little protection

  5. 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

  6. Encryption plaintext: unencrypted message ciphertext: encrypted form of message Intruder may • intercept ciphertext transmission • intercept plaintext/ciphertext pairs • obtain encryption decryption algorithms

  7. 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

  8. 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

  9. 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

  10. decryption done by reversing encryption steps • sender and receiver must use same key

  11. 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

  12. We will cover in more detail shortly

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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)

  18. 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

  19. 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"

  20. man-in-the-middle: intercept keys, spoof identity:

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

  22. Authentication Protocol (ap) • Ap 1.0 • Alice to Bob: “I am Alice” • Problem: intruder “Trudy” can also send such a message • Ap 2.0 • Authenticate source IP address is from Alice’s machine • Problem: IP Spoofing (send IP packets with a false address) • Ap 3.0: use a secret password • Alice to Bob: “I am Alice, here is my password” (e.g., telnet) • Problem: Trudy can intercept Alice’s password by sniffing packets

  23. Authentication Protocol Ap 3.1:use encryption use a symmetric key known to Alice and Bob • Alice & Bob (only) know secure key for encryption/decryption 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: playback attack • Trudy can intercept Alice’s message and masquerade as Alice at a later time

  24. Authentication Using Nonces Problem with ap 3.1: same password is used for all sessions Solution: use a sequence of passwords pick a "once-in-a-lifetime-only" number (nonce) for each session Ap 4.0 A to B: msg = "I am A" /* note: unencrypted message! */ B to A: once-in-a-lifetime value, n A to B: msg2 = encrypt(n) /* use symmetric keys */ 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?

  25. Authentication Using Public Keys Ap 4.0 uses symmetric keys for authentication Question: can we use public keys? symmetry: DA( EA(n) ) = EA ( DA(n) ) AP 5.0 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

  26. Problems with Ap 5.0 • Bob needs Alice’s public key for authentication • Trudy can impersonate as Alice to Bob • Trudy to Bob: msg = “I am Alice” • Bob to Alice: nonce n (Trudy intercepts this message) • Trudy to Bob: msg2= DT(n) • Bob to Alice: send me your public key (Trudy intercepts) • Trudy to Bob: send ET (claiming it is EA) • Bob: verify ET(DT(n)) == n and authenticates Trudy as Alice!! • Moral: Ap 5.0 is only as “secure” as public key distribution

  27. Man-in-the-middle Attack • Trudy impersonates as Alice to Bob and as Bob to Alice • Alice Trudy Bob • “I am A” “I am A” • nonce n • DT(n) • send me ET • ET • nonce n • DA(n) • send me EA • EA • Bob sends data using ET, Trudy decrypts and forwards it using EA!! (Trudy transparently intercepts every message)

  28. 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?

  29. Message Digests • Encrypting and decrypting entire messages using digital signatures is computationally expensive • Routers routinely exchange data • Does not need encryption • Needs authentication and verify that data hasn’t changed • Message digests: like a checksum • Hash function H: converts variable length string to fixed length hash • Digitally sign H(M) • Send M, EA(H(m)) • Can verify who sent the message and that it has been changed! • Property of H • Given a digest x, it is infeasible to find a message y such that H(y) = x • It is infeasible to find any two messages x and y such that H(x) = H(y)

  30. 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

  31. 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

  32. 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

  33. Protection against Intruders: Firewalls

  34. 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

  35. Secure Email • Requirements: • Secrecy • Sender authentication • Message integrity • Receiver authentication • Secrecy • Can use public keys to encrypt messages • Inefficient for long messages • Use symmetric keys • Alice generates a symmetric key K • Encrypt message M with K • Encrypt K with EB • Send K(M), EB(K) • Bob decrypts using his private key, gets K, decrypts K(M)

  36. Secure Email • Authentication and Integrity (with no secrecy) • Alice applies hash function H to M (H can be MD5) • Creates a digital signature DA(H(M)) • Send M, DA(H(M)) to Bob • Putting it all together • Compute H(M), DA(H(M)) • M’= { H(M), DA(H(M)) } • Generate symmetric key K, compute K(M’) • Encrypt K as EB(K) • Send K(M’), EB(K) • Used in PGP (pretty good privacy)

  37. Secure Sockets Layer (SSL) • SSL: Developed by Netscape • Provides data encryption and authentication between web server and client • SSL lies above the transport layer • Useful for Internet Commerce, secure mail access (IMAP) • Features: • SSL server authentication • Encrypted SSL session • SSL client authentication

  38. Secure Socket Layer • Protocol: https instead of http • Browser -> Server: B’s SSL version and preferences • S->B: S’s SSL version, preferences, and certificate • Certificate: server’s RSA public key encrypted by CA’s private key • B: uses its list of CAs and public keys to decrypt S’s public key • B->S: generate K, encrypt K with with ES • B->S: “future messages will be encrypted”, and K(m) • S->B: “future messages will be encrypted”, and K(m) • SSL session begins…

  39. SSL • SET: secure electronic transactions [Visa, Mastercard] • Designed for secure credit card payment • Includes client, merchant and merchant’s bank • Homework: read up on SET from KR 7.7.2 • Homework: get your own digital certificate • Click on “security” icon (next to “print” icon) in Netscape 4.7 • Click on “Certificates” and then on “obtain your certificate” • Send an email to yourself signed with your certificate • Also examine listed of trusted CAs built into the browser

  40. 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

  41. 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

  42. 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

More Related