In an earlier post, I asked engineers who develop software for connected and autonomous cars to consider the true cost of using Linux from a monetary as well as a safety-certification and security perspective. A friend emailed me after reading that post, asking why I didn’t discuss the security vulnerabilities of Android and why I gave it a “hall pass”. The short answer is that I believe one can architect a virtual cockpit controller that preserves the security and safety-certification benefits of QNX while enabling Android applications – which is where Android differentiates – a best of both worlds approach. In fact, our concept car (Jaguar Land Rover) cockpit at CES was based on QNX (Cluster and Hypervisor) and a QNX IVI with Android (Apps) running in a virtual domain. With Linux you get the security vulnerabilities and the extra OpEx (R&D cost), but no real differentiation. With Android, at least you get the popular Apps.
Let’s first discuss what my friend was talking about.
The Business Insider/Statista chart below provides an independent view on security vulnerabilities of various operating systems:
Of the 523 vulnerabilities attributed to Android in the above chart, 254 had a CVSS (Common Vulnerability Scoring System) score of “9” or higher, indicating that these vulnerabilities were deemed severely critical. According to SC Magazine, in 2016, Google Android had more vulnerabilities than other operating systems in the mobile phone world. The charts below, based on the latest CVE statistics from NIST (National Institute of Standards and Technology), demonstrate that the number of Android or Linux CVEs is orders of magnitude higher than QNX CVEs through the end of 2017.
That said, Android implementations can vary among mobile phone suppliers. To differing degrees, some of them add numerous modifications, made by skilled engineers, to improve the security posture of Android. BlackBerry leads the pack with the most secure Android implementation of all vendors. Yet, that is a hard job and requires a lot of highly skilled engineers and security experts. The questions is, “what issues should one consider when deploying Android in vehicles?”.
Android is not free
Some people consider Android to be “free”. Let’s consider the merit of that belief. Rich, user-friendly, apps are at the core of the Android value proposition. As with all high-value apps (Android marketplace, Google Maps, Earth, Voice Search, Local Search, etc.), such Android apps require licensing, which means that there are costs associated with them.
Secure rendering of Android requires skilled engineers and security experts who improve the security risk posture. That takes time, effort, and ultimately serious R&D investment.
With respect to automotive applications, there are further complications that raise questions:
- Android Trademark can only be used with devices that comply with Google’s Compatibility Definition Document and Compatibility Test Suite.
- Not all Android apps run on all platforms.
- It is unclear whether the OEM, or Google, will control the vehicle user interface, platform capabilities and application verification.
- Will OEMs allow Google access to their vehicle CAN bus data? That data is valuable, and access to that data can justify giving an OS away for free. Such data, for example, can be used for mapping, autonomous driving and user preferences.
- As mentioned above, just as with mobile phones, the onus is on the OEM to implement security features that prevent interaction between Android or its apps and safety-critical subsystems in the vehicle.
Therefore, beyond license fees, the security engineering, support, optimization, and maintenance investment required for Android must be considered. Often, a 3rd party Android services firm or an in-house team must be assembled to provide these expensive services.
Frequency of Android releases
There are two important maintenance considerations in the automotive context. First, Android needs regular, likely monthly, updates as do mobile phones. Does an OEM have to update cars in the field, say every month, over their lifetime (which on average is around 11 years)? In addition, to reference the mobile phone experience once again, we have seen numerous major and sub-releases of Marshmallow, Nougat, Oreo, and now P, in less than 2 years (detailed in the table below). Furthermore, each of these releases only receives support for 2 years. In the automotive industry, it takes 2-3 years to develop a product and guide it through Start of Production (SOP), and another 5-6 years of platform production. Of course, post-production, the car can easily be on the road for another 5-15 years.
| Code Name | Version # | Initial Release Date |
| Marshmallow[12] | 6.0 – 6.0.1 | October 5, 2015 |
| Nougat[13] | 7.0 – 7.1.2 | August 22, 2016 |
| Oreo | 8.0 – 8.1 | August 21, 2017 |
| Android P | 9 | May 8, 2018 (beta) |
What is the cost of these upgrades and updates, and the potential liability of an unpatched risk?
Safety & Security
Now, back to the topic of CVEs and their intersection with automotive trends. If you have been following automotive trends in the market, you know that ECUs are consolidating into fewer Domain Controllers. For example, Virtual Cockpit Controllers (VCCs), in which infotainment and instrument cluster ECUs are consolidated to run on a single-SoC high-performance Domain Controller compute platform, save costs and reduce complexity. However, for a VCC to work properly, the system needs true type-1 hypervisor capabilities that can isolate safety critical (instrument cluster) and non-safety critical (IVI) functions from each other. Some OEMs have decided to use a full-blown Android Automotive in-car infotainment system, integrated into a cockpit controller, running on a single SoC, that also supports the safety-certified Instrument Cluster, as shown in the diagram here. We believe this idea is susceptible to safety and security vulnerabilities.
From a security perspective, Android introduces a large attack surface to a vehicle’s software system. A digital instrument cluster must be certified to ISO 26262 ASIL B safety, while infotainment units do not have any safety certification requirements. As outlined above, it is very likely that Android-based systems require frequent updates and patches due to a high number of vulnerabilities (CVEs). ISO 26262 safety certification requires that software updates to the infotainment sub-system must not affect the safety-critical instrument cluster sub-system. However, if all infotainment functions run on Android, any security vulnerability (CVE) update that impacts a shared driver (e.g. audio, graphics, etc.) or resource could pose a risk that OEMs and their Tier 1 suppliers must address with a software update. To make the above situation even more complicated, Android has not been architected with virtualization or for co-existence in a consolidated cockpit Domain Controller. This means additional complexity in the system.
Let us consider a new way of approaching this with an emphasis on safety and security while leaving room for brand differentiation. How about a well-architected system that isolates safety-critical and non-critical functions using virtual machine (VM) domains and restricts the access and functionality of an Android VM (e.g. only runs consumer Android apps) to reduce risk to the safety function? By restricting access and functionality, the large attack surface exposed by Android is reduced. All this, while providing the capabilities to avoid a “me too” product. Blackberry QNX has developed such a solution.
In the BlackBerry solution, connectivity interfaces such as USB, Bluetooth, Wi-Fi, as well as buses, such as the CAN bus, and other resources including Browser and Media files are “owned” and controlled by the more secure QNX VM. At the same time, the system designer can use QNX’s screen capabilities to manage what and how content is displayed, regardless of where the content is being generated (Android VM, QNX VM, or other).
So, to answer my friend’s question as to why I wasn’t as critical of Android as I was of Linux, I believe there is a solution, such as the one architected by QNX, to build a virtual cockpit controller where one gets the security and safety-certification benefits of QNX while enabling Android valuable applications, which is where Android differentiates. On the other hand, AGL’s CVE profile, as described in my previous blog post speaks for itself.
No system in the world can claim total security forever. Security is like a race in which you need to constantly stay ahead of bad actors. Playing in the muddy waters of AGL not only prevents you from differentiating yourself from the crowd but, in fact, can hold you back.
As automakers look to consolidate domain functions such as infotainment, telematics, and digital instrument clusters into a virtual cockpit controller, QNX SDP 7.0 provides a best-in-class real-time OS that supports 64-bit compute platforms for the ARMv8 and Intel x86-64 architectures, along with true type-1 hypervisor virtualization capabilities, for a safety-certified and secure connected car. BlackBerry QNX’s foundational software platform gives automakers the freedom to choose any car platform app (Android Apps, Apple CarPlay, Baidu CarLife) for products around the world, while keeping safety-critical domains of the car securely isolated. Finally, BlackBerry QNX neither wants to own the OEM’s data nor control the brand-differentiating user Interface.
At the end of the day when you calculate total cost of ownership, the equation in favor of QNX ought to be obvious. For more information, visit us online.
