Page 1 Chapter 2.4: Authentication
2.4: Authentication
• Authentication types
• Authentication schemes:
RSA, Lamport’s Hash
• Mutual Authentication
• Session Keys
• Trusted Intermediaries 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
Page 2 Chapter 2.4: Authentication
Authentication Types
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
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Password-based Authentication
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
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Off-Line Password Guessing
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
hash(2758|passwordAlice) 2758
alice
password hash salt value
userID
Page 5 Chapter 2.4: Authentication
Address-based Authentication
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.
Computer Subnet
Network
Computers are identified by hierarchical IP addresses:
Page 6 Chapter 2.4: Authentication
Cryptographic Authentication Protocols
Cryptographic authenticationis much more secure than password-based or address- based authentication
• Alice proves her identity to Bob by performing a cryptographic operation on a quantity provided by Bob
• The cryptographic operation is based on Alice’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)
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme How to do Secure Authentication?
Problems: eavesdroppingand server database reading(reading password files)
• Protocol 1: protect against server database reading by only storing a hash
Alice BobAlice, fiddlesticks Knows hash h* of Alice‘s password Computes hash(fiddlesticks) Compares it with stored value h*
But: eavesdropping of Alice’s password
• Protocol 2: protect against eavesdropping by sending encrypted password
Alice Bob
I‘m Alice R X
Picks random R
Knows Alice‘s secret, computes same function and compares it to X
Computes X = cryptographic function of her secret and R:
X = encr(secr, R)
But: server database reading of Alice’s secret at Bob’s machine
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Authentication with RSA
Public key technology protects authentication against eavesdropping and server database reading
Widely used: challenge/response
Example: Alice authenticates herself to Bob
• Using her private key privAlice, Alice performs a cryptographic operation on a value (challenge) R supplied by Bob:
Alice Bob
I‘m Alice (in clear text)
R (in clear) or publAlice(R) R signed with Alice‘s private key privAlice(R)
Knows Alice‘s public key
Picks random R Checks result using Alice‘s public key publAlice(privAlice(R)) = R
= ?
Page 9 Chapter 2.4: Authentication
Nonce
Important: use the challenge R only once!
• A nonceis a challenge only used once
• Use e.g. a random number, a timestamp, …
• The unpredictability of R is important:
Alice Bob
I’m Alice
R KAB{R}
If sequence numbers would be used for R, an attacker needs only to observe R and use R+1 to
“authenticate” with Bob!
Alice Bob
I’m Alice R KAB{R}
If sequence numbers would be used for R, a man-in-the-middle attacker could send R+1 to Alice and use the response to authenticate with Bob
→use unpredictable numbers!
Page 10 Chapter 2.4: Authentication
Lamport‘s Hash
Other possibility for authentication: Lamport‘s Hash One-time password scheme:
• Allows Bob to authenticate Alice in a way that neither eavesdropping reading Bob’s database enables someone to impersonate Alice
• No need for public key cryptograph Requirements:
• Alice remembers a password, Alice is a human
• Bob (the server) has a database; for each user it stores:
username
n, decremented each time the user authenticates herself
hashn(Password), i.e. hash(hash(...(hash(Password))...)))
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Lamport‘s Hash - Initialization
Alice Alice‘s Workstation Bob
Alice, password
xn=hashn(password), n
xn=hashn(password), n Database
Initialization of a password:
• Alice chooses a password
• The workstation of Alice chooses the number n and computes x1=hash(password)
x2=hash(x1), ...,
xn=hash(xn-1)=hashn(password) and sends it to Bob together with n
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Lamport‘s Hash - Authentication
Authentication of a user:
• Alice enters her username and password
• Her workstation sends the name to Bob which returns n
• The workstation computes hashn-1(password) and sends the result to Bob
• Bob takes the received value, hashes it once, and compares it with its database
• In case of a match, Bob considers the response as valid, replaces the stored quantity with the received quantity, and replaces n by n-1
Alice Alice‘s Workstation Bob
Alice, password Alice
n
x=hashn-1(password)
knows <n,hashn(password)>
compare hash(x) to hashn(password) if equal, replace
<n, hashn(password)> with <n-1,x>
Page 13 Chapter 2.4: Authentication
Lamport‘s Hash
Setting up a new password:
• If n = 1 Alice needs to set her password again
• In many situations it is sufficient to choose a new password, compute hashn(new password), and transmit hashn(new password) and n to Bob
• 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 Alice 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
Page 14 Chapter 2.4: Authentication
Small n Attack
Worst weakness of Lamport‘s Hash:
• Oscar, who is able to impersonate Bob’s network address, waits for Alice’s log-in
• When Alice attempts to log in, Oscar returns a small value for n, e.g. 50
• When Alice responds with hash50(password), Oscar has enough information to impersonate Alice for some time, if the actual value of n at Bob is greater than 50 Two possible solutions:
• Human and Paper environment:
When <n, hashn(password)> is installed at the server, all values of hashi(password) for i < n are computed, encoded into a typeable string, printed on paper, and given to Alice
When Alice 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:
Alice’s workstation displays n to the human Alice
If Alice remembers approximately what n should be she can at least do a rough probability check on n
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Mutual Authentication
Often required: each of both communication partners has to identify the other one (mutual authentication), e.g. with a shared secret:
Alice Bob
I’m Alice
KAB{R1} R1
R2 KAB{R2}
Alice Bob
I‘m Alice, R2
KAB{R1} R1,KAB{R2}
Improvement, using only 3 instead of 5 messages for authentication:
But: reflection attack
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Reflection Attack
Oscar starts the mutual authentication, but when he receives the challenge from Bob, he cannot proceed further because he
cannot encrypt R1: Oscar Bob
I’m Alice, R2 R1,KAB{R2}
Oscar opens a second session to Bob and uses R1as the challenge:
Oscar Bob
I’m Alice, R1 R3,KAB{R1}
Oscar cannot continue this session because he cannot encrypt R3, but he knows KAB{R1}, so he can complete the first session
Countermeasures: “don’t have Alice and Bob do exactly the same thing”
• Different-keys: the key used to authenticate Alice should be different from the key used to authenticate Bob. For example: Bob’s key might be -KABor KAB+1 or …
• Different-challenges: the initiator’s challenge must be different from the one of the responder. For example, use Bob|R as challenge
Page 17 Chapter 2.4: Authentication
Password Guessing
Other problem: Oscar can mount an off-line password-guessing attack without need to eavesdrop:
• Oscar has to send a message to Bob claiming to be Alice
• Bob will obligingly return the encrypted value
• Then Oscar has the pair <R, KAB{R}> which he can use to check password guesses
• This weakness can fixed by adding another message, forcing Alice to send an encrypted value first:
Alice Bob
I’m Alice
KAB{R1}, R2 R1
KAB{R2}
But still: an attacker listening to the communication can learn <R, KAB{R}> pairs, and could try an off-line attack guessing passwords to derive KAB
Page 18 Chapter 2.4: Authentication
Bellovin-Merrit
Solution:
• Alice and Bob do a Diffie-Hellman exchange, but encrypt the values they exchange
• The Diffie-Hellman key is K = gRA·RBmod p
• Subsequently, they do a standard mutual authentication exchange proving each other that they know K = gRA·RBmod p
Alice Bob
KAB{gRAmod p}
KAB{gRBmod p}
K{R1|0}
R1, K{R2|1}
R2
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Mutual Authentication with Public Keys
Alice Bob
I’m Alice, {R2}B
R1 R2,{R1}A
Mutual authentication can also be done with public key technology, assuming that Bob and Alice know each other’s public key.
Problems:
• How does Alice know Bob’s public key?
• How could Alice’s workstation obtain Alice’s private key when a password is all Alice knows?
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Session Key Establishment
There are still security vulnerabilities after authentication:
• After the authentication between Alice and Bob, 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 keygenerated at the time of authentication
Therefore, authentication protocols usually establish a session key in addition to providing authentication
Page 21 Chapter 2.4: Authentication
Session Key Establishment with Shared Secret
Alice Bob
I’m Alice
KAB{R1} R1
R2 KAB{R2} Go back to first scheme for mutual
authentication: having a shared key KAB
→ Re-use the shared key in a modified way as session key
There is sufficient information in this protocol for Alice and Bob to establish a shared session key at this point:
• For example, they can use (KAB+1){R}.
• In general: Take the shared secret KAB and modify it in some way, then encrypt the challenge R (here: R1or R2) using the modified KABas the key, and use the result as the session key.
Alice Bob
(KAB+1){R1}{message}
Page 22 Chapter 2.4: Authentication
Session Key Establishment with Public Keys
There are several methods to establish session keys with public keys:
• Alice chooses a random number R, encrypts it with Bob’s public key, and sends {R}Bto Bob, attached to one of the messages in the authentication exchange
→ An attacker could hijack the conversation by picking his own R, encrypting it with Bob’s public key, and sending it to Bob
• Alice can additionally sign the result. In this case, she sends [{R}B]Ato Bob. Bob first has to verify Alice’s signature before decrypting R
→ The attacker could record the entire conversation between Alice and Bob.
If he can later take over Bob he will be able to decrypt the conversation
• Additionally, Alice picks R1and Bob R2. Alice sends {R1}Bto Bob. Bob sends {R2}Ato Alice. The session key will R1⊕R2
→An attacker is not able to learn R1and R2only by overtaking Bob or Alice
• Alice and Bob can do a Diffie-Hellman key establishment exchange, where every partner signs the quantity he is sending
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Session Key Establishment with Lamport’s Hash
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 Alice and Bob
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?
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Trusted Intermediaries
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 25 Chapter 2.4: Authentication
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
Alice KDC
[Alice, KKDC-Alice{Key for Bob?}]
KKDC-Alice{KAlice-Bob}
Bob
KKDC-Bob{KAlice-Bob}
[Alice, KAlice-Bob{message}]
ticket
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 26 Chapter 2.4: Authentication
KDC Variant
Bob
Alice wants Bob KA{use KABfor Bob}
ticket to Bob = KB{use KABfor Alice}
“I’am Alice“, ticket = KB{use KABfor Alice}
KDC
KDC operation in practice (improvement of the previous protocol):
• The KDC gives Alice the information it would have sent to Bob (the ticket)
• The ticket holds information that will allow Alice to access Bob
• This prevents e.g. problems with message runtimes, if Alice connection attempt comes to early for Bob to have received the shared key from KDC
Alice
On the following slides: KAB= KAlice-Bob KA = KKDC-Alice KB = KKDC-Bob
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Needham-Schroeder
The Needham-Schroeder protocol is a classic KDC authentication protocol (e.g. used by Kerberos):
Bob
N1, Alice wants Bob KA{N1, “Bob”, KAB, ticket to Bob}
where ticket to Bob = KB{KAB, “Alice”}
KDC
ticket, KAB{N2} KAB{N2-1, N3}
KAB{N3-1}
1
Alice
2
3 4 5
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme Security of Needham-Schroeder
1
2
3
4
5
• Nonce N1is used to prove that Alice is really talking to the KDC, not to an attacker who had listened to a KDC answer before and replies to Alice with this answer
• The string “Bob” is filled in to avoid that an attacker Oscar has intercepted message 1 and substituted “Bob” with “Oscar”, to make the KDC generating a key between Alice and Oscar (and sending back this key to Alice who thinks to have a key with Bob)
• Nonce N2is sent to Bob along with the ticket, and only someone being able to decrypt Bob’s ticket is able to decrypt N2
• Bob proves to be himself answering with N2-1 because N2only can be
decrypted by him. Additionally, nonce N3is sent as challenge for authentication by Alice
• Alice authenticates with Bob by sending back a modified nonce N3
Page 29 Chapter 2.4: Authentication
Needham-Schroeder Enhancement
Alice Bob
N1, Alice wants Bob, KB{NB} KA{N1, “Bob”, KAB, ticket to Bob}
where ticket to Bob = KB{KAB, “Alice”, NB} KDC ticket, KAB{N2}
KAB{N2-1, N3} KAB{N3-1}
I want to talk you KB{NB}
Fix a security hole:
• If an attacker finds out Alice’s key he can claim to be Alice and obtain from the KDC a shared key with, and a ticket to, Bob
• The problem with the original protocol is that the ticket to Bob remains valid even if Alice changes her key
• The additional nonce NBproves for Bob that the key KABwas newly generated
Page 30 Chapter 2.4: Authentication
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 (Alice) and a signature of a CA:
[Alice, privCA(publAlice)]
→ CAs are the public key equivalent of KDCs
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme 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
