Many security experts regard Android as the wild west of IT. An OS based on Linux developed by Google primarily for the mobile devices but now becoming key to many end points associated with IoT, Automotive, Televisions etc. With over 80% of smartphones running Android and most of the rest using Apple’s iOS, Android is well established and security is a big concern.
Imagine you are a big bank and you want 20000 employees to be able to access your secure network from their own phones (BYOD, Bring Your Own Device) or you want to offer your millions of customers your bank’s branded payment application on their own phone. How do you do it?
Android and iOS have very different security models and very different ways they can be circumvented. Apple with iOS have gone down the root of only allowing verified applications from the Apple store to be installed. If users want to install other applications they can compromise their devices by Jailbreaking their iPhone or similar. Jailbreaking can allow not only the end user to circumvent Apple controls in iOS but also malicious third-parties. IoS implements a locked bootloader to prevent modification of the OS itself or allowing applications root privileges.
Many people describe “rooting” on Android as equivalent to Jailbreaking. It isn’t. Android already allows users to add additional applications (via side-loading). Rooting of an Android devices can allow the OS itself to be modified. This can present a huge security risk as once the OS on which applications has potentially been compromised, an application running on it can’t really establish if the device is secure. Asking pure software on a device “hello, compromised device – are you compromised?” is simply a risky and silly question. Software alone theoretically can never guarantee to detect a device is secure.
There are pure software applications that pertain to establish if a device is compromised usually via techniques such as looking for common apps that can only be installed if a device is rooted/jailbroken, or characteristics left by rooting/jailbreaking applications, or signs of known malicious viruses/worms etc. These often present a rather falsely reassuring picture as they will detect the simplest and majority of compromises so it looks like such applications can detect a potentially unsecure device. However, for the most sophisticated of compromises where the OS itself is compromised the OS can supply such applications with the answer that the device is secure even if it isn’t. Being able to patch and upgrade the OS has a number of technical benefits, so some OEMs ship Android devices rooted and there is a huge ecosystem of rooting kits to enable it to be done. Rootkits can be very sinister and hide themselves though, lurking waiting to be exploited.
Knowing your OS is compromised is a comparable problem to that faced with hypervisors in virtualisation and one that can be solved by relying on hardware security where the hardware below the OS can detect if the OS is compromised. Technologies such as Intel TXT on servers takes a footprint of a hypervisor, locks it away in a hardware unit and compares the hypervisor to the reference on boot ongoing, if the hypervisor is meddled with the administrator is alerted.
Recognising the need for security for Android and other rich OSs, technologies have emerged from OEMs and chip designers that rely on hardware security. Usually these technologies include hardware support for trusted execution, trusted root and isolation with a stack of partners involved to ensure end applications can access the benefits of hardware security.
Typically, there is some isolation where both a trusted and untrusted processors and memory are provided, (some technologies allow the trusted and untrusted “worlds” to be on the same processor). The trusted world is where tested firmware can be kept and it remains a safe haven that knows what the stack above it including the OS should look like. Trusted execution environments (TEE) and Trusted Root are common in cloud and mobile and have enabled the wide-spread adoption of and confidence in mobile pay applications etc.
Many IoT products have been built upon chips designed for mobile phones, thin clients etc. and as such with Linux/Android OSs have the capabilities to support hardware supported security. However, many embedded devices were never designed to “be connected” with such security considerations. For the IoT (Internet of things) to succeed the embedded and OEM ecosystems need to look to hardware based security following the success of the datacentre and mobile in largely solving secure connection.
Of course, it all depends on the quality of execution. Enabling hardware security is a must for a secure platform however if a software stack is then added where a webcams default password is hardcoded the device can be compromised.