Feature

Mobile device security through virtualization

A hypervisor running in privileged mode allows a more flexible approach, providing security for mobile devices.

By Rob McCammon, Open Kernel Labs -- EDN, 7/1/2009

Mobile handsets are getting smarter. However, behind this fact is complexity: Designs are growing more complex and connectivity issues are evolving, adding to the challenges that developers face in creating mobile devices. As handsets become more robust and feature-rich, they are also becoming more vulnerable to attack through their operating systems.

This problem is taken seriously by the carrier networks; however, device security often falls upon the handset manufacturers, not the carrier or OS vendor. Handset manufacturers should not have to constantly worry about providing security updates as new vulnerabilities are identified in these large and complex OSes and networks.

What is needed is a secure environment that encapsulates and protects device operating systems, device drivers, and applications and drivers on mobile devices. In turn, this will secure beyond the handset to other connected systems, from the enterprise network to the wireless carrier, giving an unspoiled and safe end-user experience.

Addressing device security at the hardware level by creating a "hardwired" trusted environment that can store all the secure data, such as certificates for content protection, passwords, and encryption keys, has been supported by the makers of some processors and memory manufacturers. However, with this approach, hardware implementations come in a single, protected zone, and once this single zone is accessed, all of the information in the trusted area is breached. Another major issue with this approach 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. Additionally, because this approach is a hardware solution, device manufacturers have to integrate the hardware blocks in the next system-on-chip design, resulting in a long lead time of 18 months before new capabilities can be introduced, or old features updated.

Another approach is to build a secure environment by incorporating an extension of virtualization technology into the functions of a hypervisor. This method involves developing secure, segregated areas for critical code, combined with secure communications, to provide protection for mobile devices. This structure should be designed specifically for the performance and resource requirements of the embedded environment that builds in security at the system level.

By choosing the virtualization approach, the developer can build in security at the system level, providing the ability to flexibly partition the system in accordance with security requirements. The essential issue for embedded developers with this method 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 because processor cycles, power, and memory are all constrained.

Nevertheless, the developer can address the inherent vulnerability present in the hardware approach by choosing the virtualization method. This approach provides a more flexible way to tackle the challenge of securing mobile devices, while still using current processor architectures.

How to build a secure environment

To build a fully secure environment by incorporating virtualization technology into the functions of a hypervisor, the developer must create secure, isolated areas for critical code and implement secure communications between those areas. 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 (memory management unit). System memory can 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, from the OS to the application to the driver. All of these secure cells—and their system components—operate in user mode only.

At this point, the hypervisor cannot be compromised by either malicious attack or defective code gaining access to software running in a secure user mode cell, because no other part of the system has access to the privileged mode of the processor or the MMU. The hypervisor is now in an inaccessible "hyperspace." Any number of user mode system components can be isolated in secure cells, meaning the potential impact of malicious code on the system as a whole can be limited to the extent determined by the developer. Such a secure environment would also allow for safe updates of individual drivers or OS components, since the new code could be downloaded into the secure cell and verified without endangering the running systems.

However, development of this segmented environment does raise an important issue. One or more parts of the secured systems are now running multiple isolated cells at the user level, which calls into question how they will communicate with each other without compromising security. To ensure the proper security, a fast and flexible communication mechanism is needed. It should run entirely within the microkernel/hypervisor and manage a communications policy that is not accessible by any user mode process.

A secure IPC mechanism would only allow secure cells to communicate outside the cell in accordance with a specific policy. The IPC is running in privileged mode, along with the microkernel, making it secure from any malicious code in a secure cell. Even if code in an individual cell is infected, access to other cells can be restricted according to the policy to minimize the threat to the other system components. This mechanism will therefore allow efficient, yet secure, support for interprocess communication.

Using secure hypervisor technology, large OSes in smartphones can run in user mode inside a secure cell under the control of a hypervisor, occupying as little as 45 kbytes. Even if the application OS is now compromised, the hypervisor—running in privileged mode—is still in control of the system and not at risk. Each system component can be isolated (OS code in one secure cell, drivers in another, and each application in its own cell), which means that if one cell is compromised, the malware cannot break out and access other parts of the system.

The microkernel is secure, as it is the only code running in privileged mode and it has its own protected memory area. It is therefore completely isolated from any cell that may be subject to intrusion, so the device cannot be compromised at the hardware level, even if other parts of the system are infected. It not only makes the target device more secure, but also more reliable in operation because one compromised driver cannot crash the whole system. This segmented approach can deliver several other benefits to the developer, beyond the immediate question of security.

The use of virtualization technology in this approach is what allows the application OS to run in a secure user-level cell. It also enables the legacy real-time OS/scheduler used by the developer in the original featurephone to coexist with the application OS on the same processor, if desired. Therefore, the real-time performance and legacy code are not sacrificed, easing the migration task and avoiding the need to add a second processor, which also eliminates extra costs.

Once this virtualization design is implemented, the developer can switch out the first application OS for another without major changes to the underlying platform and without requiring new drivers. This provides a higher degree of application OS independence and greatly reduces the cost, risk, and time-to-market involved in upgrading to smartphone capability through addition of a rich OS to an existing mobile handset design.

Author Information

As vice president of product management at OK Labs, Robert McCammon oversees product management from de-fining product definition to developing industry sales strategies. Leveraging his deep embedded systems market experi-ence, McCammon is responsible for defining and creating new market opportunities. Previously, as director of ad-vanced technology planning at Wind River Systems, he was responsible for establishing plans and priorities for ad-vanced technology development to address future product requirements. McCammon received a master's degree in management from Northwestern University, a master's in computer engineering from the University of Southern Cali-fornia, and a bachelor's in computer engineering from the University of Illinois at Champaign. He can be reached at RobM@ok-labs.com.