1 / 35

Network Security

Network Security. introduction cryptography authentication key exchange required reading: text section 7.1. Network Security. intruder may eavesdrop remove, modify, and/or insert messages read and playback messages important issues:

tamarr
Télécharger la présentation

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 • required reading: text section 7.1

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

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

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

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

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

  7. 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 trys • substitution cipher subject to decryption using observed frequency of letters • 'e' most common letter, ;the' most common word

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

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

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

  11. we will cover in more detail shortly

  12. 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: • compute DB( EB(M) ) gives M

  13. knowing encryption key does not help with decryption: decryption is a non-trivial inverseof encryption • only receiver can decrypt message • question: good encryption/decryption algorithms

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

  15. RSA (continued) to encrypt: • divide message into i blocks, bi of size k: 2**k < n • encrypt: encrypt(bi) = bi**e mod n to decrypt: • bi = encrypt(bi)**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

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

  17. Further notes on RSA why does RSA work? • crucial number theory result: of p, q prime then bi**((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

  18. How to break RSA? Brute force: get B's public key • for each possible bi in plaintext, compute bi**e • for each observed bi**e, we then know bi • more: choose size of bi "big enough"

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

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

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

  22. Authentication Using Nonces to prove that A is alive, B sends "once-in-a-lifetime-only" number (nonce) to A, which Aencodes 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?

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

  24. Digital Signatures Using Public Keys Goals of digital signature: • sender can not repudiate message never sent ("I never sent that") • receiver can not fake a received message Suppose A wants B wants to "sign" a message M B sends DA(M) to A A computes if EA ( DA(M)) == M then A has signed M Question: can A plausibly deny having sent M?

  25. Symmetric key exchange: trusted server problem: how do distributed entitues 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

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

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

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

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

  30. 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 • unencrypts using session key US gov't outlawed export of greater-than-40-bit key technology • Oct 96: 56 bit key technology selectively exportable for two year trial basis

  31. Protection against Intruders: Firewalls

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

  33. 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 • secure http: supports many authentication, encryption schemes

  34. Security: conclusion key concerns: • encyption • authentication • key exchange also: • increasingly an important area as network connectivity increases • digital signatures, digital cash, authentication, biometrics 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