Authentication in wireless - Security in Wireless Protocols

1. 1
Security in Wireless Protocols
Bluetooth, 802.11, ZigBee

2. 2
Topics
• The Authentication Problem
• Simple Device Authentication
• Development of the Challenge-Response
Protocol
• C-R Attacks and Countermeasures

3. 3
The Authentication Problem
• The authentication problem is to remotely
identify one entity, the “client” or “user” to
another entity, the “server”.
• The communications channel may be
limited: voice only, or radio signals only
• The client and server may have limited
capabilities: compute power, battery life,
etc

4. COEN 351 E-Commerce
Security
• E-Commerce Security Course Homepage
• Lecture Notes

5. 5
Security Requirements
• Requirements - must be able to verify that:
1. Message came from apparent source
or author,
2. Contents have not been altered,
3. Sometimes, it was sent at a certain
time or sequence.
• Protection against active attack
(falsification of data and transactions)

6. 6
Simple Client/Server Protocol
• The Client is a device or token such as the
one you hold in your hand and use to open
your car or garage door.
• The Server is the system that receives your
device’s signal and opens the door.
• The communications channel is infrared or
radio signals.

7. 7
Simple Protocol
• The simplest protocol is for the token to transmit
its 16 bit serial number, which also acts as a
password.
• Method 1: Thief can try all possible passwords.
Can usually open door after 215
tries which, at 10
per second, is about an hour.
• Method 2: Devices called “grabbers” became
available about 1995 which would record a signal
and replay it at a later time.

8. 8
Countermeasures
• Use longer passwords – 32 bits instead of 16 (this
really happened and manufacturers proudly
advertised increased security). Guessing
impractical but grabbers still work.
• Use different codes for open and close. Grabber
must be used at proper time.
• Additional vulnerability – serial number is known
by others – original vendor, service people, etc.

9. 9
What is Really needed
• The device needs to send something that can’t
simply be recorded and played back.
• Add a counter value, random number, or
timestamp to guarantee freshness.
– Problem with counters – the token and the dog
– Problem with random numbers (nonce) – token and
server must remember past codes
– Problem with timestamp – clock drift
• Encrypt so that attacker cannot fabricate message

10. 10
General Setting and Notation
• Many clients with devices (or tokens)
needing access to a building or large
parking garage.
• Notation: to show that X is encrypted with
key K write: {X}K
or K{X}
• Standard protocol notation:
<sender> → <receiver> : <message>
• Example: token sending to the garage
T → G: T, KT
{N}

11. 11
More Sophisticated Protocol
• Token sends to the garage: its name, T, followed
by the encrypted value of its name concatenated
with a nonce, N:
T → G: T, KT
{T, N}
• The garage verifies the open request by
deciphering the encrypted part and verifying the
token name is the same as the plaintext name and
that the nonce hasn’t been used before.

12. 12
T → G: T, KT
{T, N}
• This protocol is more secure. An attacker cannot
simply replay an old message. He cannot fabricate a
message even if he knows the token’s name and
guesses a fresh nonce unless he knows KT
.
• Key management: The server needs to remember
keys for many different tokens if it is a large garage.
Assign a global master key to the garage KM. Key
for each token is the token name or serial number
encrypted with the global master key. KT
= KM{T}
This scheme is called key diversification and is
widely used in smart cards.

13. 13
Challenge-Response Protocol
• Because of the problems with nonces, the
challenge-response protocol is often used to
provide a high degree of security.
• This requires an exchange of messages and
receiving as well as more processing ability on the
part of the token (Bluetooth device wanting to
access network).
• The server (door or lock) sends a challenge
consisting of a random number and the token
computes a response by encrypting the challenge.

14. 14
Challenge-Response
T → S: T
S → T: N
T → S: T, KT
{ N}
Note that the encryption used does not have
to be invertible. A “one-way function” or
cryptographic hash function can be used.

15. 15
802.11, Bluetooth and ZigBee all use
some form of the CR protocol for
authentication.

16. 16
Weaknesses in C-R
• The C-R protocol is widely used. However, it is
not unbreakable.
• Example: the random numbers generated by the
server are often predictable and cyclic. An
attacker can eavesdrop on a C-R session and
determine what the next challenge will be and
prepare a (perhaps pre-recorded) response.
• Note: most programming language library routines
for random numbers produce predictable number
streams.
• Man-in-the-Middle attacks

17. 17
Man-in-the-Middle
• A man-in-the-middle attack involves an
attacker “between” two legitimate parties
that can authenticate – perhaps using a CR
protocol.
• The attacker intercepts the messages and
replays them in ways to trick the legitimate
participants.

18. 18
Man-in-the-Middle Example
Early wireless devices would try to access a
network server that they were authorized on
automatically with a simple C-R.
T → S: T device T sends his ID to server S
S → T: N server S sends “challenge”
T → S: KT
{N} device responds automatically

19. 19
• The device will respond to any challenge by
properly encrypting the nonce without any
verification that the server S is who he says
he is.
• The man-in-the-middle can pretend he is a
server and obtain the encrypted nonce from a
legitimate device in the vicinity that will
automatically answer the challenge.
Man in the Middle

20. 20
Man In The Middle Attack
Network Server = NS
Network Device = ND
Rogue Device = RD
NS → RD: N
RD → ND: N
ND → RD: KT
{ N}
RD → NS: KT
{ N}

21. 21
Reflection Attack
• In order for this attack to work, the two principals
must be able and willing to identify themselves to
each other. This attack works if the challenge
system and response generator are not integrated
or if the response generator does not check the
name of the challenger. (Also if the token name
is not included in the encryption part.)
• Assume you have two wireless devices, one from
the red team and one from the blue team. Each
responds to challenges without verifying the
sender.

22. 22
Reflection Attack
Red enters Blue’s space and starts a network discovery
B → R: N Blue sends challenge
R → B: N Red reflects challenge back to
Blue
B → R: K{N} Blue’s automatic system
responds without noticing that it just sent out that
same challenge
R → B: K{N} Red gives proper response to Blue,
and is allowed into Blue’s network

23. 23
Thwarting the Reflection Attack
• Require an identifier to be included in the answer to
a challenge. Blue device #1
B1 → R: N Blue 1 sends challenge
R → B1: N Red reflects challenge
B1 → R: B1, K{N} Blue 1 responds
R → B1: B1, K{N} Red sends reflection attempt
which is detected!
• Connect the challenge and response generator logic.

24. 24
Manipulating the Message
• Red was detected because Blue’s name was part of
the message. Red responds by giving his devices the
ability to manipulate the message
B1 → R: N Blue sends challenge
R → B1: N Red reflects challenge back to Blue
B1 → R: B1, K{N} Blue responds, includes b3
R → B3: B2, K{N} Red knows the first part of the message
is the identifier and changes it!! Blue thinks Red is friendly
and lets him in --

25. 25
Using Hash Function H
If Red can remove and replace the identifier in the
response in the previous example, he can escape
detection. Solution: use a hash function to thwart the
attack (reflection or MIM) and hash the ID.
B3 → R: N Blue #3 sends challenge
R → B3: N Red reflects challenge back to Blue
B3 → R: B3, H{B3, N} Blue responds, includes b3
R → B3: B4, H{B3, N} Red gives response, Blue
calculates H{B4,N} and compares to Red’s response.

26. 26
C-R Improvements
• By faking a challenge, an attacker can get
several plaintext/cyphertext samples and break
the encryption.
• Modern systems authenticate the challenge
with encryption and only respond to valid
challenges.
• “Security Engineering, A Guide to Building
Dependable Systems” by Ross Anderson, Wiley, 2001

27. COEN 351 E-Commerce
Security
• E-Commerce Security Course Homepage
• Lecture Notes