Mobile devices are vulnerable to attack through their operating system, particularly through their drivers, and traditional protection such as anti-virus software is not enough. New software approaches such as hypervisors provide protection, but are not enough to fully protect the system. Secure, segregated areas for critical code have to be combined with secure communications in order to provide protection for mobile devices.
OS developers take security very seriously, and Apple patched the iPhone vulnerability quickly to retain confidence in its platform. However, device security often falls upon the handset manufacturers, not the OS vendor. As more complex OSes, such as Symbian, Windows Mobile and mobile Linux are used on handsets, handset manufacturers should not have to constantly worry about providing security updates as new vulnerabilities are identified in these large and complex OSes. It also undermines the utility of legacy software if code needs frequent patching and repatching to keep one step ahead of the hackers.
Ideally, developers need an environment that is inherently safe from attack, and provides the appropriate level of security for all code running in the target device.
One approach to device security is to work at the hardware level and create a "hardwired" trusted environment. This idea has been supported by the makers of some processors and memory manufacturers, with hardware implementations of a single, protected zone. This creates a trusted environment that can store all the secure data such as certificates for content protection, passwords and encryption keys with secure access.
Alternatively, such a solution could be used to protect key application code or drivers. However this happens in the same environment as other drivers and code that interacts with each other. If any software component in this space is compromised, then any other function in this same trusted area is vulnerable. The most fundamental issue, however, is that once the application OS (typically outside the trusted space) is compromised, the rest of the system--and therefore potentially the connected network--is still at risk from malicious attack.
Also, since this approach is a hardware solution, device manufacturers have to integrate the hardware blocks in the next iteration of their system-on-chip design, giving an often unacceptable lead time of 18 months before new capabilities can be introduced, or old features updated.
A better approach
A more flexible way to tackle the challenge of securing the mobile device, and still use current processor architectures, is to build a fully secure environment by incorporating an extension of virtualization technology into the functions of a hypervisor. A further key consideration is that this structure should be designed specifically for the performance and resource requirements of the embedded environment that builds in security at the system level. The essential issue for embedded developers is how to achieve this while retaining their familiar OS and development tools, and without taking a significant hit to performance or system resources. This is vital for the designer of mobile devices where processor cycles, power and memory are all constrained.
The first requirement of such a secure system design is to minimize the "attack surface" of the code running on the underlying hardware in privileged mode. The smaller this code size, the more likely it is to be bug free, and the smaller the target it presents. The ideal solution is to use a real-time microkernel running in privileged mode to implement virtualization and hypervisor functions by taking exclusive control of the processor MMU. This allows system memory to be divided into an appropriate number of segregated and secure areas (cells) in which all other software is forced to run in user mode.
Each secure cell may contain any system component(s)--OS, application or driver. Most importantly of all, these secure cells--and their system components--operate in user mode only.
Since there is now no other part of the system that has access to the privileged mode of the processor or the MMU, the hypervisor integrity cannot be compromised either by malicious attack or defective code gaining access to software running in a secure user mode cell. Essentially, the hypervisor is occupying an inaccessible "hyperspace" from the point view of any other system code.
Furthermore, since any number of user mode system components can be segregated individually in secure and isolated cells, the potential impact of malicious or unstable code on the system as a whole can be limited precisely to the extent determined by the developer, according to the requirements of the application.