Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "1 Network Security  introduction  cryptography  authentication  key exchange  Reading: Tannenbaum, section 7.1 Ross/Kurose, Ch 7 (which is incomplete)"— Presentation transcript:

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

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

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

4 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 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 6 Encryption plaintext: unencrypted message ciphertext: encrypted form of message Intruder may  intercept ciphertext transmission  intercept plaintext/ciphertext pairs  obtain encryption decryption algorithms

7 7 A simple encryption algorithm Substitution cipher: abcdefghijklmnopqrstuvwxyzpoiuytrewqasdfghjklmnbvczx  replace each plaintext character in message with matching ciphertext character: plaintext: Charlotte, my love ciphertext: iepksgmmy, dz sgby

8 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 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 10  decryption done by reversing encryption steps  sender and receiver must use same key

11 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 12 We will cover in more detail shortly

13 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 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 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., integer-remainder( (ed) / ((p-1)(q-1)) ) = 1, i.e., ed = k(p-1)(q-1) +1 ed = k(p-1)(q-1) +1  three numbers:  e, n made public  d kept secret

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

19 19 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 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^{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 b^(p-1)(q-1) b^(p-1)(q-1)... b^(p-1)(q-1) = b 1 1... 1 = b 1 1... 1 = b = b Note: we can also encrypt with d and encrypt with e.  this will be useful shortly

20 20 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"

21 21 man-in-the-middle: intercept keys, spoof identity:

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

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

24 24 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 then A is verified else A is fradulent else A is fradulent  failure scenarios: playback attack  Trudy can intercept Alice’s message and masquerade as Alice at a later time

25 25 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 then A is verified else A is fradulent else A is fradulent  note similarities to three way handshake and initial sequence number choice  problems with nonces?

26 26 Authentication Using Public Keys Ap 4.0 uses symmetric keys for authentication 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 then A is verified else A is fradulent else A is fradulent

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

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

29 29 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 then B has signed M Question: can B plausibly deny having sent M?

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

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

32 32

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

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

35 35 Protection against Intruders: Firewalls

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

37 37 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 E B –Send K(M), E B (K) –Bob decrypts using his private key, gets K, decrypts K(M)

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

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

40 40 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 E S  B->S: “future messages will be encrypted”, and K(m)  S->B: “future messages will be encrypted”, and K(m)  SSL session begins…

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

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

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

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


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

Similar presentations


Ads by Google