Chapter 2: Security Techniques Background€¦ · Chapter 2.4: Authentication Page 5 Address-based Authentication Possible forms of authentication: • Maintain list of network addresses

Lehrstuhl für Informatik 4

Kommunikation und verteilte Systeme

Page 1Chapter 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




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




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




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

password hashsalt valueuserID




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 thecurrent node.

ComputerSubnetNetwork

Computers are identified by hierarchical IP addresses:




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)




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

Alic

e

Bob

Alice, fiddlesticksKnows hash h* of Alice‘s passwordComputes hash(fiddlesticks)

Compares it with stored value h*

But: eavesdropping of Alice’s password

• Protocol 2: protect against eavesdropping by sending encrypted passwordA

lice

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




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:

Alic

e

Bob

I‘m Alice (in clear text)

R (in clear) or publAlice(R)

R signed with Alice‘s private keyprivAlice(R)

Knows Alice‘s public key

Picks random R

Checks result using Alice‘s public keypublAlice(privAlice(R)) = R

= ?




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:

Alic

e

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!

Alic

e

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!




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




Lamport‘s Hash - InitializationA

lice

Alic

e‘s

Wor

ksta

tion

Bob

Alice, passwordxn=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 computesx1=hash(password)

x2=hash(x1), ...,

xn=hash(xn-1)=hashn(password) and sends it to Bob together with n




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 quantitywith the received quantity, and replaces n by n-1

Alic

e

Alic

e‘s

Wor

ksta

tion

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>




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, computehashn(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




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




Mutual Authentication

Often required: each of both communication partners has to identify the other one (mutualauthentication), e.g. with a shared secret:

Alic

e

Bob

I’m Alice

KAB{R1}

R1

R2

KAB{R2}

Alic

e

Bob

I‘m Alice, R2

KAB{R1}

R1,KAB{R2}

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

But: reflection attack




Reflection Attack

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

Osc

ar

Bob

I’m Alice, R2

R1,KAB{R2}

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

Osc

ar

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 -KAB or 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




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:

Alic

e

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




Bellovin-Merrit

Solution:• Alice and Bob do a Diffie-Hellman exchange, but encrypt the values they exchange• The Diffie-Hellman key is K = gRA·RB mod p

• Subsequently, they do a standard mutual authentication exchange proving each other that they know K = gRA·RB mod p

Alic

e

Bob

KAB{gRA mod p}

KAB{gRB mod p}

K{R1|0}

R1, K{R2|1}

R2




Mutual Authentication with Public Keys

Alic

e

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?




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




Session Key Establishment with Shared Secret

Alic

e

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 KABand modify it in some way, then encrypt the challenge R (here: R1 or R2) using the modified KAB as the key, and use the result as the session key.

Alic

e

Bob

(KAB+1){R1}{message}




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 R1 and Bob R2. Alice sends {R1}B to Bob. Bob sends {R2}A to Alice. The session key will R1⊕R2

→ An attacker is not able to learn R1 and R2 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




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?




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




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 securelycommunicate with it (authentication + encryption)

• Nodes ask for a temporary key (ticket) if they want to communicate with each other

Alic

e

KD

C

[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




KDC Variant

Bob

Alice wants Bob

KA{use KAB for Bob}ticket to Bob = KB{use KAB for Alice}

“I’am Alice“, ticket = KB{use KAB for Alice}

KD

C

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

Alic

e

On the following slides: KAB = KAlice-Bob

KA = KKDC-Alice

KB = KKDC-Bob




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”}

KD

C

ticket, KAB{N2}

KAB{N2-1, N3}

KAB{N3-1}

1

Alic

e

2

3

4

5




Security of Needham-Schroeder

1

2

3

4

5

• Nonce N1 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 N2 is 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 N2 only can be decrypted by him. Additionally, nonce N3 is sent as challenge for authentication by Alice

• Alice authenticates with Bob by sending back a modified nonce N3




Needham-Schroeder Enhancement

Alic

e

Bob

N1, Alice wants Bob, KB{NB}

KA{N1, “Bob”, KAB, ticket to Bob}

where ticket to Bob = KB{KAB, “Alice”, NB}

KD

C

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




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




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

Documents

Chapter 2: Security Techniques Background€¦ · Chapter 2.4: Authentication Page 5 Address-based Authentication Possible forms of authentication: • Maintain list of network addresses