It’s likely that Android’s development team tested the waters by collaborating with the Chrome OS development team. A feature called Easy Unlock entered the Chrome development channel last spring. If you enable the feature in the development channel and you’re a competent enough coder, you may be able to test Easy Unlock yourself. You may need to have both an Android mobile device and a Chromebook in developer mode, and enable the feature on both devices. If the code is workable by now, when properly configured it should allow you to unlock your Chromebook with your Android phone or tablet. I’m not sure which versions of Android, Chrome OS, or Chromium OS are needed, nor do I know what the package dependencies may be. So, if you’re going to try Easy Unlock, you’ll be doing so at your own risk. It’s possible that when Easy Unlock is stable, it’ll be renamed to Smart Lock, for unison with the new Android 5.0 feature. Smart Lock will probably be a handy feature for many users. But my concern is whether or not Smart Lock introduces significant new security vulnerabilities to the Android and Chrome OS ecosystem. There’s no publicly available technical documentation on Smart Lock as of this writing. But I do know that 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 Smart Lock. Google recently acquired Impermium, so I’m optimistic that they kept security in mind. Here’s how the Bluetooth implementation may be attackable. How Can Bluetooth Be Attacked? For Defcon 2013, Charlie Miller and Chris Valasek demonstrated how the embedded systems in the 2010 models of the Ford Escape and the Toyota Prius can be penetrated. What their attack has in common with Android Smart Lock is that it’s a way to attack a car’s computer with Bluetooth. The major difference is that I’m not sure if Android Auto will have any access to a vehicle’s driving mechanisms. For that reason, I’ll speculate that Electronic Control Units that interact with the steering and breaking aren’t a component of Android Auto. Android Auto might just give passengers access to general Android apps and functions (SMS, etc.), with GPS navigation, weather, and traffic reports for the driver. But Miller and Valasek are among many researchers who have found ways to use Bluetooth to attack an embedded car system, which makes me concerned about the Bluetooth functionality in Android Auto, with or without ECUs. The most potentially destructive Bluetooth vulnerability is man-in-the-middle attacks. Bluetooth usually uses EAP-AKA (Extensible Authentication Protocol- Authentication and Key Agreement) or EAP-SIM (EAP- Subscriber Identity Module) for authentication when such a framework has been implemented. A Bluetooth device, such as one using Android 5.0’s Smart Lock, will acquire master keys from an authentication server. Bluetooth standards from 2.1 to 4.1 require encryption, which usually uses an AES algorithm. But encryption may be bypassed by conducting a man-in-the-middle attack, which involves spoofing packets with the headers that are used between a user’s authorized Bluetooth devices, which can be a computer and a peripheral, or two computers. Smart Lock communications are between two computers, as all devices running Android are. Bluetooth communication designates one device as the master and the other as the slave, but the two devices may frequently switch roles. . There’s a Bluetooth penetration testing suite called Bluediving. It has versions that run in Windows, GNU/Linux, and FreeBSD. Bluediving contains all the tools that are necessary for a man-in-the-middle attack. An attacker’s laptop running Bluediving should first sniff packets that are used in the Link Management Protocol process when one Smart Lock device authenticates with another. The man-in-the-middle attack can work if the attacker’s laptop is Bluetooth capable and connected to a WLAN, which may be open WiFi, or the attacker may 3G or 4G tether with their own phone or tablet. The sniffed packets contain the data the attacker’s laptop needs to bypass the encryption- an authentication code, a Master Session Key, and the encryption command. Those are exchanged during an EAP-AKA challenge. The attacker’s machine starts the spoof by replaying that traffic to whichever Smart Lock device is the slave. Now the slave thinks the attacker is the master. The attacker completes the EAP authentication process, which renders whatever encryption is implemented to be irrelevent. The attacker is decrypting now, and the cipher didn’t even need to be cracked. That’s because a new, compromised MSK has been generated for the attacker, through their own WLAN connection to an internet server. Although the Bluetooth standard has measures that address authentication, it lacks measures for integrity. Because of the lack of integrity verification in the standard, the attack is able to hijack the authentication procedure in order to spoof for a man-in-the-middle attack. Now that the attacker’s machine is the “man-in-the-middle,” if their machine has other software that can exploit vulnerabilities in Android 5.0 and Smart Lock, the attacker can truly wreak havoc. At the very least, with the successful man-in-the-middle attack, maliciously unlocking Smart Lock on the Android device that’s the Bluetooth slave should be a piece of cake. Through Smart Lock, the Android device will think the attacker is a legitimate user, so even the default filesystem encryption in Android 5.0 may be bypassed. That’s wonderful for the attacker, because cracking AES128 is a real pain in the ass. With 2014 technology, it could take a computing cluster years. The longer it takes to crack an encryption algorithm, the greater the risk is that the attacker will be caught. How Could Smart Lock’s Bluetooth Be Implemented More Securely? A more secure use of Bluetooth involves only having Bluetooth turned on when absolutely necessary, and having discoverability turned on only when the two legitimate Smart Lock are initially connecting. Here are the two common scenarios I can imagine with Smart Lock use. The user could be wearing an Android 5.0 smartwatch, and have their Android 5.0 phone or tablet in their purse or their pocket. Or, the user could be in their car that has Android Auto (Android 5.0 in a car’s embedded system), and it unlocks their Android 5.0 phone or tablet. Discoverable mode can be on only when the Smart Lock devices authenticate each other, but Bluetooth will need to stay turned on for both devices for the duration of Smart Lock use. But it may be a hassle for the user to have discoverability turned off, just in case the user’s two devices need to reconnect after disconnecting for whatever reason. Oops! That’s an opportunity for an attacker. I really hope that Smart Lock only uses Bluetooth 4.1, because so many more vulnerabilities are known for all previous versions of Bluetooth. I imagine more successful 4.1 attacks will exploit zero-day vulnerabilities. It’s much more difficult for an attacker to find a zero-day. It would be great if Smart Lock requires both devices to switch their master and slave roles frequently, because an attacker will need to focus on the slave for a man-in-the-middle attack. All passkeys that Smart Lock uses should be at least eight digits long. Obviously, the longer the better. Google’s servers that operate the Smart Lock feature should change a user’s link keys as frequently as possible. When Google releases technical documentation for how Smart Lock uses Bluetooth, we’ll get a better idea as to if they take security seriously. I hope that Google has penetration tested the feature thoroughly. But I won’t be at all surprised if I hear about a successful Smart Lock attack technique at next year’s Defcon. I personally won’t ever use the feature myself, even though I’ll have at least a couple of Android 5.0 Lollipop devices of my own in the next few months. I see this as yet another situtation where making a system more user friendly renders it less secure. References Adventures in Automotive Networks and Control Units- Charlie Miller and Chris Valasek http://illmatics.com/car_hacking.pdf Bluetooth Security- NSA https://www.nsa.gov/ia/_files/factsheets/i732-016r-07.pdf Android 5.0 Lollipop Official Website http://www.android.com/versions/lollipop-5-0/ Bluetooth Connectivity Threatens Your Security- Aaron Stern, Kaspersky Blog http://blog.kaspersky.com/bluetooth-security/ A man-in-the-middle attack using Bluetooth- Eric Gauthier, Security Science http://www.security-science.com/mastering-internet-security/internet-security-ebooks-and-documents/item/a-man-in-the-middle-attack-using-bluetooth Top 5 Bluetooth Hacking Tools- Hack Yogi http://hackyogi.com/top-5-bluetooth-hacking-tools/ New Chrome feature will allow users to unlock a computer with a smartphone- Conner Forrest, Tech Republic http://www.techrepublic.com/article/new-chrome-feature-will-allow-users-to-unlock-a-computer-with-a-smartphone/ Security- Bluetooth Developer Portal https://developer.bluetooth.org/TechnologyOverview/Pages/Security.aspx
