Mobile devices are increasingly coming under attack from malicious applications. As more complex operating systems (OS), such as Symbian, Windows Mobile, and Linux are used in handsets, providing security updates and identifying new vulnerabilities has become more complicated. Addition ally, frequent patching and rewriting of code to keep one step ahead of hackers undermines the utility and longevity of legacy software. What developers really need is an environment that is inherently safe from attack and provides the appropriate level of security for all code running in the target device. Secure, segregated areas for critical code must be combined with secure communications in order to provide protection for mobile devices.

System-Level Security

The most flexible way to secure mobile devices is to build a fully secure environment by incorporating an extension of virtualization technology into the functions of a hypervisor. This structure should be designed specifically for the performance and resource requirements of the embedded environment, building in security at the system level. The essential issue for embedded developers is achieving this while retaining the 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.

Minimizing the "attack surface" of the code running on the underlying hardware in privileged mode is the first step for this system. The shorter the code, the fewer the bugs and the smaller the target. Ideally, a real-time microkernel running in privileged mode is used, using virtualization and hypervisor functions by taking exclusive control of the processor MMU. Then, system memory can be sectioned into segregated, secure cells where all other software runs in user mode.

Each secure cell may contain any system component(s) — OS, application or driver. All of these cells and their components operate only in user mode. Only the hypervisor runs in privileged mode of the processor or the MMU. Its integrity cannot be compromised either by attack or misbehaved code running in the cells, which operate only in user mode. The hypervisor occupies an inaccessible "hyperspace" away from any other system code. Because the user mode components are securely segregated, they are also protected from each other. This environment enables safe and secure remote update of individual drivers, or other OS components, since the new code could be downloaded into its own secure cell and verified without any danger of compromise to the running system.

Secure Inter-Process Communication

This approach raises another important practical issue. With one or more parts of the secured system now running inside multiple isolated cells at user level, how do they communicate with each other without compromising security? This requires an inter-process communication (IPC) that can:

  1. Run entirely within the microkernel/ hypervisor;
  2. Manage a communications policy that is not accessible by any user mode process.

Essentially, such a secure IPC mechanism only allows code running in secure cells to communicate outside the cell as determined by a pre-set policy. Running the IPC as part of the microkernel entirely in privileged mode, it is invulnerable to any compromised code in a secure cell. So, even if code in a particular cell is compromised, the IPC can restrict access to other cells, minimizing the threat to other system components (e.g. the RF device, the Linux OS environment), while allowing efficient yet secure inter-process communication to be supported. Figure 1 shows this model.

Smartphone Strategy

The security threat is an important concern for smartphone developers. These devices run application operating systems such as Linux, Symbian, or Windows Mobile, resulting in several megabytes of code running in privileged mode. Using a secure hypervisor, these large application operating systems can run in secure cells (in user mode) under the control of a hypervisor occupying as little as 65 KB. Even if the application OS is compromised, the hypervisor, running in privileged mode, retains control and is not at risk.

The OS code can be in one secure cell, drivers in another and each application in its own cell, meaning that if one cell is infected, the rest of the system is unaffected. The microkernel's vulnerability is minimized because its memory space does not contain the application OS, drivers or applications. This makes the target device more secure and also more reliable.

Featurephone Strategy

Figure 1. By partitioning system memory space into secure cells with only essential functions running in privileged mode, and allowing communication between cells only through a secure IPC mechanism, system security can be assured to whatever level is appropriate for the application.

This approach can deliver several other benefits to the developer other than security. For example, a developer may upgrade a featurephone design to a smartphone. Adding an application OS such as Linux to a featurephone obviously introduces a "step function" in security exposure to the design. The cell structure approach already described will cover this issue.

However, there are also other advantages. Application operating systems run in secure user-level cells. The OS/scheduler used in the featurephone can also co-exist with the application OS on the same processor so that performance and legacy code is not sacrificed. This eases migration and avoids adding a second processor.

After the virtualized design is in place, the first application OS can be traded for another without any major change to the underlying platform and without new drivers. This provides a higher degree of application OS independence for developers. This same approach can also be used to consolidate a dual OS (e.g. RTOS + application OS) design using two processors on a single core to save BOM and power.

Figure 2 shows a possible implementation using this approach, taking full advantage of the existing legacy code, with the added advantage that it deals with the increased security risk inherent in the upgrade to a smartphone environment.

Virtualization and Open Source

In recent years, open source software use has been on the rise. But is open source software more or less secure than proprietary software? At first blush, it seems that proprietary code, being confidential, is more "hackerproof" than open source that is visible to everybody. But, most developers actually consider an open source code base to be a benefit in creating a more secure environment. In their experience, the fact that more experts have contributed to the code, and its likelihood of being used in several different applications, translates into robustness in security of the code base.

Figure 2. By consolidating smartphone and featurephone application environments onto a single CPU target, additional hardware cost can be minimized, while also addressing the increased security problem

In short, security by obscurity is a poor strategy. The universal accessibility of open source code generally ensures that there are many more engineers testing and evaluating every aspect of a piece of code than code from a proprietary vendor. Their detailed feedback creates a hardier, proven code base where more vulnerabilities and risks have been identified and avoided.

Conclusion

As embedded devices become more powerful and more connected, new security risks for devices continue to emerge. While some of these threats are still new, they are growing. Many device security solutions are ported from the PC world and come in the form of point solutions such as firewalls being spread throughout the design chain, but mobile devices require smarter protection. Using a microkernel with secure communications allows developers to protect the entire mobile device. This provides a segregated, secure environment that protects the device and the network. Beyond device security, an embedded hypervisor setup allows developers to adapt security levels and support as a particular device requires.

This article was written by Rob McCammon, Vice President of Product Management, OK Labs (Chicago, IL). For more information, contact Mr. McCammon at This email address is being protected from spambots. You need JavaScript enabled to view it., or visit here .