Authentication Types. Password-based Authentication. Off-Line Password Guessing

Transcription

1 Authentication Types Chapter 2: Security Techniques Background Secret Key Cryptography Public Key Cryptography Hash Functions Authentication Chapter 3: Security on Network and Transport Layer Chapter 4: Security on the Application Layer Chapter 5: Security Concepts for Networks 2.4: Authentication Authentication types Authentication schemes: RSA, Lamport s Hash Mutual Authentication Session Keys Trusted Intermediaries Authentication can be the process of reliably verifying the identity of a user, a computer, or both computer and user. Forms of authentication (combinations are possible): password-based address-based cryptographic Page 1 Page 2 Password-based Authentication Off-Line Password Guessing Simple: people log into a computer by typing a user name and a password Problems with using passwords for authentication: The user himself/herself Eavesdroppers might see the password when careless users log in The password might be easy to guess (on-line attack) because users choose passwords they can remember easily Attempts to force users to choose unguessable passwords might render the system so inconvenient that users write down passwords Password management For login, the system has to know the valid passwords they are stored in an own file. An attacker might read the system file with the password information Thus: encrypt stored password information Store hashes of passwords Encrypt the stored passwords Combination: Encrypt a database of hashed passwords But: the password may be cracked by an off-line attack A common approach is to store a hash of the password (as e.g. within UNIX) An attacker can obtain a cryptographic hash of the password through either eavesdropping or reading a database The attacker can guess a password calculating the same hash and comparing it with the stolen value (e.g. Dictionary attack) Approach to slow down an attacker: When choosing a password, the system chooses a random number (salt) The system stores the salt and a hash of the combination of the stored salt and the chosen password userid alice salt value 2758 password hash hash(2758 password ) Page 3 Page 4

2 Address-based Authentication Cryptographic Authentication Protocols Computers are identified by hierarchical IP addresses: Network Possible forms of authentication: Maintain list of network addresses of equivalent machines, i.e., give users who have access to machine X the same access rights for machine Y Problem: user must have identical account names on all systems Extension: store entry: remote address, remote account name, local account name Implementation e.g. in UNIX: /etc/hosts.equiv file contains list of computers that have identical user account assignments.rhosts file in a user s home directory contains a list of tuples computer, account that are granted access to this user s account But: if someone gains privileged access to a node, he can access all users resources on this node. He can also get access to other machines accessable by users of the current node. Subnet Computer Page 5 Cryptographic authentication is much more secure than password-based or addressbased authentication proves her identity to by performing a cryptographic operation on a quantity provided by The cryptographic operation is based on s secret A computer can do cryptographic operations on behalf of its user: The user only has to remember a password The system has to obtain a cryptographic key based on the password by: doing a hash of the password using the password to decrypt a higher-quality key (e.g. DES key, RSA private key) Keys and cryptographic algorithms e.g. can be stored on a smart card (authentication token) Page 6 How to do Secure Authentication? Problems: eavesdropping and server database reading (reading password files) Protocol 1: protect against server database reading by only storing a hash, fiddlesticks But: eavesdropping of s password Knows hash h* of s password Computes hash(fiddlesticks) Compares it with stored value h* Protocol 2: protect against eavesdropping by sending encrypted password Computes X = cryptographic function of her secret and R: X = encr(secr, R) I m But: server database reading of s secret at s machine R X Picks random R Knows s secret, computes same function and compares it to X Authentication with RSA Public key technology protects authentication against eavesdropping and server database reading Widely used: challenge/response Example: authenticates herself to Using her private key priv, performs a cryptographic operation on a value (challenge) R supplied by : I m (in clear text) R (in clear) or publ (R) R signed with s private key priv (R) Knows s public key Picks random R Checks result using s public key publ (priv (R)) = R =? Page 7 Page 8

3 Nonce Important: use the challenge R only once! A nonce is a challenge only used once Use e.g. a random number, a timestamp, The unpredictability of R is important: I m {R R If sequence numbers would be used for R, an attacker needs only to observe R and use R+1 to authenticate with! I m R {R If sequence numbers would be used for R, a man-in-the-middle attacker could send R+1 to and use the response to authenticate with Lamport s Hash Other possibility for authentication: Lamport s Hash One-time password scheme: Allows to authenticate in a way that neither eavesdropping reading s database enables someone to impersonate No need for public key cryptograph Requirements: remembers a password, is a human (the server) has a database; for each user it stores: username n, decremented each time the user authenticates herself hash n (Password), i.e. hash(hash(...(hash(password))...))) use unpredictable numbers! Page 9 Page 10 Lamport s Hash - Initialization Lamport s Hash - Authentication, password s Workstation x n =hash n (password), n Database x n =hash n (password), n, password s Workstation n x=hash n-1 (password) knows <n,hash n (password)> compare hash(x) to hash n (password) if equal, replace <n, hash n (password)> with <n-1,x> Initialization of a password: chooses a password The workstation of chooses the number n and computes x 1 =hash(password) x 2 =hash(x 1 ),..., x n =hash(x n-1 )=hash n (password) and sends it to together with n Authentication of a user: enters her username and password Her workstation sends the name to which returns n The workstation computes hash n-1 (password) and sends the result to takes the received value, hashes it once, and compares it with its database In case of a match, considers the response as valid, replaces the stored quantity with the received quantity, and replaces n by n-1 Page 11 Page 12

4 Lamport s Hash Setting up a new password: Ifn = 1 needs to set her password again In many situations it is sufficient to choose a new password, compute hash n (new password), and transmit hash n (new password) and n to An enhancement is to add a salt value to the password, with the same advantages as in password storage like e.g. in UNIX Another advantage of salt is that will not need to change her password if n = 1 Properties: Similar to public key schemes regarding database reading But: user can only log-in a finite number of times before having to re-install the password at the server Problem: small n attack Small n Attack Worst weakness of Lamport s Hash: Oscar, who is able to impersonate s network address, waits for s log-in When attempts to log in, Oscar returns a small value for n, e.g. 50 When responds with hash 50 (password), Oscar has enough information to impersonate for some time, if the actual value of n at is greater than 50 Two possible solutions: Human and Paper environment: When <n, hash n (password)> is installed at the server, all values of hash i (password) for i < n are computed, encoded into a typeable string, printed on paper, and given to When logs in, she uses the string at the top of the page, crosses that value, and uses the next value the next time Workstation environment: s workstation displays n to the human If remembers approximately what n should be she can at least do a rough probability check on n Page 13 Page 14 Mutual Authentication Reflection Attack Often required: each of both communication partners has to identify the other one (mutual authentication), e.g. with a shared secret: I m { R 2 Improvement, using only 3 instead of 5 messages for authentication: I m, R 2, { But: reflection attack Oscar starts the mutual authentication, but when he receives the challenge from, he cannot proceed further because he cannot encrypt : Oscar opens a second session to and uses as the challenge: Oscar Oscar I m, R 2, I m, R 3, { Oscar cannot continue this session because he cannot encrypt R 3, but he knows {, so he can complete the first session Countermeasures: don t have and do exactly the same thing Different-keys: the key used to authenticate should be different from the key used to authenticate. For example: s key might be - or +1 or Different-challenges: the initiator s challenge must be different from the one of the responder. For example, use R as challenge Page 15 Page 16

5 Password Guessing Bellovin-Merrit Other problem: Oscar can mount an off-line password-guessing attack without need to eavesdrop: Oscar has to send a message to claiming to be will obligingly return the encrypted value Then Oscar has the pair <R, {R> which he can use to check password guesses This weakness can fixed by adding another message, forcing to send an encrypted value first: I m {, R 2 Solution: and do a Diffie-Hellman exchange, but encrypt the values they exchange The Diffie-Hellman key is K = g RA RB mod p Subsequently, they do a standard mutual authentication exchange proving each other that they know K = g RA RB mod p {g RA mod p {g RB mod p K{ 0, K 1 R 2 But still: an attacker listening to the communication can learn <R, {R> pairs, and could try an off-line attack guessing passwords to derive Page 17 Page 18 Mutual Authentication with Public Keys Session Key Establishment I m, B R 2,{ A Mutual authentication can also be done with public key technology, assuming that and know each other s public key. Problems: How does know s public key? How could s workstation obtain s private key when a password is all knows? There are still security vulnerabilities after authentication: After the authentication between and, data integrity checks and/or message encryption is done during communication using secret key cryptography Keys wear out if used a lot. The more encrypted data an attacker has the better his chances of finding the key It might be possible for an intruder to record messages from a previous conversation and inject those packets into a current conversation If the long-term shared secret key were compromised, it would be desirable to prevent an old recorded conversation from being decrypted Keys could be stored by a communication partner for future misuse use a secret per-session key generated at the time of authentication Therefore, authentication protocols usually establish a session key in addition to providing authentication Page 19 Page 20

6 Session Key Establishment with Shared Secret Session Key Establishment with Public Keys Go back to first scheme for mutual authentication: having a shared key Re-use the shared key in a modified way as session key I m { R 2 There are several methods to establish session keys with public keys: chooses a random number R, encrypts it with s public key, and sends {R B to, attached to one of the messages in the authentication exchange An attacker could hijack the conversation by picking his own R, encrypting it with s public key, and sending it to There is sufficient information in this protocol for and to establish a shared session key at this point: For example, they can use ( +1){R. In general: Take the shared secret and modify it in some way, then encrypt the challenge R (here: or R 2 ) using the modified as the key, and use the result as the session key. ( +1){ {message can additionally sign the result. In this case, she sends [{R B ] A to. first has to verify s signature before decrypting R The attacker could record the entire conversation between and. If he can later take over he will be able to decrypt the conversation Additionally, picks and R 2. sends { B to. sends A to. The session key will R 2 An attacker is not able to learn and R 2 only by overtaking or and can do a Diffie-Hellman key establishment exchange, where every partner signs the quantity he is sending Page 21 Page 22 Session Key Establishment with Lamport s Hash Trusted Intermediaries With Lamport s Hash neither side has a public key, and they do not have a shared secret key. Nevertheless, there are several possibilities to establish a shared session key: They can first do the authentication handshake, and then a Diffie-Hellman exchange to establish a session key An attacker could hijack the conversation after the initial authentication and before the Diffie-Hellman exchange They can do a Diffie-Hellman exchange first, and then do the authentication handshake as part of a conversation protected with the Diffie-Hellman key An attacker could do a bucket-brigade attack, establishing a separate Diffie-Hellman key with both and Secret or public key technology seem to be more secure but a general problem remains: how to get a public key of or a shared key with a possible communication partner? Assume that network security is based on secret key technology Consider a large network with n nodes. Each computer may need to authenticate each other computer each computer needs to know n-1 keys Adding a new node would cause generation of n keys, as the new node needs to have a shared secret with each other node The keys would have to be securely (i.e. encrypted) distributed to all the other nodes e.g. by public key schemes Possibilities Key Distribution Center (KDC) for secret keys Certification Authorities (CAs) for public key schemes Multiple Trusted Intermediaries extended (mesh) structure if the networks (and thus the KDCs/CAs) become too large Page 23 Page 24

7 KDC Key Distribution Center (KDC) The KDC holds a database with keys for all nodes A new node registers with the KDC; any node registered with the KDC can securely communicate with it (authentication + encryption) Nodes ask for a temporary key (ticket) if they want to communicate with each other KDC Variant On the following slides: = K - K A = K KDC- K B = K KDC- [, K KDC- {Key for?] K KDC- {K - ticket K KDC- {K - wants K A {use for ticket to = K B {use for KDC I am, ticket = K B {use for [, K - {message] Disadvantages of KDCs: KDC has enough information to impersonate all nodes and users (vulnerability) KDC is a single point of failure - if it goes down, nobody can use anything on the network KDC might be a performance bottleneck for large number of users Page 25 KDC operation in practice (improvement of the previous protocol): The KDC gives the information it would have sent to (the ticket) The ticket holds information that will allow to access This prevents e.g. problems with message runtimes, if connection attempt comes to early for to have received the shared key from KDC Page 26 Needham-Schroeder Security of Needham-Schroeder The Needham-Schroeder protocol is a classic KDC authentication protocol (e.g. used by Kerberos): N 1, wants K A {N 1,,, ticket to where ticket to = K B {, ticket, {N 2 {N 2-1, N 3 {N 3-1 KDC Nonce N 1 is used to prove that is really talking to the KDC, not to an attacker who had listened to a KDC answer before and replies to with this answer The string is filled in to avoid that an attacker Oscar has intercepted message 1 and substituted with Oscar, to make the KDC generating a key between and Oscar (and sending back this key to who thinks to have a key with ) Nonce N 2 is sent to along with the ticket, and only someone being able to decrypt s ticket is able to decrypt N 2 proves to be himself answering with N 2-1 because N 2 only can be decrypted by him. Additionally, nonce N 3 is sent as challenge for authentication by authenticates with by sending back a modified nonce N 3 Page 27 Page 28

8 Needham-Schroeder Enhancement I want to talk you K B {N B N 1, wants, K B {N B K A {N 1,,, ticket to where ticket to = K B {,, N B ticket, {N 2 {N 2-1, N 3 {N 3-1 Fix a security hole: If an attacker finds out s key he can claim to be and obtain from the KDC a shared key with, and a ticket to, The problem with the original protocol is that the ticket to remains valid even if changes her key The additional nonce N B proves for that the key was newly generated KDC Page 29 Certification Authorities (CAs) Key distribution is easier with public key cryptography: Each node knows its own private key, and the public keys can be obtained from a central entity Problem: How to be sure that the public key information is correct? Solution: Establish a trusted node, a Certification Authority (CA), to generate certificates Certificates consist of a public key, a name () and a signature of a CA: [, privca(publ)] CAs are the public key equivalent of KDCs Page 30 Certification Authorities (CAs) Advantages of CAs (compared to KDCs) The CA does not need to be on-line, key exchange may be done by e.g. smart cards Since the CA does not have to be on-line, a comparably simple device can be employed If the CA crashes, the network is still usable, but the installation of new user is impossible One cannot write bogus certificates as only the CA generate signatures A corrupt CA cannot decrypt conversations Disadvantages of CAs Once a certificate has been issued it is difficult to revoke it if the CA is not online As a first solution, a certificate is valid only for a specified time Better solution (similar to credit cards): Publish a list of all revoked certificates Certificate Revocation List (CRL) The CRLs will be distributed periodically A certificate is valid if it has a valid CA signature and is not listed on the CRL Page 31