1. Reducing Risk from Poorly Chosen Keys
T. Mark A. Lomas, Li Gong, Jerome H. Saltzer, Roger M. Needham

2. Motivations
A common risk in authentication systems is password guessing
Cause: to make a system convenient enough for user acceptability, personal keys of users may be derived from passwords – Chosen by user
Self-chosen passwords are easy to guess
Dictionary attack, offline

3. Motivations (Cont’d)
Example: Kerberos Key Distribution Server enciphers initial response packet using a key derived from user’s password
An attacker could passively record initial response packet and attempt to decrypt that packet using keys derived from a series of guesses
Attacker will know if a guess is correct because resulting deciphering of packet will be recognizable data, ie: network service, time of day
Attacker can work privately – only cost of incorrect guessing is wasted time

4. Common Counter
Encourage or force users to choose passwords that are hard to guess
These passwords are often difficult to remember – often encounters user resistance
Example: Bingsuns password

5. First Inspiration
ATM machines generally use 4-digit numerical passwords – not particularly susceptible to attack
Why not? ATM passwords can be guessed in less than 9,999 tries

6. First Inspiration (Con’d)
Systems generally confiscate the banking card after the third wrong guess – Terminates experimentation
Guesses cannot be verified in isolation
Each guess must be tried by invoking part of system that is in a position log incorrect guesses and raise alarm

7. Second Inspiration
Observed that if a completely random string of bits is enciphered, attackers have no way of verifying correctness of guess

8. Notation and Terminology
{m}k: indicates a message m encrypted using an encryption key k
Plaintext: unencrypted form of message m
Ciphertext: encrypted form of message m
Well chosen: an encryption key chosen at random from a large space
Poorly chosen: an encryption key derived from a user-chosen password

9. A Typical Attack
An eavesdropper has been monitoring network traffic and records copies of all messages that form part of an authentication
One day, eavesdropper hears the following statement: “The system forces me to change my password so often that I just use the name of the day on which it last forced me to change it.”
Eavesdropper tests each of the seven possible values using, using only the messages that have already been recorded

10. A Typical Attack (Cont’d)
Previous example showed an insecure protocol because it is possible for eavesdropper to determine the actual password
A protocol that is secure against guessing is one in which the eavesdropper must reveal to an authentication server his knowledge (or lack thereof) for each guess – Attacker risks discovery

11. Known Plaintext
If part, or all, or part of ciphertext can be predicted before the message is decrypted, then that message is said to contain known plaintext
There are two ways to exploit this knowledge:
Determine part of the message
Discover decryption key that corresponds to the message

12. Known Plaintext (Example)
A recipient of a series of letters notes that they always begin with a return address
One day, recipient receives an encrypted message not intended for him
It is reasonable to assume that this message also begins with return address
The address is known plaintext
The concept applies to any predictable information, regardless of position

13. Known Plaintext (Example Cont’d)
Assume that person choosing decryption keys is not careful
The previous three keys were “Angela”, “Beryl” and “Christine”
If unintended recipient of the message attempts to decrypt it with series of women’s names, starting with the letter “D”, recipient may find a key for which the decrypted message begins with the expected return address – result will verify key guess

14. Verifiable Plaintext
A message has verifiable plaintext if it contains information that is recognizable when decrypted
Note: Known plaintext forms a subset of verifiable plaintext since information that is known in advance is verifiable
Any message that has a specific property that an attacker might know in advance is verifiable
Example: An ASCII string, integer with a small range

15. Verifiable Plaintext (Cont’d)
Most worrying aspect from point of view of a protocol designer is that attacker can check correctness of a guess as to the encryption key without any online transactions – without notice
Note: it is possible to be more relaxed about the use of poorly chosen passwords if we can remove verifiable plaintext from messages that are enciphered with predictable keys

16. Verifiable Plaintext (Cont’d)
Public Key Encryption System
Public and Private keys for each user pair
Public keys are used to encrypt message
Private keys are used to decrypt message
If a public key encryption system is used, then it is possible for attacker to determine plaintext without discovering decryption key
An eavesdropper monitors one or more transactions using public key
For each possible value of plaintext, computes corresponding ciphertext and compares it with ciphertext previously logged – Match indicates plaintext found

17. Verifiable Plaintext (Cont’d)
Counter to previous example:
Introduce a random number, a confounder
Sole purpose of the confounder is to thwart such an attack
Value of confounder may be ignored by the recipient of the message

18. A Two-Message Protocol
Sample private-key message pair:
A  B: {n}k
B  A: {f(n)}k
Alice generates a random number n and encrypts it using a pre-arranged private key k
Bob decrypts the message, computes some agreed function of the number and returns encrypted form of result to Alice
The function f() ensures that the two messages aren’t identical

19. A Two-Message Protocol (Cont’d)
Neither of these messages alone is known plaintext since both n and f(n) are random numbers
However, assuming f() is not a secret, then the pair of messages together contain verifiable plaintext and are subject to guessing attack

20. A Mutual Authentication Protocol
Developed protocol requires authentication server to generate session keys
Server S mediates between two clients, A and B

21. A Mutual Authentication Protocol (Cont’d)
A  S: {A,B,na1,na2,cs,{ta}Pa}Ks
S  B: A,B
B  S: {B,A,nb1,nb2,cb,{tb}Pb}Ks
S  A: {na1,k XOR na2}Pa
S  B: {nb1,k XOR nb2}Pb
B  A: {ra}k
A  B: {f1(ra),rb}k
B  A: {f2(rb)}k

22. A Mutual Authentication Protocol
na1, na2, ca, ra, nb1, nb2, cb and rb are random numbers generated by the originator of the first message in which they appear
The key Ks is the public key of the server
Pa and Pb are the password-derived personal keys of clients A and B respectively to comm.
The values ta and tb are pieces of recognizable but non-repeating information such as local time

23. A Mutual Authentication Protocol (Cont’d)
Client Alice generates three random numbers na1, na2, and ca produces a piece of timely information encrypted under Alice’s personal key and announces that she is Alice and wishes to comm. With Bob
Assume Ks is the public key to a public-key encryption algorithm used only for the purpose of sending initial requests to the key dist. server

24. A Mutual Authentication Protocol (Cont’d)
The server deciphers message i(iii) using its private key and verifies claimed identities of Alice (Bob) by deciphering {ta}Pa ({tb}Pb)
If deciphered message is not current time, server logs failure, otherwise server responds with message iv(v)
Message iv(v) contains na1(nb1) as proof that message i(iii) was correctly decrypted
To further security, server can send back dummy message in place of iv(v) if decipher failed

25. A Mutual Authentication Protocol (Cont’d)
Message iv(v) contains na2(nb2) for two reasons
To protect Alice (Bob) against an attack by Bob (Alice) who already know the value of k, the session key
To prevent messages vi and vii or messages vii and viii to be exploited to verify k, which in turn allows Pa or Pb to be verified
Messages vi and vii contain a challenge ra and response f(ra)

26. Insider Attacks
Although one would like to assume that communicating parties trust each other, this is not always the case
Further, protecting against insider attacks also ensures that Bob compromising his own key will not compromise Alice’s

27. Insider Attacks (Cont’d)
Confounders ca and cb serve the purpose of defending Alice from Bob and vice-versa
Without ca and cb, someone attempting to guess Pa or Pb could attempt to construct messages I or iii without being able to decrypt them

28. Insider Attacks Consider the following:
i. A  S: {A,B,na1,na2,{ta}Pa}Ks
iv. S  A: {na1,k XOR na2}Pa
Bob, knowing k, guesses the value of Pa, decrypts message iv using this guess, computes the corresponding ciphertext value for message i, and compares it with intercepted copy of message I
If the two versions are identical then guess of Pa has been verified
Addition of ca will confound such an attack under the assumption that all bits of enciphered message I depend on all of the plaintext bits of that message

29. Results
Suggested class of risk, guessing of poorly-chosen passwords, for which an authentication protocol can provide protection
Offers conceptual framework based on verifiable plaintext to determine whether or not a protocol is susceptible to password guessing
Demonstrated examples of techniques for avoiding verifiable plaintext in an authentication protocol