Tapkey against Bluetooth Relay Attacks

Tapkey not vulnerable to Relay Attacks on Bluetooth

Different kinds of attacks have been demonstrated on Bluetooth-enabled locking mechanisms over the last few years. Just recently, a new kind of relay attack was demonstrated that allows the opening and operation of Tesla cars. We at Tapkey are often asked by our customers whether Tapkey is affected by the demonstrated kinds of attacks on the Bluetooth technology standard. The short answer: It is not and has never been. Here’s why.

First some background. The majority of demonstrated attacks fall into two types, which I will discuss in more detail:

Attacks on the security protocols built into the Bluetooth Standard
Relay Attacks

Attacks on Security Protocols

Bluetooth comes with encryption built into the standard. Protocols have been defined that should allow secure pairing of and communication between Bluetooth-enabled devices. Security researchers have identified vulnerabilities in these protocols, especially regarding the pairing procedure, that make them vulnerable to eavesdropping or could even allow attackers to take control over affected devices.

Tapkey is not affected by these kinds of vulnerabilities, because Tapkey’s security protocols are built *on top* of the Bluetooth standard. This means that Tapkey doesn’t rely on the security of Bluetooth’s built-in cryptography, but instead implements all required encryption and other crypto in additional protocols that are independent of the Bluetooth standard. One of the reasons for that is that the protocols built into the standard have not been designed with cloud-based, many-to-many kind of operations in mind as they are the very nature of Tapkey devices.

Relay Attacks

Communication via Bluetooth is usually limited to a proximity range of only a couple of meters. Bluetooth devices have some ways of reasoning on the actual distance, like measurement of the signal strength or applying trigonometry to name just two of them. The problem with these is that they are not reliable. On the one hand they are not precise, but more importantly a communication partner can either estimate the distance of the other party or verify its identity, but not both together. So a party can either know where the other party is but not be sure that it’s really the one it’s pretending to be, or verify its identity, but not be sure that it is anywhere close. The major way of reliably and securely measuring the distance between mobile devices would be the measurement of the time of flight of a signal in combination with some cryptography (i.e. measuring the time it takes for a signal to be sent by a first party (the mobile device), to be received by the other party (the lock/car), have the other party do some cryptography and to be returned to the first party), but this needs support built into the technology stack on a very low level. Unfortunately, this kind of functionality has not been built into the Bluetooth standard and cannot be retrofitted into today’s real-life hardware.

Now, why is this a problem?

Some products offer unlocking via some kind of hands-free mode (also called keyless entry, keyless go, etc.). I.e., a mode where it is sufficient to bring a key (or in our case a mobile device) close to a lock (or a car) in order to operate it. No additional interaction is required between the owner of the key and the key (mobile device) itself. This is usually implemented by the app running on the mobile device reasoning on the distance between the mobile device and the locking device and sending an unlock command if within a certain range. But due to the lack of support from the Bluetooth standard, neither the mobile app nor the locking device can be sure that the party being in close range really is the one it is pretending to be. This allows a pair of attackers doing the following (simplified procedure):

A person (let’s call her Alice) has a mobile device with a legitimate key for some other person’s car (let’s call him Bob).
Attacker 1 (let’s call her Mallory) brings her mobile device with a custom malicious app close to Alice’s phone.
Mallory’s phone pretends to be Bob’s car by replicating the car’s advertising data.
Alice’s phone can just see that Bob’s car seems to be nearby, but not verify its identity. Alice’s keyring app has hands-free mode built in, so it nevertheless sends a legitimate unlock command to Mallory’s phone (because it assumes it’s Bob’s car).
Mallory’s phone receives the key and forwards it to the second attacker’s (let’s call him Malcolm) mobile device.
Malcolm brought his phone close to Bob’s car already, and the malicious custom app on his phone forwards the key to Bob’s car, pretending it’s Alice’s phone.
Bob’s car verifies the key, which succeeds, as it is Alice’s legitimate key. However, Bob’s car can only see that Alice’s phone seems to be nearby, but cannot verify its identity.
Bob’s car unlocks.

This attack allows Mallory and Malcolm to unlock Bob’s car, even though Alice is nowhere close. Maybe she’s even in a different country.

Can handsfree unlocking be securely implemented at all using today’s smartphones and based on only Bluetooth? “Not to my knowledge.” says Tapkey CTO & Co-CEO Markus Minichmayr.

Does this mean, using Bluetooth for physical access is unsecure? No. It just means that implementing hands-free mode in a secure manner does not seem to be possible if based solely on Bluetooth technology.

Why isn’t Tapkey affected?

The Tapkey App simply doesn’t implement any kind of hands-free mode, and any 3rd party apps integrating the Tapkey Mobile SDK are heavily discouraged to do so. When unlocking via the Tapkey app using Bluetooth, the procedure is always initiated by the users themselves and always involves some kind of user interface. So an attacker cannot cause the Tapkey app to issue a command by themselves. Moreover, the UI always shows the name of the lock being opened and requires the user to confirm the unlocking procedure via some physical interaction. As users usually only initiate unlocking operations when they are in front of the door and wouldn’t confirm unlocking door Y when they stand in front of door X, relaying is not a threat in most cases.

By the way, there are alternatives to hands-free mode that allow providing a great user experience *and* avoiding the discussed security issues. The Tapkey App for iOS for example comes with a Widget for the Today Screen, which gives users quick access to their locks nearby. With the Tapkey App for Android, NFC can be used for unlocking, which allows getting access by just tapping a lock with an unlocked Android phone. In both cases, an intentional user interaction is still required. So the discussed vulnerabilities don’t apply, while nevertheless a great user experience is offered.