2.4: Authentication Authentication types Authentication schemes: RSA, Lamport s Hash Mutual Authentication Session Keys Trusted Intermediaries

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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

Page 3 Chapter 2.4: Authentication

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

Page 4 Chapter 2.4: Authentication

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|password_Alice) 2758

alice

password hash salt value

userID

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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:

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 6 Chapter 2.4: Authentication

Cryptographic Authentication Protocols

Cryptographic authentication is 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

Page 7 Chapter 2.4: Authentication

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

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

Page 8 Chapter 2.4: Authentication

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 priv_Alice, 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 publ_Alice(R)

R signed with Alice‘s private key priv_Alice(R)

Knows Alice‘s public key

Picks random R

Checks result using Alice‘s public key

publ_Alice(priv_Alice(R)) = R

= ?

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 9 Chapter 2.4: Authentication

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:

Alice Bob

I’m Alice

R K_AB{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 K_AB{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!

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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

hashⁿ(Password), i.e. hash(hash(...(hash(Password))...)))

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 11 Chapter 2.4: Authentication

Lamport‘s Hash - Initialization

Alice Alice‘s Workstation Bob

Alice, password

x_n=hashⁿ(password), n

x_n=hashⁿ(password), n Database

Initialization of a password:

• Alice chooses a password

• The workstation of Alice chooses the number n and computes x₁=hash(password)

x₂=hash(x₁), ...,

x_n=hash(x_n-1)=hashⁿ(password) and sends it to Bob together with n

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 12 Chapter 2.4: Authentication

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 hash^n-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=hash^n-1(password)

knows <n,hashⁿ(password)>

compare hash(x) to hashⁿ(password) if equal, replace

<n, hashⁿ(password)> with <n-1,x>

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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 hashⁿ(new password), and transmit hashⁿ(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

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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 hash⁵⁰(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, hashⁿ(password)> is installed at the server, all values of hashⁱ(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

Page 15 Chapter 2.4: Authentication

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

K_AB{R₁} R₁

R₂ K_AB{R₂}

Alice Bob

I‘m Alice, R₂

K_AB{R₁} R₁,K_AB{R₂}

Improvement, using only 3 instead of 5 messages for authentication:

But: reflection attack

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 16 Chapter 2.4: Authentication

Reflection Attack

Oscar starts the mutual authentication, but when he receives the challenge from Bob, he cannot proceed further because he

cannot encrypt R₁: Oscar Bob

I’m Alice, R₂ R₁,K_AB{R₂}

Oscar opens a second session to Bob and uses R₁ as the challenge:

Oscar Bob

I’m Alice, R₁ R₃,K_AB{R₁}

Oscar cannot continue this session because he cannot encrypt R₃, but he knows K_AB{R₁}, 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 -K_AB or K_AB+1 or …

• Different-challenges: the initiator’s challenge must be different from the one of the responder. For example, use Bob|R as challenge

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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, K_AB{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

K_AB{R₁}, R₂ R₁

K_AB{R₂}

But still: an attacker listening to the communication can learn <R, K_AB{R}> pairs, and could try an off-line attack guessing passwords to derive K_AB

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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

Alice Bob

K_AB{g^RA mod p}

K_AB{g^RB mod p}

K{R₁|0}

R₁, K{R₂|1}

R₂

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 19 Chapter 2.4: Authentication

Mutual Authentication with Public Keys

Alice Bob

I’m Alice, {R₂}_B

R₁ R₂,{R₁}_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

Page 20 Chapter 2.4: Authentication

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 key generated at the time of authentication

Therefore, authentication protocols usually establish a session key in addition to providing authentication

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 21 Chapter 2.4: Authentication

Session Key Establishment with Shared Secret

Alice Bob

I’m Alice

K_AB{R₁} R₁

R₂ K_AB{R₂} Go back to first scheme for mutual

authentication: having a shared key K_AB

→ 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 (K_AB+1){R}.

• In general: Take the shared secret K_AB and modify it in some way, then encrypt the challenge R (here: R₁ or R₂) using the modified K_AB as the key, and use the result as the session key.

Alice Bob

(K_AB+1){R₁}{message}

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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}_B to 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]_A to 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 R₁ and Bob R₂. Alice sends {R₁}_B to Bob. Bob sends {R₂}_A to Alice. The session key will R₁⊕R₂

→ An attacker is not able to learn R₁ and R₂ only 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

Page 23 Chapter 2.4: Authentication

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

Page 24 Chapter 2.4: Authentication

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

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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, K_KDC-Alice{Key for Bob?}]

K_KDC-Alice {K_Alice-Bob}

Bob

K_KDC-Bob {K_Alice-Bob}

[Alice, K_Alice-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

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 26 Chapter 2.4: Authentication

KDC Variant

Bob

Alice wants Bob K_A{use K_AB for Bob}

ticket to Bob = K_B{use K_AB for Alice}

“I’am Alice“, ticket = K_B{use K_AB for 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: K_AB = K_Alice-Bob K_A = K_KDC-Alice K_B = K_KDC-Bob

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 27 Chapter 2.4: Authentication

Needham-Schroeder

The Needham-Schroeder protocol is a classic KDC authentication protocol (e.g. used by Kerberos):

Bob

N₁, Alice wants Bob

K_A{N₁, “Bob”, K_AB, ticket to Bob}

where ticket to Bob = K_B{K_AB, “Alice”} KDC ticket, K_AB{N₂}

K_AB{N₂-1, N₃} K_AB{N₃-1}

1

Alice

2

3 4 5

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 28 Chapter 2.4: Authentication

Security of Needham-Schroeder

1

2

3 4

5

• Nonce N₁ is 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 N₂ is sent to Bob along with the ticket, and only someone being able to decrypt Bob’s ticket is able to decrypt N₂

• Bob proves to be himself answering with N₂-1 because N₂ only can be

decrypted by him. Additionally, nonce N₃ is sent as challenge for authentication by Alice

• Alice authenticates with Bob by sending back a modified nonce N₃

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 29 Chapter 2.4: Authentication

Needham-Schroeder Enhancement

Alice Bob

N₁, Alice wants Bob, K_B{N_B}

K_A{N₁, “Bob”, K_AB, ticket to Bob}

where ticket to Bob = K_B{K_AB, “Alice”, N_B} KDC ticket, K_AB{N₂}

K_AB{N₂-1, N₃} K_AB{N₃-1}

I want to talk you K_B{N_B}

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 N_B proves for Bob that the key K_AB was newly generated

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

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

Page 31 Chapter 2.4: Authentication

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