Proactive Mobile Defense: Android
A two-day mobile security training course on secure application and software development
+ read more
Inspecting the Android Auto solution - with guidance around the security considerations of implementing it in apps and head units
Google are working for vehicles to become more connected, as seen in their self driving car project. But they are also working in other ways to make vehicles smarter. One of these is “Android Auto”, a solution to build a bridge between vehicle head units and user’s Android devices, launched in June 2014.
This article inspects the Android Auto solution, and gives guidance to security considerations of implementing it in apps and head units.
Android Auto is a way for Android smart phones, and the apps that they run, to connect into a vehicle’s console and sound systems. It’s made up of three components:
There are several key concerns when connecting devices to vehicles in this manner. We don’t want to lower the security of the phone or its apps, nor do we want to communicate insecurely with the vehicle from the phone. Finally for head unit and vehicle manufacturers, we don’t want to risk allowing mobile users to access more functionality than just the console screen and vehicle sound systems.
For app designers, Android Auto is a useful feature that makes apps more usable by having them show notifications on a car’s console, or by allowing them to play media through the car sound system. Android provide clear instructions to developers to show how to use this API in their apps.
If a developer wants their notifications to show up on the console, then they can build notifications in the regular Android manner, but extended with CarExtender. The Android’s Auto App will pick up these notifications and handle getting them to the head unit.
It is also possible for the app to be informed when a user has acknowledged the notification, or maybe has produced a reply. In this case, the app needs to add a pending intent to the notification.
Pending intents have been known to have some security issues in the past. By using them, the app is allowing another app to call activities that are then executed with its privileges. The Google developer pages show how both to do this securely and insecurely.
The type of pending intent is up to the developer, but must be included in the app’s AndroidManifest.xml. The example shown by Google has two major security flaws:
Firstly the broadcast receiver has an intent-filter, but is not marked as export=false. This means that any other app on the same device could call these end-points and interact with this app in an unintended way.
The second issue is that the app is using broadcasts for pending intents. This means that the messages will be broadcast to any app that is interested to register a broadcast receiver. SMSmessages are usually strictly controlled on modern Android devices so that only apps that the user has selected can read their text messages. It is recommended that instead, an Activity is used as a pending intent.
Using pending intents can be used securely. Google’s guide to the subject can be found here
Car manufacturers also need to consider security protections when designing and implementing Android enabled head units. Many in vehicle entertainment systems aren’t simple music players, but instead connect to many components of the car so as to display information such as fuel consumption and engine temperature. As has been shown in several recent reports car hacking is more than just a theoretical attack, so an attack from an Android device should be considered when designing and Android Auto head unit.
In some instances Android is used on the Android enabled head units, making it an area with known vulnerabilities and known exploits. Manufacturers should therefore be careful to enforce two key areas of security: segregation and patching.
Patching is a well-known method in the IT world to keep systems safe from known issues. But in embedded devices there is the issue of how to get the latest versions of libraries and applications to a system that may not have a network connection, or at least not one capable of transferring large files.
For some manufacturers, the choice has been made to rely on the customers to patch – a method becoming avoided in the IT world – but where possible a process of patch management could form part of a vehicle’s servicing.
The other area of segmentation is a more technically complex one. Android has always used app sandboxing to keep apps’ data separate, and to prevent an app reaching resources that it should not be able to access through the permissions model. Similar considerations will needed to be given to apps on the head unit. We do not trust the media coming from our customers’ devices, so what would happen if the media app is compromised through malicious input? Hopefully the media app has only the few permissions it needs, so a compromise would have little impact on the vehicle’s safety. Otherwise mobile malware may take on a far more dangerous form.
As we have seen, Android Auto provides a simple and effective way for apps to interact with head units through well documented API. However as with building any type of Android application, it is important to understand and design products with security in mind. In the case of using Android in vehicles, this presents a unique landscape, with unique challenges. It will be important to be proactive to make sure that customers remain confident in products.