Hello
Challenge R
f(k, R
f(k, R Problems: 1. Authentication is not mutual only authenticates Anyone can send the challenge R.
f(k, R Problems: 1. Authentication is not mutual only authenticates Anyone can send the challenge R. 2. Connection can be hijacked if the rest of the transaction is without cryptographic protection and attacker makes packets with addr
f(k, R Problems: 1. Authentication is not mutual only authenticates Anyone can send the challenge R. 2. Connection can be hijacked if the rest of the transaction is without cryptographic protection and attacker makes packets with addr 3. Off line password guessing attack if K is derived from password because both R and f(k,r are observable.
f(k, R Problems: 1. Authentication is not mutual only authenticates Anyone can send the challenge R. 2. Connection can be hijacked if the rest of the transaction is without cryptographic protection and attacker makes packets with addr 3. Off line password guessing attack if K is derived from password because both R and f(k,r are observable. 4. Someone reading the database may be able to impersonate later or to another server that the client uses
Hello
K{R}
R
R Concerns: 1. Requires reversible cryptography no hash
R Concerns: 1. Requires reversible cryptography no hash 2. No need to eavesdrop if R is recognizable Attacker says hello and gets back K{R}, if K derived from password can generate lots of Ks for a dictionary attack.
R Concerns: 1. Requires reversible cryptography no hash 2. No need to eavesdrop if R is recognizable Attacker says hello and gets back K{R}, if K derived from password can generate lots of Ks for a dictionary attack. 3. If R is recognizable by, then protocol authenticates but only if life of R is short, otherwise K{R} can be replayed by attacker
Hello, K{time}
Hello, K{time} Advantage: 1. One direction, more efficient is drop in replacement for existing prot.
Hello, K{time} Advantage: 1. One direction, more efficient is drop in replacement for cleartext prot. 2. The server does not need to keep volatile state (such as R
Hello, K{time} Advantage: 1. One direction, more efficient is drop in replacement for cleartext prot. 2. The server does not need to keep volatile state (such as R Problems: 1. Attacker can use K{time} to impersonate within acc clock skew
Hello, K{time} Advantage: 1. One direction, more efficient is drop in replacement for cleartext prot. 2. The server does not need to keep volatile state (such as R Problems: 1. Attacker can use K{time} to impersonate within acc clock skew But can be foiled if remembers all timestamps sent.
Hello, K{time} Advantage: 1. One direction, more efficient is drop in replacement for cleartext prot. 2. The server does not need to keep volatile state (such as R Problems: 1. Attacker can use K{time} to impersonate within acc clock skew But can be foiled if remembers all timestamps sent. 2. If multiple s, same K, K{time} on one can work on others
Hello, K{time} Advantage: 1. One direction, more efficient is drop in replacement for cleartext prot. 2. The server does not need to keep volatile state (such as R Problems: 1. Attacker can use K{time} to impersonate within acc clock skew But can be foiled if remembers all timestamps sent. 2. If multiple s, same K, K{time} on one can work on others Can be foiled by sending K{time server}
Hello, K{time} Advantage: 1. One direction, more efficient is drop in replacement for cleartext prot. 2. The server does not need to keep volatile state (such as R Problems: 1. Attacker can use K{time} to impersonate within acc clock skew But can be foiled if remembers all timestamps sent. 2. If multiple s, same K, K{time} on one can work on others Can be foiled by sending K{time server} 3. Vulnerable to attacker setting time back on!!
Hello, K{time} Problems: 4. Setting time requires a security handshake better make it chllng/resp (that is, not depending on time or else there is a problem if clocks of machines are too far apart the negotiation will fail.
Hello, time, hash{k,time}
Hello, time, hash{k,time} Advantage: 1. Otherwise, if time not sent, for to check hash, must try lots of different acceptable times before one matches the hash
(K c, S c Hello (K s, S s
(K c, S c Challenge R (K s, S s
(K c, S c signed[r] Sc (K s, S s Advantage: Like secret key protocol except database not vulnerable to peeking
(K c, S c signed[r] Sc (K s, S s Advantage: Like secret key protocol except database not vulnerable to peeking Problem: Can trick someone into signing something. Wait for to say Hello, send back something you want client to sign, get the signed item use it.
(K c, S c Hello (K s, S s
(K encrypt{r} c, S c Kc (K s, S s
(K R c, S c (K s, S s Concerns: 1. Some public key systems can only do signatures, not reversible encryption
(K R c, S c (K s, S s Concerns: 1. Some public key systems can only do signatures, not reversible encryption 2. Attacker can get an encrypted message sent to client, impersonate, send the message to who decrypts it. Gets back the decrypted message.
(K R c, S c (K s, S s Should the same keys be used for encryption and signing? 0. Someone encrypts message M with client public key, sends to client 1. Attacker intercepts M e mod N where <e,n> is the client's key pair 2. Attacker chooses number R, prime relative to modulus N 3. Attacker creates bogus message H = M e *R e (recall e is public 4. Attacker impersonates server, sends H to client for signing 5. Attacker gets H d mod N = (M*R ed mod N = M*R mod N 6. Attacker multiplies by R 1 to get M
(K R c, S c (K s, S s Concerns: 1. Some public key systems can only do signatures, not reversible encryption 2. Attacker can get an encrypted message sent to client, impersonate, send the message to who decrypts it. Gets back the decrypted message. Never use the same key for signing and encryption/decryption
(K R c, S c (K s, S s Concerns: 1. Some public key systems can only do signatures, not reversible encryption 2. Attacker can get an encrypted message sent to client, impersonate, send the message to who decrypts it. Gets back the decrypted message. Never use the same key for signing and encryption/decryption Observe: several secure independent systems may be insecure when put together (attacker may use one protocol to break another.
Hello, R c Mutual Authentication:
R s, f(k, R c Mutual Authentication:
f(k,r s Mutual Authentication:
Imposter Hello, R i Reflection Attack: Attacker wants to impersonate to. Attacker sends Hello and a challenge.
Imposter R s, f(k, R i Reflection Attack: Attacker wants to impersonate to. Attacker sends Hello and a challenge. Attacker gets back f(k, R i (who cares and R s.
Imposter R s, f(k, R i Hello, R s Reflection Attack: Attacker wants to impersonate to. Attacker sends Hello and a challenge. Attacker gets back f(k, R i (who cares and R s. Attacker opens second connection to using R s.
Imposter R s, f(k, R i Reflection Attack: Attacker wants to impersonate to. Attacker sends Hello and a challenge. Attacker gets back f(k, R i (who cares and R s. Attacker opens second connection to using R s. Attacker gets back R s encrypted. R p, f(k, R s
Imposter f(k, R s Reflection Attack: Attacker wants to impersonate to. Attacker sends Hello and a challenge. Attacker gets back f(k, R i (who cares and R s. Attacker opens second connection to using R s. Attacker gets back R s encrypted. R p, f(k, R s Attacker abandons second connection and sends back f(k, R s to complete.
Imposter f(k, R s R p, f(k, R s Reflection Attack, how to foil it: 1. Instead of the same key K, use different keys K s, K c K s may be almost K c (say times 1 or 1 different etc. 2. Insist the challenge from the is different from that of the
Imposter f(k, R s R p, f(k, R s Reflection Attack, how to foil it: 1. Instead of the same key K, use different keys K s, K c K s may be almost K c (say times 1 or 1 different etc. 2. Insist the challenge from the is different from that of the Also, off line password guessing attack vulnerability: Attacker sends message to claiming to be and enclosing a challenge R, returns the challenge encrypted f(k, R, this gives the attacker ability to check passwords
Hello Reflection Attack can't succeed with this protocol:
R s Reflection Attack can't succeed with this protocol:
f(k,r s Reflection Attack can't succeed with this protocol:
R c Reflection Attack can't succeed with this protocol:
f(k,r c Reflection Attack can't succeed with this protocol: Reason: Initiator always is first to prove its identity!!
Hello, encrypt{r c } (K Ks c, S c (K s, S s Public key mutual authentication:
R c, encrypt{r s } (K Kc c, S c (K s, S s Public key mutual authentication:
R (K s c, S c (K s, S s Public key mutual authentication:
R (K s c, S c (K s, S s Public key mutual authentication: Variant: R s and R c are signed by their respective parties
R (K s c, S c (K s, S s Public key mutual authentication: Variant: R s and R c are signed by their respective parties How does the client's workstation retrieve the client's private key when all the client knows is a password? usually keys cannot be recovered from passwords, e.g. RSA Use a directory service client workstation retrieves the following: 1. 's private key which is encrypted with 's password 2. Certificate for 's public key, signed with 's private key
hello R K{R} Establish a session key (secret key system: After authentication R and K{R} is known by and Can't use K{R} as session key someone may have seen it Can't use K{R+1} as session key Attacker seeing transmission using session key K{R+1} impersonates 's network address to and sends R+1 as the challenge to. responds with K{R+1}. So attacker can decrypt previous transmission.
hello R K{R} Establish a session key (secret key system: After authentication R and K{R} is known by and Can't use K{R} as session key someone may have seen it Can't use K{R+1} as session key Attacker seeing transmission using session key K{R+1} impersonates 's network address to and sends R+1 as the challenge to. responds with K{R+1}. So attacker can decrypt previous transmission. Session key should not be an encrypted value which can be predicted or extracted later.
(K c, S c g, p, [g a mod p] Sc, [g b mod p] Ss (K s, S s Establish a session key (public key system: Authenticate with Diffie Hellman exchange, RSA signing. Use g ab mod p as the session key. Attempt to get root access on either machine does not reveal the a and b needed to generate session key to decrypt recorded messages they were never recorded and the session key was tossed. If session key had been sent across, it could have been recorded and decrypted after getting root access. If session keys get sent across without being signed, attacker can send an R while impersonating 's network address.
Request B A KDC (K a K a {K AB } (K s K b {K AB } B (K b KDC operation, in principle Makes K AB
A KDC (K a N a, Req B (K s B (K b Needham Schroeder authentication and session key (secret key system: A sends a nonce N a and request to connect to B to the KDC
K ab, N a A KDC (K a (K s B (K b Needham Schroeder authentication and session key (secret key system: A sends a nonce N a and request to connect to B to the KDC KDC makes a session key K ab for the connection
K ab, N a A KDC K a {N a, B, K ab, T} (K a (K s T=K b {K ab, A} B (K b Needham Schroeder authentication and session key (secret key system: A sends a nonce N a and request to connect to B to the KDC KDC makes a session key K ab for the connection KDC encrypts N a, B, a ticket T with key K a and sends all to A. To make T the KDC encrypts the session key and A with with K b.
A KDC (K a (K s B (K b T, K ab {N b } Needham Schroeder authentication and session key (secret key system: A sends a nonce N a and request to connect to B to the KDC KDC makes a session key K ab for the connection KDC encrypts N a, B, a ticket T with key K a and sends all to A. To make T the KDC encrypts the session key and A with with K b. A encrypts a nonce N b with the session key K ab, sends with ticket to B
A KDC (K a (K s Needham Schroeder authentication and session key (secret key system: A sends a nonce N a and request to connect to B to the KDC KDC makes a session key K ab for the connection KDC encrypts N a, B, a ticket T with key K a and sends all to A. K ab {N b 1,N c } To make T the KDC encrypts the session key and A with with K b. B (K b A encrypts a nonce N b with the session key K ab, sends with ticket to B B subtracts 1 from nonce, make new nonce, encrypts with session key sends encrypted message to A.
A KDC (K a (K s B (K b K ab {N c 1} Needham Schroeder authentication and session key (secret key system: A sends a nonce N a and request to connect to B to the KDC KDC makes a session key K ab for the connection KDC encrypts N a, B, a ticket T with key K a and sends all to A. To make T the KDC encrypts the session key and A with with K b. A encrypts a nonce N b with the session key K ab, sends with ticket to B B subtracts 1 from nonce, make new nonce, encrypts with session key sends encrypted message to A. A subtracts 1 from nonce, encrypts with session key, sends to B
A KDC (K a N a, Req B (K s B (K b Needham Schroeder: What is going on? Nonce N a protects against: attacker, having stolen previous K b and message from A requesting it, waits for A to request a session key from the KDC and immediately plays back KDC's reply to A, and gets the session key encrypted with B's old K b, which it knows, so it can impersonate B to A. K a {N a, B, K ab, T} T=K b {K ab, A} Attacker need not know key of A
A KDC K (K a a {N a, B, K ab, T} (K s T=K b {K ab, A} B (K b Needham Schroeder: What is going on? With the identity of B inserted, attacker id substitution is detected by A Nonce is returned to check authenticity of KDC Double encryption of session key (K b for ticket, then K a on the ticket is not considered necessary
A KDC (K a (K s B (K b T, K ab {N b } Needham Schroeder: What is going on? A knows that only someone with B's key K b can decrypt and get the session key. With session key, B decrypts N b.
A KDC (K a (K s B (K b Needham Schroeder: Vulnerability If attacker finds out A's key K a, then attacker can impersonate itself to the KDC. But if A changes K a, then we require attacker not to be able to impersonate. But the ticket to B remains valid after a such a change. Attacker can save K a {N a, B, K ab, K b {K ab, A}} until it knows the old K a key, then decrypt to get K b {K ab, A} and send that to B to convince it that it is connecting with A using K ab.
A KDC (K a (K s B (K b Needham Schroeder: Vulnerability If attacker finds out A's key K a, then attacker can impersonate itself to the KDC. But if A changes K a, then we require attacker not to be able to impersonate. But the ticket to B remains valid after a such a change. Attacker can save K a {N a, B, K ab, K b {K ab, A}} until it knows the old K a key, then decrypt to get K b {K ab, A} and send that to B to convince it that it is connecting with A using K ab Fixed by A connecting to B requesting an encrypted nonce and using that nonce throughout the exchange.
A KDC (K a (K s B (K b Otway Rees: N c, A, B, K a {N a, N c, A, B}
A KDC (K a (K s K a {N a, N c, A, B}, K b {N b, N c, A, B} B (K b Otway Rees: If N c is not the same in both messages, KDC will stop the transaction.
K ab A KDC (K a (K s B (K b Otway Rees:
K ab A KDC (K a (K s N c, K a {N a, K ab }, K b {N b, K ab } B (K b Otway Rees: B is reassured that it is talking to KDC since its nonce was extracted using K b and sent back encrypted.
K ab A KDC (K a (K s B (K b Otway Rees: K a {N a, K ab } This message reassures A that both the KDC and B are OK because it can check its nonce, which it had encrypted with other things, and to get it back means the KDC used K a and the KDC validated B.
K ab A KDC (K a (K s B (K b Otway Rees: K ab {anything recognizable} A proves identity to B by showing it knows K ab.
Nonce types: Security Handshake Pitfalls Random number will probably never be reused Timestamp requires synchronized clocks Sequence number requires non volatile memory (system crash?
Protocol Checklist: Eavesdropping: attacker should not be able to do any of the following learn the contents of messages between connecting parties learn information enabling impersonation in a future exchange learn anything that permits off line password guessing
Protocol Checklist: Eavesdropping: attacker should not be able to do any of the following learn the contents of messages between connecting parties learn information enabling impersonation in a future exchange learn anything that permits off line password guessing Impersonation of Originator: attacker should not be able to do any of these: convince other party it is the real originator learn information that would enable impersonator to do an off line password guessing attack against or 's secret information learn information that would enable impersonation of in the future learn information that would enable impersonation of to trick into signing or decrypting something
Protocol Checklist: Eavesdropping: attacker should not be able to do any of the following learn the contents of messages between connecting parties learn information enabling impersonation in a future exchange learn anything that permits off line password guessing Impersonation of Originator: attacker should not be able to do any of these: convince other party it is the real originator learn information that would enable impersonator to do an off line password guessing attack against or 's secret information learn information that would enable impersonation of in the future learn information that would enable impersonation of to trick into signing or decrypting something Pounce attacker gets part way through authentication but should not: convince the attacker is the learn info enabling an off line password guessing attack learn info enabling impersonation of in future or to trick into signing or decrypting something
Protocol Checklist: Read Database: Bad news! Then attacker can convince it is the. Attacker can do off line password guessing attack against 's secret (if it is derived from a password since must have enough info to know if party really is the. But: Attacker should not be able to impersonate the to the Attacker should not be able to decrypt recorded messages between S and C
Protocol Checklist: Read Database: Bad news! Then attacker can convince it is the. Attacker can do off line password guessing attack against 's secret (if it is derived from a password since must have enough info to know if party really is the. But: Attacker should not be able to impersonate the to the Attacker should not be able to decrypt recorded messages between S and C Read Database: Bad News!! Then attacker can convince that it is the. Attacker can do off line password guessing attack against 's secret. But: Attacker should not be able to impersonate the to the Attacker should not be able to decrypt recorded messages between S and C
Protocol Checklist: Read Database: Bad news! Then attacker can convince it is the. Attacker can do off line password guessing attack against 's secret (if it is derived from a password since must have enough info to know if party really is the. But: Attacker should not be able to impersonate the to the Attacker should not be able to decrypt recorded messages between S and C Read Database: Bad News!! Then attacker can convince that it is the. Attacker can do off line password guessing attack against 's secret. But: Attacker should not be able to impersonate the to the Attacker should not be able to decrypt recorded messages between S and C Sit on net and modify messages Attacker should not be able to: do an off line password guessing attack on anybody's secret information read any messages hijack a conversation without the other side knowing this cause messages between and to be misinterpreted