Embedded Technology

Developing mission-critical IoT devices in Android: the benefits and challenges

By Steve Howard, Field Engineering Manager, Static Code Analysis at Perforce Software


n addition to being the leading platform for smartphones, Android is also increasingly being used as the platform for a variety of IoT devices, including mission- and safety-critical products and systems. However, development of Android- based systems — or more specifically, the Android Open Source Project (AOSP) — comes with potential risks that must be mitigated. Otherwise, vulnerabilities could be introduced, which in turn could lead to product failure or even security breaches.

If potential risks are common, why is AOSP development becoming popular for the IoT? AOSP has some compelling benefits. First, AOSP is open-source, free, and supported by a worldwide community of experts and resources. Plus, AOSP is more than just a basic operating system. Compared to typically embedded development platforms, AOSP is ready to go, with prebuilt elements, which means that it is straightforward to work with and shortens the development cycle. AOSP contains a rich stack of components that includes graphical interfaces, communication systems, and more. Based on a Linux kernel, Android has a hardware abstraction layer, libraries, and APIs that are written in C and C++. Above them resides the Java (or Kotlin) application software that runs on a Java application framework. In total, Android contains around 25-30 million lines of code, split roughly 50/50 between C/C++ and Java. All this gives embedded software developers a comprehensive and appealing box of tools from which to work.

Mission and safety critical environments

Beyond its more common uses in games consoles, televisions, and digital cameras, AOSP is becoming the foundation for many other innovations. One example is the automotive infotainment system, which is

32 July/August 2021

increasingly used as the dashboard for multiple onboard systems, such as adjusting wipers and lights for poor weather conditions, and for all car-to-X communications. Therefore, the infotainment system is progressively becoming a mission-critical system.

AOSP is also being used to develop medical devices. For instance, one Israeli-organisation we work with is developing an intelligent drug delivery system that ensures that monitors patient requirements and delivers the necessary mix of drugs accordingly. Innovations such as this are more viable using AOSP as it reduces time-to-market and development costs.

By necessity, all mission- and safety-critical situations must have a high emphasis on safety and security. Products and systems may also need to adhere to compliance requirements, such as the FDA for medical devices or ISO 26262 for the automotive industry.

Risk mitigation

Running in parallel with AOSP’s benefits are some downsides. One of the most significant is that 25-30 million lines of code adds complexity — especially when it’s across many communication interfaces. Therefore, the potential attack surface is massive. Furthermore, as AOSP is open source, anyone can look up the code and find vulnerabilities to exploit. Conversely, those vulnerabilities are well documented and therefore easy to monitor and address. The National Vulnerability Database (NVD) provides a comprehensive insight into relevant Common Vulnerabilities and Exposure (CVE) identifiers. A quick search of the NVD using the keyword ‘Android’ found over 7,000 matching results (Of course, these vulnerabilities will likely span the entire Android lifespan, going back 13 years). Maintained by the Forum of Incident Response and Security Teams (FIRST), another

Components in Electronics

helpful resource is the Common Vulnerability Scoring System (CVSS), an open industry standard for assessing the severity of software vulnerabilities. The CVSS can help companies prioritise vulnerabilities on which to focus: A score of 0.1 — 3.9 would indicate low risk, 4.0 — 6.9 would be a medium risk, 7.0 — 8.9 would be a high risk, and above 9.0 would be flagged as a critical risk.

To make this task easier, some tools automatically match CVEs to open source software packages based on versions and platforms, and provide filtering based on CVSS scoring.

Alongside the NVD’s CVE database is the Common Weakness Enumeration (CWE), a free list of the most typical vulnerabilities (including the top 25 for the current year). The list is gathered together by the CWE community and covers both hardware and software. Sponsored by the MITRE Corporation, the CWE list is updated every few months and encompasses over 600 categories.

Using static analysis tools to check the application-specific code and AOSP customisations for CWEs, will provide an indication of the risks from those areas of the system. The CWE Top25 is a frequently used coding standard that focuses on the most commonly occurring vulnerabilities. By enforcing good coding rules and supporting compliance

requirements, coding standards also help engender a more uniform and higher quality of coding practices across an organisation. Testing has always been a fundamental part of the software development lifecycle, but never more so than today, particularly with the advent of DevOps and ‘Shift Left’, whereby testing takes place earlier in the process to unearth vulnerabilities sooner. With AOSP, traditional testing mechanisms will be limited due to the sheer size and complexity involved. Automated analysis options are more appealing, and while dynamic testing tools might struggle with scale and size, efficient static code analysis tools are able to scan the code in a linear time to identify new vulnerabilities as they are created.

CVEs, the CWE list, and the CVSS are all freely available resources, it is only the tools that improve the efficiency of working through them that requires some investment. AOSP has powerful advantages for all kinds of IoT applications, including mission critical ones. As long as the associated risks are addressed, developing AOSP-based embedded systems can help deliver better products faster and more cost-effectively, but with safety and security built in.

Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58