Part 2 – Authentication
This is the second part in a list of cheatsheets based on the book Network Security: Private Communications in a Public World (2nd Edition).
This post is about authentication. The first part, Cryptography Introduction Cheatsheet – part 1, was about cryptography.
Authentication services
Authentication is the process of reliably identifying the identity of someone.
- Password based authentication happens via a secret quantity. The biggest drawback is eavesdropping. Guessing the password can happen online or offline. Offline attacks are possible if the attacker captured a quantity X and then the attacker can guess unlimited. This is also referred to as a dictionary attack;
- Cryptographic authentication protocols use a cryptographic function on a provided quantity;
It is important to differentiate between authentication a computer -that can use a high quality quantity- and a user. The user can not use a high quality quantity but only a password. The password of the user can be used directly (hash) or to decrypt a higher quality quantity stored somewhere else.
Public key authentication protects against eavesdropping and from an intruder reading the server database. Basically it works as
- Hi Bob, I’m Alice.
- Hi Alice, this is a random R value.
- Hi Bob, I’ve signed the random R value with my private key, can you check with my public key?
On a fairly large network you need trusted intermediaries because otherwise every node needs to know n-1 keys. It also gets complicated when a new node is added.
A KDC – Key Distribution Center knows the keys for all the nodes. They make key distribution more convenient but have some drawbacks. It’s a single point of failure and can become a bottleneck. More importantly, it has enough information to impersonate anyone to anyone.
A CA – Certification Authority is a trusted node that generates certificates signed with a public key. The nodes can verify messages with that single public key.
CA compared to a KDC
- A CA does not need to be online, can be a simpler machine and as a consequence is easier to secure;
- A crash does not disable the network, only installing new users etc. is impossible;
- Certificates are not security-sensitive. An attacker can generate bogus information but only the CA can sign it properly;
- A compromised CA cannot decrypt conversations between Alice and Bob;
- With a CA someone who was revoked access (revoked certificate) still has a certificate. With the KDC removing the entry is enough. A CA has to use a CRL – Certificate Revocation List.
Scaling these solutions requires multiple domains. One authentication is done, Alice and Bob need to use a shared secret key to further protect their conversation, this is called a session key.
Authenticating people
Authentication is dependent on two important capabilities : able to store a cryptographic key and perform cryptographic operations. A computer has these capabilities, a human doesn’t. User authentication is a computer verifying your identity via
- what you know;
- what you have;
- what you are.
Passwords are used for authentication but they allow eavesdropping and guessing (online or offline). Protection against offline guessing can be done by introducing salt. You can protect against eavesdropping with one-time passwords.
Users are a weak link when using passwords. Using the same password in multiple places can weaken your system. Requiring frequent password changes is impractical. One of the major threats is a login trojan horse that captures passwords.
Distributing the password can be a challenge. You can use an initial strong password with expiration requiring users to change it immediately.
Instead of using passwords we can use authentication tokens like a smart card.
- PIN protected memory card, the information is in memory and can only be read after entering a PIN;
- Cryptographic challenge/response cards. A computer that knows the key creates a challenge and asks the card to encrypt or decrypt it;
- Cryptographic calculator or readerless smart card. The computer generates a challenge, the user enters a PIN into the card and then the challenge, requiring the calculator to encrypt it.
Another alternative is biometrics via a retina scanner, fingerprint readers, ….
Security handshake pitfalls
A lot of the existing protocols were designed in an area where eavesdropping was not a concern. The world has changed and so the protocols have to be updated.
- Via a shared secret. Alice asks Bob to send her a challenge. She then encrypts the challenge with the shared key between Alice and Bob and sends it back. Alternatively Bob can send an encrypted challenge and Alice has to decrypt it and send it back. The number of connections can be reduced by Alice sending an encrypted timestamp to Bob. All these protocols allow Trudy to impersonate Bob if she an read his database;
- via a one-way public key. Alice transforms the challenge with her private key and Bob can verify the validity with her public key. The database of Bob most be protected from modification but disclosure is no longer a problem.
With mutual authentication you can validate both participants. The basic protocol requires Alice to ask Bob to send her a challenge. She encrypts the challenge, sends it and Alice creates a second challenge and sends this also to Bob. Bob then encrypts it and sends the result back. In a more simplified version, Alice sends to Bob a challenge, Bob replies with the encrypted challenge and another challenge. Alice then encrypts the second challenge and sends it back. This simplified protocol allows for a reflection attack by Trudy and it can also lead to password guessing (Bob requires with the encrypted value that Trudy chooses). Mutual authentication can also be done with private/public keys and instead of using challenges we can also use the timestamp.
Once authentication is done we also need to assure the integrity of the data. Alice and Bob have to agree on a session key either via a shared secret or via private/public keys. You can use sequence numbers to make sure the messages arrive in the right order. You can change the keys in the middle of a conversation (key rollover) to make sure you don’t run out of sequence numbers and an attacker waits until the sees the same number reappearing.
A ticket given by a KDC is an encrypted piece of information that Alice has to hand over to Bob. A nonce is a number (sequence number, timestamp, large random number) that is only used once. Note the difference between random (the numbers are picked unpredictably) and pseudorandom (an algorithm where the outcome is determined by its initial state).
Needham-Schroeder is a classic KDC-arbitrated authentication protocol (Kerberos is based on it with additionally expiration dates in the messages).
- Alice contacts the KDC. The message contains a nonce that assures Alice that she is talking to the KDC;
- The KDC returns the nonce, a string “Bob” so the request can not be tampered, a key for Alice and Bob to share and also a ticket (the key and Alice’s name encrypted with Bob’s key) for Alice to use to Bob. Alice can not read the ticket but Bob can decrypt it.;
- Alice sends a request to Bob containing a new nonce that is encrypted with the shared key and the ticket;
- Bob can decrypt the ticket to get the shared key and can so get the nonce;
- Bob sends the nonce (decremented with one) back to Alice and a also sends a new nonce encrypted with the shared key;
- Alice returns the decremented version of the decrypted nonce from Bob.
To prevent Trudy from reading recorded messages with a captured (older) key from Alice an extra step is introduced where Alice requests Bob to send a nonce, the nonce is send to the KDC and packaged in the ticket for Bob.
Otway-Rees is an improved authentication protocol.
- Alice sends a clear-text nonce to Bob and another nonce encrypted with the key of Alice;
- Bob forwards the encrypted nonce to the KDC along with his own encrypted nonce and the clear-text nonce;
- The KDC replies to Bob the shared key and a message he has to forward to Alice (to assure to Alice that both the KDC and Bob are legitimate);
- Bob forwards that message to Alice and Alice then replies by sending something encrypted with the shared key (proving that she now knows the key).
It is important that the nonces are unpredictable.
Authentication Protocol Checklist
- Protect against eavesdrop;
- Impersonation of one of the correspondents;
- Protect against a situation when the keys are stolen;
- Intercept and modify messages.
Password protocols
A credential is something that can be used to prove who you are or prove that you are authorized to do something.
The Lamport’s hash provides a password protocol that protect against eavesdropping and impersonation and does not use public key cryptography. Alice has a password. Bob remembers the username, an integer (n) that gets decremented with every authentication and n-times the hash of the password. When the integer reaches 1 then Alice has to reset the password. A salt can be chosen at password installation time and concatenated to the password before the hashing takes place. Alice can reuse the password with different Bob’s as long as different salt is used when setting up the password with the different Bob’s.
The EKE – Encrypted Key Exchange is a password protocol where
- Alice and Bob share a weak secret (the hash of the password);
- Bob knows the secret because he stores it;
- Alice knows the secret because she computes it.
A Diffie-Hellman exchange happens where the D-H numbers are encrypted with the weak secret and Alice and Bob then do mutual authentication based on the D-H shared secret.
Other strong password protocols were later introduced SPEKE – Simple Password Exponential Key Exhange, SRP – Secure Remote Passwords and PDM – Password Derived Moduli.
