Zero-Interaction Authentication
and Relay Attacks
Cooper Filby
Dr. Saxena
Babins Shrestha
Course Admin
HW4 Posted
• Covers IPSec (lecture 8) and Wireless Security (lecture 9)
• Due 11am on Dec 02 (Monday)
• Lab exercise involves capturing WiFi packets using Wireshark
• Labs active this Friday and next
Zero-Interaction Authentication
Zero-Interaction Authentication refers to technologies which allow users to
gain access to some secure entity without requiring manual interaction after
initial setup.
Examples:
-Key FOBs
-BlueProximity
Relay Attack Overview
A relay attack is a simple attack in which the attacker gains access to a
resource by impersonating each party of communication and facilitating
communication between them.
In essence, Party A thinks they’re communicating with party B, while party B
thinks it’s communicating with A, even though they’re not actually in
proximity with one another.
This attack can be used in a variety wireless protocols, including bluetooth,
RFID, NFC, and standard wireless networking.
NFC Relay Attack
http://nfc-tools.org/images/3/34/Relay_attack_access_control.png
Man-in-the-Middle Attack Comparison
A relay attack is conceptually similar to the Man-in-the-Middle attack, in which
a third party controls a connection between two authentic parties.
However, a man-in-the-middle attack usually entails manipulating the data
sent between two parties in order to facilitate unauthorized accessed or
connections.
A relay attack is a much simpler attack in which authentic data is forwarded
between the two parties in order to gain access to some asset. The attacker
doesn’t have to know about the contents of the data it’s forwarding.
BlueProximity
BlueProximity is a freely available
authentication tool that allows
users to unlock their machine
when a selected bluetooth enabled
device is in proximity.
Linux Based
Open Source, coded in Python
https://lh5.googleusercontent.com/_1QSDkzYY2vc/Tdt_QSOAO6I/AAAA
AAAAEj4/_VZ_kitzSDs/blueproximity.jpeg
How BlueProximity Functions
The user pairs a device such as their phone with their desktop/laptop that’s
running Blueproximity. Then, the BlueProximity process runs in the
background, scanning for nearby devices.
When the phone is outside of range, the desktop locks, and when the phone is
within a certain range, the desktop unlocks.
Can work without pairing, but the author recommends your device is paired
with your desktop/laptop.
Uses the PyBluez libraries for Bluetooth scanning and detection.
How secure is BlueProximity?
If blueproximity is a freely available software that users can install and use,
how secure is it?
- On Debian and Ubuntu, you can install it through apt.
Is device pairing alone safe enough to forego password based user
authentication on a desktop?
Does BlueProximity utilize any form of client authentication?
Initial Flaws of BlueProximity
By default, BlueProximity relies primarily on the MAC Address of the bluetooth
device for device identification and authentication.
- Extremely unsecure when unpaired
- Because of this choice, unlocking a machine is as simple obtaining the
mac address of the client device and spoofing it.
- BlueProximity recommends device pairing, but doesn’t verify that the
device is actually paired, it just tries to open a socket to that device if
it’s in range.
Initial Flaws of BlueProximity
Using the mac address for identification and authentication is flawed.
- MAC Address of a device isn’t secret, can easily be obtained by scanning
Pairing devices offers theoretically offers more security, but it’s still not ideal,
since the application relies on the security of bluetooth and has no further
authentication of the client.
Improving BlueProximity
These initial flaws of BlueProximity show that it is not particularly secure
against even basic attacks.
We improved BlueProximity by requiring pairing in order to function, which
should prevent the basic spoof attack.
Simple fix: Use the bluez-tools package to verify the device the user wants to
use with BlueProximity is paired with the machine.
The Intended Attack
Now that BlueProximity requires pairing to function, how do we gain access to
the target machine?
-Relay Attack?
Since BlueProximity uses no further authentication at the application layer
(based on our analysis of the source code), then we need to analyze the
security of the Bluetooth Pairing Protocol
Bluetooth
Short range communication protocol that relies on secure Personal Area
Networks (PANs) for communication.
-Individual devices identified by MAC addresses, much like ethernet
networking
Communication devices hop channels during a session, making it more
difficult to eavesdrop on communications without specialized equipment.
- Easy to record communications being sent to and from your device using
freely available tools
- Kismet, Wireshark, etc
- Promiscuous scanning more difficult with a standard dongle
- Ubertooth Device
Bluetooth Stack
A few important Bluetooth Stack Protocols:
LMP - Link Management Protocol, sets up and control
link between two devices
SDP - Service Discovery Protocol, used for finding
services provided by other devices (like Printing)
L2CAP - Logical Link and Adaptation Protocol,
connection oriented protocol
RFCOMM - Data stream protocol that relies on ports.
Similar to TCP, uses ‘sockets’
- BlueProximity relies on opening RFCOMM
connections
http://upload.wikimedia.org/wikipedia/commons/9/9f/Blueto
oth_protokoly.svg
Bluetooth Pairing
A method of bonding two devices, such that they can securely resume
communication after an initial exchange.
There are a few different pairing methods, most of which rely on basic user
interaction, such as providing a PIN or verifying numbers that appear on each
device.
During the pairing process, the two devices negotiate a Link Key that they can
use for future communication.
- When you unpair a device, it forgets that link key, meaning you need repair
the device for secure communication
Encryption can be used, although pairing primarily provides device authentication.
Bluetooth Pairing
Bluetooth Pairing
How Secure is Pairing?
While the above method appears to
be secure way of authenticating
participants, research conducted
by Levi et al. proposed a simple
method of doing a both a one and
two device relay attack to facilitate
unauthorized pairing.
- The attackers don’t need to
know the link keys, since the
authentic devices do end up
communicating with each other.
How Secure is Pairing?
Levi et al. were able to demonstrate their relay attacks using C++ to simulate the
Bluetooth protocol.
However, their proposed methods are not effective if encryption is utilized by the
bluetooth protocol.
-Pairing generally used to grant access, not to secure communications
In general, relay attacks are highly effective, although they can be detected if
communication is timed.
- In Levi et al.’s simulation, pairing when under the relay attack had a
noticeable time delay
- Recommend changes to Bluetooth protocols to detect and prevent relay
attacks
Security of BlueProximity
Given that the Bluetooth Pairing protocol can be beaten by a relay attack, it
stands to reason that our improved BlueProximity is not secure as a means
of access control to a desktop/laptop.
- Still could be convenient for the average user, but not practical when high
security is a necessity.
- While Bluetooth pairing is vulnerable to a relay attack, not everyone
would have the equipment to perform it.
Due to this research and the difficulty of accessing the lower level protocols of
the Bluetooth Stack, we opted to design a relay attack using a simple
authentication program to give a practical relay attack example.
SimpleAuth
Our basic bluetooth authentication protocol is written in Python, and relies on
PyBluez with RFCOMM socket communication to authenticate the mobile
client.
- The Desktop and Phone have a preshared Symmetric Key
- The Desktop generates a random challenge, which it then sends to the
client.
- The client receives the challenge, encrypts it with AES256 using the
preshared symmetric key and sends it back to the server
- The server then decrypts the key and compares it to the original
response. If it matches, the client is authenticated, otherwise the client isn’t
considered authentic.
SimpleAuth
Based on our knowledge of
Symmetric and Asymmetric key
algorithms, it’s pretty clear that
this isn’t a very good
authentication algorithm.
Challenge
Desktop
However, this is just serving as a
demonstration, even if we did
use a more improved RSA
based authentication approach,
it would still be vulnerable to a
relay attack.
EnckChallenge
Deck(EnckChallenge)
Verify
Phone
Cracking SimpleAuth
Based on our knowledge of Relay Attacks, there’s two main hurdles we need
to overcome in order to successfully implement our relay attack
- MAC Address spoofing
- Passing messages between impersonating devices
We choose to use two attacking devices for simplicity - one device would be
much less practical due to the short range nature of bluetooth. With two
devices, the phone and desktop could be miles apart and the attack would
still work, as long as attacking devices are in close proximity.
MAC Address Spoofing
With standard networking devices, MAC Address spoofing is pretty trivial.
- On Linux, it’s as simple as specifying it in your networking configuration,
such as /etc/network/interfaces on Ubuntu/Debian.
MAC Address spoofing on Bluetooth devices requires specialized tools and
devices by specific manufacturers.
- We can change the mac address using the bdaddr tool
- However, this often proves challenging, since not every bluetooth
dongle is reprogrammable.
- Of the six or more dongles we had, only 2 were
reprogrammable.
Communicating between attackers
Since SimpleAuth relies on prespecified MAC addresses for the client and
desktop, impersonation is as easy as spoofing these addresses on the
attack devices.
However, once the desktop tries to communicate with Attackerphone, how to get
the challenge to the authentic phone?
- Rely on bluetooth for communication between the attackers and the
authentic devices
- Rely on network sockets for communication between the attackers
The Relay Attack
Desktop
EnckChallenge
Bluetooth
Challenge
Challenge
Challenge
Attacker
Phone
EnckChallenge
Network Socket
Attacker
Desktop
Phone
EnckChallenge
Bluetooth
1. Desktop sends the challenge to AttackerPhone, which spoofs Phone.
2. AttackerPhone sends the challenge to AttackerDesktop, which spoofs Desktop.
3.AttackerDesktop sends the challenge to Phone.
4. Phone sends the encrypted challenge to AttackerDesktop.
5. AttackerDesktop forwards the encrypted challenge to AttackerPhone.
6. AttackerPhone delivers the encrypted challenge to Desktop.
7. Desktop verifies the encrypted challenge, authenticating AttackerPhone as Phone.
Demonstration
Results
As we can see, relay attacks are extremely simple and effective attacks on
authentication protocols.
How could we prevent such an attack?
- Timing of authentic versus compromised authentications
- Contextual Security
Contextual Security
Contextual security relies on utilizing context tags, which give some
information about the environment of a given electronic device.
Potential Context Tags Sources
- GPS
- Observed wireless traffic
- IDs of nearby devices
- Ambient audio fingerprints (and other sensor data)
Contextual Security
The above relay attack could easily be beaten if we used context tags between the
client and server.
In SimpleAuth, if we utilized context tags in our handshake, then it would be safe
against our simple relay attack.
Possible ContextAuth Design:
1. Server sends challenge to client
2. Client creates a context tag, and appends to to the challenge, encrypting
both with the preshared key.
3. Server decrypts the message from the client and verifies the challenge and
context tag.
Thus, if the client and server are in different locations, a relay attack would fail, as the
context tag sent by the client wouldn’t correspond to that of the server.
Conclusions
Zero-Interaction authentication, while extremely convenient for the end-user,
isn’t inherently secure.
Relay attacks are simple and effective attacks that can be used against poorly
designed Zero-Interaction authentication protocols.
Utilizing context tags in Zero-Interaction authentication protocols can greatly
increase the security of such protocols.
Conclusions
However, even with context tags, Zero-Interaction Authentication still has
some flaws:
- Client devices could be stolen.
http://xkcd.com/538/
Questions?