Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme
Chapter 2: Security Techniques Background • Secret Key Cryptography 2.4: Authentication • Public Key Cryptography • Authentication types • Hash Functions • Authentication schemes: • Authentication RSA, Lamport’s Hash Chapter 3: Security on • Mutual Authentication Network and Transport Layer • Session Keys • Trusted Intermediaries Chapter 4: Security on the Application Layer 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 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)
Chapter 2.4: Authentication Page 6 Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme
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
Knows hash h* of Alice‘s password e
Alice, fiddlesticks b
c
i o
l Computes hash(fiddlesticks) B A Compares it with stored value h*
But: eavesdropping of Alice’s password
• Protocol 2: protect against eavesdropping by sending encrypted password I‘m Alice
Picks random R e
R b
c i Computes X = cryptographic o
l Knows Alice‘s secret, computes B function of her secret and R: A same function and compares it X X = encr(secr, R) 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
I‘m Alice (in clear text) e
R (in clear) b Picks random R
c
i
o
l B A or publAlice(R) Checks result using = ? R signed with Alice‘s private key Alice‘s public key
privAlice(R) publAlice(privAlice(R)) = R
Chapter 2.4: Authentication 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:
I’m Alice I’m Alice
KAB{R} R Bob Bob Alice Alice R KAB{R}
If sequence numbers would be used If sequence numbers would be used for R, for R, an attacker needs only to a man-in-the-middle attacker could send observe R and use R+1 to R+1 to Alice and use the response to “authenticate” with Bob! 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
Lamport‘s Hash - Initialization
Alice, password n Database xn=hash (password), n
n
Bob x =hash (password), n Alice n Alice‘s Workstation
Initialization of a password: • Alice chooses a password • The workstation of Alice chooses the number n and computes
x1=hash(password)
x2=hash(x1), ..., n xn=hash(xn-1)=hash (password) and sends it to Bob together with n
Chapter 2.4: Authentication Page 11 Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme
Lamport‘s Hash - Authentication
Alice, password Alice knows
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: •Ifn = 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
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: I’m Alice
R1
KAB{R1} Bob Alice R2
KAB{R2}
Improvement, using only 3 instead of 5 messages for authentication:
I‘m Alice, R2
R1,KAB{R2} Bob Alice K {R } AB 1 But: reflection attack
Chapter 2.4: Authentication Page 15 Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme
Reflection Attack
Oscar starts the mutual authentication, but I’m Alice, R when he receives the challenge from Bob, 2
he cannot proceed further because he R1,KAB{R2} Bob Oscar cannot encrypt R1:
Oscar opens a second session to Bob I’m Alice, R1 and uses R1 as the challenge: R3,KAB{R1} Bob Oscar
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
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
I’m Alice
R1 K {R }, R
AB 1 2 Bob Alice
KAB{R2}
But still: an attacker listening to the communication can learn
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
RA KAB{g mod p} RB KAB{g mod p}
K{R1|0} Bob Alice R1, K{R2|1}
R2
Chapter 2.4: Authentication Page 18 Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme
Mutual Authentication with Public Keys
I’m Alice, {R2}B
R2,{R1}A Bob Alice R1
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
I’m Alice
Go back to first scheme for mutual R1 authentication: having a shared key K AB KAB{R1} Bob
→ Alice Re-use the shared key in a modified way R as session key 2 KAB{R2}
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}. (KAB+1){R1}{message} Bob • In general: Take the shared secret KAB Alice 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.
Chapter 2.4: Authentication 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
[Alice, KKDC-Alice{Key for Bob?}]
C
D K KKDC-Bob {KAlice-Bob}
KKDC-Alice {KAlice-Bob}
e
b
c
i
o
l
B A
[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
On the following slides: KAB = KAlice-Bob
KA = KKDC-Alice
KB = KKDC-Bob
Alice wants Bob
KA{use KAB for Bob} KDC ticket to Bob = KB{use KAB for Alice} Bob Alice “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
The Needham-Schroeder protocol is a classic KDC authentication protocol (e.g. used by Kerberos):
N , Alice wants Bob 1 1 KA{N1, “Bob”, KAB, ticket to Bob} 2 KDC where ticket to Bob = KB{KAB, “Alice”}
ticket, KAB{N2} Bob 3 Alice K {N -1, N } 4 AB 2 3 K {N -1} 5 AB 3
Chapter 2.4: Authentication Page 27 Lehrstuhl für Informatik 4 Kommunikation und verteilte Systeme
Security of Needham-Schroeder
• Nonce N1 is used to prove that Alice is really talking to the KDC, not to an 1 attacker who had listened to a KDC answer before and replies to Alice with this answer 2 • 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 3 2 decrypt Bob’s ticket is able to decrypt N2 • Bob proves to be himself answering with N -1 because N only can be 4 2 2 decrypted by him. Additionally, nonce N3 is sent as challenge for authentication by Alice
5 • 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
KB{NB}
N1, Alice wants Bob, KB{NB}
KA{N1, “Bob”, KAB, ticket to Bob} KDC where ticket to Bob = KB{KAB, “Alice”, NB} Bob Alice
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