Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
2.4: Authentication
• Authentication types
• Authentication schemes:
RSA, Lamport’s Hash
• Mutual Authentication
• Session Keys
• Trusted Intermediaries
Chapter 5: Security Concepts for Networks
Chapter 2.4: Authentication
Page 1
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
Chapter 2.4: Authentication
Page 2
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
Chapter 2.4: Authentication
Page 3
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
userID
salt value
password hash
alice
2758
hash(2758|passwordAlice)
Chapter 2.4: Authentication
Page 4
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Address-based Authentication
Computers are identified by hierarchical IP addresses:
Network
Subnet
Computer
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.
Chapter 2.4: Authentication
Page 5
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Cryptographic Authentication Protocols
Cryptographic authentication is much more secure than password-based or addressbased 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)
Chapter 2.4: Authentication
Page 6
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
How to do Secure Authentication?
Alice, fiddlesticks
Bob
Alice
Problems: eavesdropping and server database reading (reading password files)
• Protocol 1: protect against server database reading by only storing a hash
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
R
X
Bob
Computes X = cryptographic
function of her secret and R:
X = encr(secr, R)
Alice
I‘m Alice
Picks random R
Knows Alice‘s secret, computes
same function and compares it
to X
But: server database reading of Alice’s secret at Bob’s machine
Chapter 2.4: Authentication
Page 7
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:
Knows Alice‘s public key
R (in clear)
or publAlice(R)
R signed with Alice‘s private key
privAlice(R)
Chapter 2.4: Authentication
Bob
Alice
I‘m Alice (in clear text)
Picks random R
Checks result using
Alice‘s public key
publAlice(privAlice(R)) = R
=?
Page 8
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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:
R
If sequence numbers would be used
for R, an attacker needs only to
observe R and use R+1 to
“authenticate” with Bob!
R
Bob
Alice
KAB{R}
I’m Alice
Bob
Alice
I’m Alice
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!
Chapter 2.4: Authentication
Page 9
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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))...)))
Chapter 2.4: Authentication
Page 10
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Database
xn=hashn(password), n
Bob
Alice
Alice, password
Alice‘s Workstation
Lamport‘s Hash - Initialization
xn=hashn(password), n
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
Chapter 2.4: Authentication
Page 11
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Alice
knows <n,hashn(password)>
n
x=hashn-1(password)
Bob
Alice
Alice, password
Alice‘s Workstation
Lamport‘s Hash - Authentication
compare hash(x) to hashn(password)
if equal, replace
<n, hashn(password)> with <n-1,x>
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
Chapter 2.4: Authentication
Page 12
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
Chapter 2.4: Authentication
Page 13
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
Chapter 2.4: Authentication
Page 14
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:
KAB{R1}
R2
Bob
Alice
I’m Alice
R1
KAB{R2}
Chapter 2.4: Authentication
I‘m Alice, R2
R1,KAB{R2}
KAB{R1}
Bob
Alice
Improvement, using only 3 instead of 5 messages for authentication:
But: reflection attack
Page 15
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
I’m Alice, R1
R1,KAB{R2}
R3,KAB{R1}
Bob
I’m Alice, R2
Bob
Oscar opens a second session to Bob
and uses R1 as the challenge:
Oscar
Oscar starts the mutual authentication, but
when he receives the challenge from Bob,
he cannot proceed further because he
cannot encrypt R1:
Oscar
Reflection Attack
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
Chapter 2.4: Authentication
Page 16
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Password Guessing
I’m Alice
R1
KAB{R1}, R2
Bob
Alice
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:
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
Chapter 2.4: Authentication
Page 17
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
KAB{gRA mod p}
K{R1|0}
R1, K{R2|1}
Bob
Alice
KAB{gRB mod p}
R2
Chapter 2.4: Authentication
Page 18
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Mutual Authentication with Public Keys
R2,{R1}A
R1
Bob
Alice
I’m Alice, {R2}B
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?
Chapter 2.4: Authentication
Page 19
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 key generated at the time of authentication
Therefore, authentication protocols usually establish a session key in addition to providing
authentication
Chapter 2.4: Authentication
Page 20
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Session Key Establishment with Shared Secret
Chapter 2.4: Authentication
R2
KAB{R2}
(KAB+1){R1}{message}
Bob
Alice
KAB{R1}
Bob
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: R1 or R2) using the
modified KAB as the key, and use the result
as the session key.
Alice
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
I’m Alice
R1
Page 21
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
Chapter 2.4: Authentication
Page 22
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?
Chapter 2.4: Authentication
Page 23
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
Chapter 2.4: Authentication
Page 24
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
ticket
KDC
KKDC-Alice {KAlice-Bob}
KKDC-Bob {KAlice-Bob}
Bob
Alice
[Alice, KKDC-Alice{Key for Bob?}]
[Alice, KAlice-Bob {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
Chapter 2.4: Authentication
Page 25
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
KDC Variant
Bob
Alice wants Bob
KA{use KAB for Bob}
ticket to Bob = KB{use KAB for Alice}
KDC
Alice
On the following slides: KAB = KAlice-Bob
KA = KKDC-Alice
KB = KKDC-Bob
“I’am Alice“, ticket = KB{use KAB for Alice}
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
Chapter 2.4: Authentication
Page 26
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Needham-Schroeder
1
3
Alice
2
KA{N1, “Bob”, KAB, ticket to Bob}
where ticket to Bob = KB{KAB, “Alice”}
4
5
Chapter 2.4: Authentication
ticket, KAB{N2}
Bob
N1, Alice wants Bob
KDC
The Needham-Schroeder protocol is a classic KDC authentication protocol
(e.g. used by Kerberos):
KAB{N2-1, N3}
KAB{N3-1}
Page 27
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
Chapter 2.4: Authentication
Page 28
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
Needham-Schroeder Enhancement
I want to talk you
KA{N1, “Bob”, KAB, ticket to Bob}
where ticket to Bob = KB{KAB, “Alice”, NB}
Bob
Alice
N1, Alice wants Bob, KB{NB}
KDC
KB{NB}
ticket, KAB{N2}
KAB{N2-1, N3}
KAB{N3-1}
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
Chapter 2.4: Authentication
Page 29
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
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
Chapter 2.4: Authentication
Page 30
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
Chapter 2.4: Authentication
Page 31