How Can Android Smart Lock Be Attacked?
When the official details of the new features in Android 5.0 Lollipop were released last week, Android Smart Lock piqued my interest. It is a lock screen control feature that uses Bluetooth connectivity between a user’s Android 5.0 devices to unlock their phone, tablet, and smartphone screens when they are within broadcast range of other Android 5.0 smartwatches or built-in Android Auto.It’s likely that the Android development team was testing the waters in collaboration with the Chrome OS development team. The feature, called Easy Unlock, entered Chrome’s development pipeline last spring. If you enable this feature in the development pipeline and are a competent enough coder, you may be able to test Easy Unlock yourself. You may need to have both your Android mobile device and your Chromebook in developer mode and enable the feature on both devices.
If the code is already working, it should allow you to unlock your Chromebook with your Android phone or tablet after proper configuration. I’m not sure which versions of Android, Chrome OS, or Chromium OS are needed, nor do I know what the package dependencies might be. So if you’re going to try Easy Unlock, you do so at your own risk.
It is possible that when the Easy Unlock feature is stable, it will be renamed to Smart Lock to be consistent with the new Android 5.0 feature.
Smart Lock is likely to be a handy feature for many users. But I wonder if Smart Lock introduces significant new security flaws into the Android and Chrome OS ecosystem.
At the time of writing, there is no publicly available technical documentation for Smart Lock. But I know it uses Bluetooth for communication and authentication, which is probably the most pragmatic radio technology for its purpose.
I can only speculate how Bluetooth is implemented for the Smart Lock. Google recently acquired Impermium, so I’m optimistic that they thought about security.
Here’s how a Bluetooth implementation can be hacked.
How can Bluetooth be hacked?
Charlie Miller and Chris Valasek demonstrated for Defcon 2013 how to break into the embedded systems in a 2010 Ford Escape and Toyota Prius. Their attack has something in common with Android Smart Lock in that it’s a way to attack the car’s computer using Bluetooth . The main difference is that I’m not sure Android Auto will have any access to the vehicle’s steering mechanisms.For this reason, I will speculate that the electronic control units that work with the steering and braking are not part of Android Auto. Android Auto can only provide passengers with access to general Android apps and features (SMS, etc.), with GPS navigation, weather and traffic reports for the driver. But Miller and Valasek are among the many researchers who have found ways to use Bluetooth to attack an embedded car system, which worries me about Bluetooth functionality in Android Auto, with or without an ECU.
The most potentially destructive Bluetooth vulnerability is man-in-the-middle attacks.
Bluetooth typically uses EAP-AKA (Extensible Authentication Protocol-Authentication and Key Agreement) or EAP-SIM (EAP-Subscriber Identity Module) for authentication, if such a framework has been implemented. A Bluetooth device, such as a device using Smart Lock Android 5.0, obtains master keys from an authentication server. Bluetooth standards from 2.1 to 4.1 require encryption, which usually uses the AES algorithm.
However, encryption can be bypassed by performing a man-in-the-middle attack, which involves forging packets with headers that are used between the user’s authorized Bluetooth devices, which can be a computer and a peripheral or two computers. Smart Lock communication is between two computers, just like all Android devices. Bluetooth communication designates one device as the master and the other as the slave, but the two devices can often switch roles. .
There is a Bluetooth penetration testing suite called Bluediving. It has versions that run on Windows, GNU/Linux and FreeBSD. Bluediving includes all the tools necessary for a man-in-the-middle attack. An attacker’s laptop running Bluediving should first sniff the packets that are used in the Link Management Protocol process when one Smart Lock device authenticates with another. A man-in-the-middle attack can work if the attacker’s laptop supports Bluetooth and is connected to a WLAN, which could be open WiFi, or the attacker can 3G or 4G tether to their own phone or tablet.
The captured packets contain the data the attacker’s laptop needs to bypass the encryption – the authentication code, the session master key, and the encryption command. These are exchanged during the EAP-AKA challenge.
The attacker’s machine initiates the spoof by replaying this traffic to any slave Smart Lock device. Now the slave thinks the attacker is the master. The attacker completes the EAP authentication process, which renders any implemented encryption irrelevant. The attacker now decrypts and the cipher didn’t even need to be cracked. This is because a new, compromised MSK was generated to the attacker through his own WLAN connection to the Internet server.
Although the Bluetooth standard includes measures that address authentication, it lacks measures for integrity. Since the standard lacks integrity verification, an attack is able to hijack the authentication procedure to forge a man-in-the-middle attack.
Now that the attacker’s machine is a man-in-the-middle, if his machine has other software that can exploit the vulnerabilities in Android 5.0 and Smart Lock, the attacker can really wreak havoc. At least with a successful man-in-the-middle attack, maliciously unlocking Smart Lock on a Bluetooth slave Android device should be a breeze.
Through Smart Lock, the Android device will treat the attacker as a legitimate user, so even the default file system encryption in Android 5.0 can be bypassed. This is great for an attacker because cracking AES128 is a real pain in the ass. With 2014 technology, this could take years of a compute cluster. The longer it takes to crack an encryption algorithm, the greater the risk that an attacker will be caught.
How could Bluetooth Smart Lock be implemented more securely?
More secure use of Bluetooth includes turning on Bluetooth only when absolutely necessary and having the discoverability option turned on only when two legitimate Smart Locks are initially paired.Here are two common scenarios I can imagine using Smart Lock. A user can wear an Android 5.0 smartwatch and have an Android 5.0 phone or tablet in their purse or pocket. Or the user can be in their car that has Android Auto (Android 5.0 in the car’s built-in system) and unlock their Android 5.0 phone or tablet.
Visibility mode can only be turned on when the Smart Lock devices authenticate each other, but Bluetooth will need to remain on for both devices while Smart Lock is in use. However, it can be a problem for users to have visibility turned off in case the user’s two devices need to reconnect for whatever reason after disconnecting. Oops! This is an opportunity for the attacker.
I really hope the Smart Lock only uses Bluetooth 4.1 because there are many more known vulnerabilities with all previous Bluetooth versions. I imagine the more successful 4.1 attacks will exploit zero-day vulnerabilities. It is much more difficult for an attacker to find a zero-day.
It would be great if Smart Lock required both devices to switch their master and slave roles frequently, as an attacker would need to target the slave for a man-in-the-middle attack.
All passkeys that Smart Lock uses should be at least eight digits long. It goes without saying that the longer the better.
Google servers running Smart Lock should change user link keys as often as possible.
Also Read:Ethical Hacking Interview Questions 2023
When Google releases technical documentation on how the Smart Lock uses Bluetooth, we’ll get a better idea of whether they’re taking security seriously. I hope Google has thoroughly tested this feature.
But I won’t be at all surprised to hear about a successful Smart Lock attack technique at the next Defcon. Personally, I will never use this feature, even though I will have at least a few Android 5.0 Lollipop devices of my own in the next few months. I see this as another situation where the system is more user friendly and less secure.