Presentation is loading. Please wait.

Presentation is loading. Please wait.

ECE454/CS594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011.

Similar presentations


Presentation on theme: "ECE454/CS594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011."— Presentation transcript:

1 ECE454/CS594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011 1

2 Overview of Authentication Systems Password-based authentication Address-based authentication Cryptography-based authentication Trusted intermediaries Session key establishment Authentication of people 2

3 Basic Problem How do you prove to someone you are who you claim to be? Any system with access control must solve this problem. 3 ?

4 Authentication Verify the identity of a person (or a machine) Assume there is a secret that is only known by the person (machine). If a remote party can demonstrate the knowledge of the secret, it is authenticated. 4

5 Who Is Being Authenticated? Authenticate a person to a server Authenticate a machine to a machine Authenticate both a person and a machine to a server A machine stores high-quality secret; a person memorizes low-quality password Cryptographic operations - Use password directly in the cryptographic operation -Use password to derive a high-quality secret first 5

6 Password as Cryptographic Key 6 Secret key: hash a password to get a DES key Public key: - Use a password to encrypt a private key - Use a password as the seed for a random number generator to create a private/public key pair

7 Password-based Authentication 7 What you know: user has a secret password, system checks it to authenticate the user Password is sent over in plaintext for authentication Problems: - eavesdropping - database reading - password guessing: online, offline (dictionary attack)

8 Storing User Password 8 Where to store: Store passwords individually on each server Store all passwords at authentication storage node: authentication done at server Store all passwords at authentication facilitator node: authentication done at facilitator In what format: Store passwords in plaintext Store password hashes: password-guessing Store encrypted passwords: node compromise Store encrypted password hashes

9 UNIX-Style Passwords 9 t4h97t4m43 fa6326b1c2 N53uhjr438 Hgg658n53 … usersystem password file “cypherpunk” hash function

10 UNIX Password System 10 Uses modified DES as if it were a hash function Encrypt NULL string using password as the key - Truncates passwords to 8 characters! Artificial slowdown: run DES 25 times Can instruct modern UNIX to use MD5 hash function Problem: passwords are not truly random With 52 upper- and lower-case letters, 10 digits and 32 punctuation symbols, there are 94 8  6 quadrillion possible 8-character passwords Humans like to use dictionary words, human and pet names  1 million common passwords

11 Dictionary Attack 11 Password file /etc/passwd is world-readable Dictionary attack is possible because many passwords come from a small dictionary - Attacker can compute H(word) for every word in the dictionary and see if the result is in the password file - With 1,000,000-word dictionary and assuming 10 guesses per second, brute-force online attack takes 50,000 seconds (14 hours) on average (conservative estimate, offline attack is much faster!)

12 Salt 12 fURxfg,4hLBX salt (chosen randomly when password is first set) crypt(pwd,salt) Password Users with the same password have different entries in the password file Dictionary attack is still possible! Basically, DES on NULL plaintext

13 Advantage of Salting 13 Without salt, attacker can pre-compute hashes of all dictionary words once for all password entries With salt, attacker must compute hashes of all dictionary words once for each password entry - With 12-bit random salt, same password can hash to 2 12 different hash values - Attacker must try all dictionary words for each salt value in the password file

14 Address-based Authentication 14 Where you are Each computer stores information which specifies accounts on other computers that should have access to its resources UNIX, VMS - File copy, log in, remote execution Network address impersonation: - forge source address is easy but the packet might not return back to source (due to destination based routing) - same LAN, on the path, different LANs

15 Cryptography-based Authentication 15 Challenge-response - secret key cryptography - hashes - public key cryptography

16 Eavesdropping and Database Reading 16 Public key cryptography is secure against both eavesdropping and server database reading. Password or secret key cryptography is resilient to one (which one?) but not both.

17 Trusted Intermediaries 17 SKC solution: key distribution center (KDC) - establishes shared secret key over network - overcomes scalability problem of secret keys: for n machines to mutually authenticate with each other, O(n^2) number of keys are required. PKC solution: certification authority (CA) - when Alice obtains Bob’s public from web site, email, disc, how does she know it’s not Trudy’s?

18 KDC 18 A trusted central node Each node i shares a secret key K i with KDC Any two nodes must first communicate through KDC

19 Authentication with KDC (in Principle) 19 A and B do not authenticate directly A first authenticates with KDC KDC selects a temporary secret K AB, and sends K A {K AB } to A and K B {K AB } to B Now A and B has a common secret K AB, and they can authenticate each other

20 Authentication with KDC (in Practice) 20 A and B do not authenticate directly A first authenticates with KDC KDC selects a temporary secret K AB, and sends K A {K AB } and K B {K AB } to A A sends K B {K AB }, called a ticket, to B Now A and B has a common secret K AB, and they can authenticate each other

21 KDC Performance 21 O(n) keys are needed When a new user arrives or a user key is compromised, only one place (KDC) and one key needs to be re-configured Disadvantages - single point of vulnerability - single point of failure - performance bottleneck

22 CA 22 Public key equivalent of KDC A trusted central node - register (by phone or by …) the public key with CA - CA signs each node’s public key with its private key; the result is called a certificate, which can be stored anywhere - everyone is required to be pre-configured with CA’s public key

23 Certificate Generation and Verification 23 Bob’s public key K B + Bob’s identifying information digital signature (sign) CA private key K CA - K B + certificate for Bob’s public key, signed by CA Bob’s public key K B + digital signature (verify) CA public key K CA + K B + Generation Verification

24 Advantages of CA 24 The CA does not need to be on-line It can be a simpler device The failure of the CA would not disable the whole network Certificates are not security-sensitive A compromised CA cannot decrypt conversations between two parties.

25 Certificate Revocation 25 Certificate for A: - CA.privateKey{A.name, A.publicKey, expiration time, serial number, …} - Every one in the group has a trust relationship with CA, with CA’s public key pre-configured - CA can extend this trust relationship by issuing certificates When A leaves the group, this trust extension should be terminated, but if A’s certificate is not expired, this extension still exists Certificate Revocation List (CRL) is published periodically to revoke certificate B accepts A’s certificate only when it has a valid CA signature, has not expired, and is not in the CA’s most recent CRL

26 Single KDC/CA 26 Problems: - Single administration trusted by all principals - Single point of vulnerability and failure - Scalability Solutions: break into multiple domains Each domain has a trusted administration

27 Multiple KDC Domains 27

28 Authentication Across Domains 28

29 KDC Chains and Hierarchy 29

30 Multiple CA Domains 30 All users of a domain has the public key of the domain’s CA CAs of different domains hold each other’s public key, forming a mesh, a hierarchy, or a graph. CAs issue certificates for each other The trust relationship extends along a CA chain

31 Session Key Establishment 31 Use long-term shared keys (public/private keys or secret keys) to authenticate Authentication protocols negotiate session keys for subsequent data encryption Why: - Keys “wear out” if used a lot; Shared key requires external means to configure and should be used sparsely - Shared key encryption is subject to replay attacks - Once a long term shared key is compromised, all old encrypted messages can be decrypted

32 Delegation 32 Alice logs onto a remote computer from a dumb terminal at home. She needs the computer to access various resources on her behalf Give the shared secrets to the computer? Set ACL dynamically on the resources? Use her private key to sign the permissions (like a certificate), or ask KDC to encrypt the permissions in a ticket

33 Authentication of People 33 Main techniques: What you know: password, SSN, DoB What you have: physical keys, credit cards, smart card What you are: biometrics

34 Authentication Token 34 A physical device used in authenticating What you have - generally coupled with one of the other two mechanisms Examples: Keys, credit cards (magnetic strip) Disadvantages: - requires custom hardware on every access device - subject to loss or theft - no or little protection against communication eavesdropping

35 Smart Card 35 Smart card: keeps secret and possesses processing capability (CPU and memory) to carry out cryptographic authentication PIN protected memory card Cryptographic challenge/response cards Cryptographic calculator - keypad + display; no card reader - time encryption protocols to encrypt the current time; no keypad, no card reader.

36 Biometrics 36 What you are: Retinal scanner Fingerprint reader Face recognition Iris scanner Handprint reader Voiceprint Keystroke timing Signatures

37 Reading Assignment 37 [Kaufman] Chapters 9, 10


Download ppt "ECE454/CS594 Computer and Network Security Dr. Jinyuan (Stella) Sun Dept. of Electrical Engineering and Computer Science University of Tennessee Fall 2011."

Similar presentations


Ads by Google