1 Security in Wireless Protocols Bluetooth, , ZigBee

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

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 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)

5 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.

6 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 2 15 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.

7 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.

8 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

9 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:  : Example: token sending to the garage T  G: T, K T {N}

10 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, K T {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.

11 T  G: T, K T {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 K T. 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. K T = KM{T} This scheme is called key diversification and is widely used in smart cards.

12 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.

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

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

15 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

16 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.

17 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: K T {N} device responds automatically

18 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

19 Man In The Middle Attack Network Server = NS Network Device = ND Rogue Device = RD NS  RD: N RD  ND: N ND  RD: K T { N} RD  NS: K T { N}

20 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.

21 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

22 Thwarting the Reflection Attack Require an identifier to be included in the answer to a challenge. Blue device #1 B1  R: NBlue 1 sends challenge R  B1: NRed 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.

23 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 --

24 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: NBlue #3 sends challenge R  B3: NRed 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.

25 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