Android ended 2016 very close to becoming the world’s most popular operating system, with 86.8% of market share, losing by 2% in relation to Microsoft Windows. However, this small difference tends to be significantly overtaken by the end of 2017. That is because, at the end of last year, Google launched the Android Things initiative, which consists on the platform for developing a version of the operating system for devices classified as Internet of Things, or IoT.
According to the release, Android Things will be part of the Android ecosystem for smartphones and tablets and will be merged with Weave — a method of communication between IoT devices and Google resources through Google Assistant — already used in Samsung and Philips devices.
This is an attempt to create a standard ‘dialect’ for equipment, which multiplies exponentially, tending to reach tens of billions of devices by 2020.
In theory, this search for unification in the operating system of IoT devices is positive, because there is a cacophony in the software development for these devices which results in elementary security flaws, such as the use of insecure web interfaces, ineffective authentication controls, privacy violations and other vulnerabilities. While inserting concepts that standardise the operating system, incorporating common security features for all devices into a single ecosystem, it would be of great relevance to fight frequent problems, such as incorporating millions of IoT devices into botnets.
This kind of solution becomes even better when we consider that the Android ecosystem is open, with manufacturers that can incorporate improvements for all entities from the ecosystem and community developers that respect common rules in designing their applications.
Another factor that would contribute to improve security is the deployment, on IoT devices, of the granularity of permissions to resources (available since Android 6). In this mode, users can determine if an application can access the camera, microphone, SD card, etc.
Meanwhile, Android was the world’s most vulnerable operating system in 2016. According to CVE Details, 523 distinct vulnerabilities were discovered in Android, far ahead of the runner-up, Debian Linux.
One of the reasons behind this troubling number is the fact that the operating system is the most popular one among smartphones and tablets, and popularity attracts the interest of people who seek flaws. But there are also conceptual flaws in the principles that have made Android popular and have shaped its ecosystem.
The Android ecosystem involves several entities that collaborate with various functions of its operation. The Android Open Source Project operates as the maintainer of the development process of the operating system, which is conducted mostly by Google.
Chipset manufacturers — the companies that produce the set of electronic components that make up the integrated circuit — are responsible for developing the drivers that provide the interaction between the OS and the hardware. And device manufacturers (which produce smartphones and tablets) rely on these drivers to customise the version of Android for their devices. Many of these customisations also depend on carriers who implement special features, especially when the device is blocked for use on other carriers’ networks.
At the edges of the ecosystem are the application developers, who need to tailor their software to a set of standards, developed by the Android Open Source Project, and which must follow the changes with each version. And at the end of the chain is the user, who, from a security perspective, decides which permissions will be granted to each application, to use the resources of the device.
In a very enlightening document from 2013, the manufacturer HTC describes the process of updating Android in their devices, presenting the limits of responsibility of each entity, when a new version is made available.
The process starts with Google making available a software development package (Platform Development Kit) for the chipset manufacturers, along with the source code of the new version.
After analysing the code, the chipset manufacturer evaluates which of its products support the new OS features and performs a feasibility study of the development of the drivers for each of the eligible chipsets.
At this stage, the chipset manufacturer has the autonomy to decide if it will carry out the driver development project and this decision can be guided by both technical and business criteria.
Considering that the chipset manufacturer chooses to upgrade its drivers, it conducts development projects for each eligible chipset and, upon completion, sends them to all device manufacturers. At the same way, the device manufacturers conduct similar feasibility studies and choose which models will receive the upgrade. Again, both technical and business criteria will guide the decision.
While each device manufacturer conducts the necessary adjustments for the upgrade, it also initiates projects with carriers, as they may also have to update applications and specific functionalities to devices in their network, especially those that are blocked to operate with other carriers.
With the whole development process completed, the testing and certification phase is started, and that presupposes various comings and goings until the operating system is ready for use, when it receives the ‘Technical Acceptance’ from the carriers and Google. At the end of this phase, the operating system is made available for updating by the user.
During the update process of the operating system, the updating of applications also occurs, carried out by thousands of Android community developers around the world. The application update process is also driven by technical and business criteria, and developers can publish them on Google Play — the official app store — and / or various other unofficial Android application markets.
Considering the number of stakeholders, and the autonomy of each one of them to decide whether or not to update the software of their responsibility, having an unbalanced ecosystem is an inexorable consequence.
Researchers at the University of Cambridge could prove this in a study that involved the analysis of 20,400 devices. According to the survey, the rate of updates in the Android ecosystem is, on average, 1.26 per year. This number involves not only new versions of the operating system, but also security patches. This shows that there is a strong mismatch between the amount of vulnerabilities that are discovered and the number of updates that are made available to users.
The researchers were also able to establish a ranking, with scores from 0 to 10, for manufacturers and models, considering their efficiency in making security updates available. The best manufacturer in this ranking was LG with a rating of 3.97. This suggests that there is a great way for device manufacturers (and other entities in the chain) to commit to the security of the devices they sell.
In a report evaluating the implementation of various security initiatives on Android in 2016, Google demonstrates that, among other things, it has improved malware search engines that protect both the endpoint and the app store; it also implemented safe browsing and it improve controls against potentially harmful apps (PHAs). Most of all improvements, including those examples above, only cater to recent versions of the operating system.
Certainly, Android is evolving in security. The change in its access permissions model is an example of this. The previous model was very fragile. However, the biggest problem of Android’s security is what it makes it most conceptually attractive: its open ecosystem. That is because the individual interests of each ecosystem entity undermine the security of the entire platform.
Chipset and device manufacturers do not sell software, but hardware, and the market demands a lot of sales. It is a logical consequence to predict that the interests of these companies are not to maintain operating systems, especially in a time-consuming process and dependent on so many other companies, as is the case of Android. One of the reasons for them to opt for this operating system is to minimise development costs, because, otherwise, they would probably choose to implement their own software functionality, in an attempt to retain their customers.
But, in the race for innovation, it is more profitable to adopt a ready ecosystem, and the ‘ghost’ of Nokia’s history still serves as a lesson for manufacturers in this market.
What happens is that many manufacturers ‘enter the same boat’, which presupposes openness and collaboration; however, they also undergo market pressures to make a difference, promote innovations, and be cost effective, making programmed obsolescence essential for keeping the business driver working. And the boat ends up being formed by rowers interested in rowing to the side that better suits their individual interests. In a boat where each one rows to an individual side, the security of the whole boat is weakened.
To the costumer who purchases an Android-based device, is only guaranteed to have the version of the operating system installed on the device at the time of purchase, since few will be upgraded.
Nexus is one exception, which OS update process is maintained by Google and takes less time to be updated, but cannot be considered satisfactory because its different models received scores of 4.71 (Galaxy Nexus), 3.69 (Nexus 4) and 3.25 (Nexus 7) in the University of Cambridge’s study. In addition to this model, other developers are taking advantage of the open source code to develop alternative versions of Android, with increased security and privacy protections, such as CopperheadOS and Cyanogen OS, but with still modest numbers of users.
In past, we witnessed, for example, the discovery of serious vulnerabilities in the Android Kernel, and also threats such as trojans and botnets, which abuse the platform to perform Malvertising attacks or to defraud the digital advertising industry, among others. The trend, if the issue of roles and responsibilities between ecosystem entities is not improved, is that this situation will become worse, especially when the use of this operating system is disseminated to IoT devices.
This is an opportunity to reassess the model and implement measures that guarantee not only the maintenance of the market share, but also its security.
Researchers at the Georgia Institute of Technology have taken a step in this direction. In an extended article, they analyse the ecosystem in a broad perspective and describe their conceptual flaws.
Granting permissions to resources for applications in a granular way (Android 6 or higher) is considered by researchers as a problem that must be solved, because it transfers a substantial responsibility to the user, who can be misled by malicious application developers. In fact, this type of attack is already being executed, for example, by the FakeToken Trojan, which incessantly presents notifications to the user for him or her to grant root access to the device. The attacker relies on the fact that users will end up granting administrator permissions to avoid boring notifications.
Another important measure that can be taken is the hardening of the operating system by default. According to the researchers, there is a lot of material in this sense, but which is not implemented because manufacturers make their decisions oriented to the performance of the device and to reduce costs.
It is also necessary to review the way in which security updates are made available, building a security model that is respected by all manufacturers, and does not depend on several companies for the installation of patches with the function of protecting the device.
Finally, it is very important to review Google Play app store controls, making it a single point for downloading applications, and enforcing permission controls in the store itself. For example, if an application requests more permissions than necessary for its function, it should not even be available for download.
Without enforcement measures that guarantee freedom of innovation to ecosystem entities, but under strict controls that raise the level of user protection, it is not possible to recommend that critical activities be performed using the Android platform, except for advanced users that are well informed about new threats.
The principles of openness and freedom of Android presuppose interdependence in its process of continuous evolution. Unfortunately, however, the interests of entities exploiting the ecosystem are eroding the operating system, rendering it unreliable.
