Transcript document

CS 6390 (Advance Computer Networks)
class discussion – Prof Prakash
Systematic Design of a Family of
Attack Resistant Authentication
Protocols
By:- Ray Bird, I Gopal, Amir Herzberg, Philippe A Jnason, Shay Kutten,
Refik Molva, and Moti Young
AUTHENTICATION
- The process of proving one’s identity to
someone else
A necessary condition for securing a
network is :The ability to reliably authenticate
communication partners and other
network entities.
Methods of Authentication
1. One-way password based authentication
requires users to prove identity by demonstrating knowledge of some
secret they know
Limitations
- Passwords are transmitted in clear text (sniff & snoop by intruders)
- Passwords are easy to guess ( users choose easy password,
memorized)
- Authentication is one-way ( faked prompt from wrong computer / IP
spoofing )
Methods of Authentication
2. Biometric information based authentication
Authentication based on recognition of biometric information such as
voice sample, finger prints, hand signature etc.
Limitations
- Reliability problems
- Expensive hardware and software support problems
- biometric information is often transmitted in clear text( sniffing by
intruder)
Methods of Authentication
3. Cryptographic Authentication
- Combines issues of authentication with those of key distribution
- challenges communicating parties being authenticated to prove
identity by demonstrating ability to encipher and decipher some item
with a secret (private) key or public key. [ Key could be stored on
smart cards or chip cards equipped with processor capabilities]
- Key usually does not change frequently (potential for intruder to
record and playback)
- To guarantee that the item that gets enciphered or deciphered (called
the Challenge) is different for every execution of the authentication
protocol, 3 different techniques are used:-
Methods of Cryptographic Authentication
1. Time Stamps
- Challenge derived from a real time clock
A
authenticated
requesting authentication
enciphers current clock readings
sends the result to party requesting authentication
deciphers the received message
B
verifies time stamp corresponds to current real time
- Requires that A and B must have synchronized real time clocks
(not possible so A’s clock should be within a limited time window of
B’s clock)
- possibility of intruder impersonating A ( replay one of A’s recent
authentications:- limit number of protocols runs in window, B saves
all authentication messages in a window)
Methods of Cryptographic Authentication
2. Counters
- Challenge derived from a counter that is incremented for every
protocol execution
- A and B maintain synchronized counters of the number of times
they authenticate each other
- A enciphers counter, send to B, B deciphers and verify with its
own, both parties then increment counter
- requires both parties to maintain synchronized counters
- counters must be long enough
- counter complicates conflict resolution (when both parties want to
initiate protocol execution at the same time)
Methods of Cryptographic Authentication
3. Random Number Generator (Nonce)
- Challenge derived from a random number generator ( Nonce:- A
number that a protocol will only ever use once-in-a-lifetime )
- simple to implement than the other two but requires an extra
network message ( message may be piggy-backed on to regular
traffic)
- B verifies that nonce has never been used, so B generates the nonce
- B enciphers nonce, send it to A, A deciphers ,send it to B in clear
text, B then authenticates
Limitations of Cryptographic
Authentication
• Synchronization of clocks, counters
• Export restrictions because of the way they
use cryptographic functions
• Not amenable for use in lower layers of
network protocols because of the size and
complexity of the messages they use
Simple Cryptographic
Authentication
• One way authentication of A
A
B
Ea(N)
ciphertext
N
cleartext
Simple Cryptographic
Authentication
• Two way authentication
A
B
Eb(N1)
N1
Ea(N2)
N2
• Two way authentication with three
messages
A
Eb(N1)
B
N1, Ea(N2)
N2
(with symmetric cryptography, the keys Ka
and Kb could be the same, so that Ea and Eb
represent encryption under the same key)
Possible Attacks on Simple
Cryptographic Authentications
1. Relay Attack
- Consider two communicating entities A and B that share a key
- C is a third party with no access to the key, however, C has access
to all legitimate protocol executions that were accepted by A and B
in the past
- C is also able to interfere with on-going protocol executions (or
even start a new faked protocol execution) involving A and B
- C’s objective is to cause A or B to erroneously mark one of these
perverted protocol executions as accepted
- It follows that C acts as just a simple delay “relay” between A and B
Possible Attacks on Simple
Cryptographic Authentications
2. Plain text Attack
- Enciphered message flowing between A and B is the ciphertext of a
bit string (the nonce) that flows in plaintext in subsequent message
between A and B
- Intruder is able to collect two cleartext-ciphertext pair each time the
protocol is run
- Intruder is able to accumulate encryption tables in the long run that
may help it break the scheme
Possible Attacks on Simple
Cryptographic Authentications
3. Chosen Ciphertext Attack
- Intruder may turn plaintext attack into selected text attack by
playing an active role instead of a passive role
- Intruder sends ciphertext on behalf of either A or B to the other
party and wait for the other party to reply with the deciphered value
of that text
- It can then accumulate pairs of cleartext-ciphertext of which it
selected the ciphertext or the cleartext
Possible Attacks on Simple
Cryptographic Authentications
4. Oracle Session Attack
- A and B use the same key
- Intruder C, poses as A, starts a session with B by sending some
enciphered nonce E(N1)
- B replies with the deciphered value N1 and its own enciphered
challenge E(N2)
- C then takes advantage of a selected ciphertext attack on A, using A
as the oracle who will provide the decipher value N2
- C then drops the oracle session with A, turns around and assumes its
faked identity A with respect to B by sending E(N2) to B
An Oracle Session Attack
A
C
B
E(N1)
N1, E(N2)
E(N2)
N2, E(N3)
N2
abandon session
ISO two way authentication
Protocol
A
B
N1
E(N1), E(N2)
N2
-
the challenge to the initiator of the protocol (A) consist of
demonstrating ability to encipher a given clear text nonce
The challenge to the responder B consists of demonstrating ability to
decipher a given ciphertext nonce
Thus and intruder can no longer misuse one party as an oracle against
the other
Possible Attacks on Simple
Cryptographic Authentications
5. Parallel Session Attack
- Intruder assumes a passive role, intercepts a call from A to B with a
challenge N1, leaving B out of the picture
- It then turns A into an oracle against itself
- Since C cannot answer the challenge N1, it simply pretends that it is
B trying to start a parallel session, thus causing A to provide it with the
key
Parallel Session Attack
A
C
N1
N1
E(N1), E(N2)
E(N1), E(N2)
N2
N2
Oracle session
E(N2) is the enciphered challenge on the parallel session
To prevent, this the cryptographic message
used in the second challenge must be direction
dependent
Offset Attack through a parallel
session
-
Enciphering of N1 is replaced by a simple function of N1 (XOR)
But with proper offsetting an intruder can still resort to a parallel
session attack
A
N1
N1 XOR B XOR A
E(N1 XOR B), E(N2)
E(N1 XOR B), E(N2)
N2
N2
C
Interleaving Attacks
• Attacks that involve replaying messages and
functions of challenges observed in other
runs of the protocol
• Examples:- Oracle session attacks
- Parallel session attacks
- Offset attacks
Design Requirements
Objective:
- design two-way authentication protocols
- complex enough to resist interleaving attacks
- economical
- usable in low layers of network architecture
Requirements
- Nonce based (synchronization of clocks, stable counter mgt issues)
- Resistant to common attacks ( secure against known- and plaintext
attacks as well as interleaving )
- Usable at any layer of any network architecture (small messages)
Requirements
- Usable on any processing base ( execute on smart cards as well as
low-end entry level networking components)
- Use any known and typical encryption algorithm
- Exportable
- Extendible (flexible to accommodate different contexts and should
allow possible functional extensions )
Canonical Protocol Development
1. Resistance to Replay attacks through the
use of Nonce
A
B
N1
N2, U(K1, N1, ..)
* A sends N1 to B
•B authenticates itself by
sending back a function U, N2
•A completes by authenticating
itself with a function V
V(K2, N2, ..)
** for this protocol to resist Oracle attack, the functions U() and
V() must be different
Canonical Protocol Development
2. No Restriction on Cryptographic System
(workable with symmetric and asymmetric systems)
A
N1
N2, E(p(N1, ..))
B
K1, K2 –private of B and A resp.
In symmetric system, K1, K2 are
shared secrets, in fact the same thus
U(K1, ..) and V(k2, ..) replaced with
p() and q()
E(q(N2, ..))
** Prevention of Parallel session attacks suggest that function
P() must be asymmetric(direction-dependent)
Canonical Protocol Development
3. Resistance to Parallel Session Attacks
- The arguments to the function p() must be different depending on
whether A or B starts the connection
A
B
N1
N2, E(p(N1, D, ..))
E(q(N2, ..)
Canonical Protocol Development
4. Small Cryptographic Messages
p() and q() may be restricted to 64-bit functions or operator #
5. Resistance to Offsets and selected text
Attacks
include inside p() an additional internal encrypted function of the
same parameters N1 and D which can be separated cryptographically,
and N2 which is not under the control of the intruder
A
N1
N2, E(f(N1, N2, D, ..)#E(g(N1, N2, D, ..)))
E(g(N1, N2, D, ..))
B
Canonical Protocol Development
6. Few Cryptographic function operations
- By putting additional conditions on q() we can return to a protocol
requiring two cryptographic block operations, we let the functions g()
= q(),
- thus the inner most cryptographic expression required to produce or
verify flow 2 is the same expression of flow 3
A
N1
B
N2, E(f(N1, N2, D, ..) # E(g(N1, N2, D, ..)))
E(g(N1, N2, D, ..))
Canonical Protocol Development
7. Resistance to known Plaintext Attacks
- all arguments of g() and f() can be obtained through wire-taping and
the intruder can compute the cleartext and observe the ciphertext of
flow 3, combine it with # operator to derive the cleartext for flow 2
- hide the cleartext value for flow 3 by replacing g() with g’() #E(h),
where # is a suitable 64-bit operator.
- also hide the clear text in flow 2 by encrypting inside g() and outside
it with a suitable 64-bit operator
A
N1
N2, E(f(..)#E(g’(..)#E(h(..))))
E(g’(..)#E(h(..)))#E(h(..))
B
Canonical Protocol Development
8. Exportability
- Use one-way data integrity (MAC) operations instead of encryption
and decryption
- the cryptographic expression of flows 2 and 3 are replaced with
combinations of plain 64-bit MAC integrity checks that are computed
using the Cipher Block Chaining (CBC) mode operations of DES
A
N1
N2, MAC(h(..), g(..), f(..))
MAC(h(..), g(..)) XOR MAC(h(..))
B
Testing Resistance to Interleaving
Attacks
Assumptions:
- f() and g() are cryptographically separate in flow(2) of the canonical
protocol
- f() and g() takes just N1, N2, D as arguments and are strongly
dependent on their arguments
Test:To show that an intruder C attacking A or B cannot reconstruct or derive
the cryptographic expressions needed in flows 2 or 3 by replaying or
manipulating the results of passive observations or active interleaving
attacks
Testing Resistance to Interleaving
Attacks
Observations of an Intruder:
- record legitimate past runs of the protocol between A and B
- collect information on the protocol actively by pretending to be A / B
and attacking the other party
- Armed with any amount of knowledge about legitimate past runs or
interleaved trial run of the protocol, intruder could:a) behave passively, waiting for a call to intercept – ( produce
cryptographic expression of flow 2 )
b) initiate a call ( produce cryptographic expression of flow 3)
Testing Resistance to Interleaving
Attacks
• Since protocol uses challenges and responses that
are always based on truly random numbers for
every instance, combining information from
various reference sessions in the hope that it may
be useful for an attack is impossible
• For any given message m, the attacker can know
E(m) only if it is able to cause the execution of the
protocol by A or B to send noncryptographic oneto-one function of E(m)
Specific Examples
1. Two encryptions
A
N1
B
N2, E(Nmin XOR B XOR E(N1 XOR N2)
E(N1 XOR N2)
Nmin = N1 if A < B
= N2 if A > B
•Secure against interleaving attacks
•Use two encryptions
•F() is the XOR of name of responder
•G() is XOR of two nonce
•B used as direction indicator
Specific Examples
2. Three encryptions
•Extra block encryptions added inside g()
•Result re-used with XOR of flow 3
N1
N2, E(N1 XOR B XOR E(N2 XOR E(N1)))
E(N2 XOR E(N1)) XOR E(N1)