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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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