Patent Application
20050166064
This invention relates to a trusted user interface for a secure mobile wireless device. The user interface forms an element of a platform security architecture.
Platform security covers the philosophy, architecture and implementation of platform defence mechanisms against malicious or badly written code. These defence mechanisms prevent such code from causing harm Malicious code generally has two components: a payload mechanism that does the damage and a propagation mechanism to help it spread. They are usually classified as follows:
Security threats encompass (a) a potential breach of confidentiality, integrity or availability of services or data in the value chain and integrity of services and (b) compromise of service function. Threats are classified into the following categories:
Games are an important application category for mobile wireless devices, but expose the device to high levels of security risk Usually, games require direct access to the screen memory or to a graphic accelerator in order to perform fast bitmap operations. However, allowing direct access to the screen is an open door to the following threats:
Hence, conventional screen memories (also known as frame buffers) present an Achilles heel to platform security since applications such as malicious or badly written games can grab or alter sensitive information (e.g. passwords etc.) displayed on screen. Hewlett Packard PCT/GB00/02005 shows one possible approach to solving this aspect of platform security: it discloses a PC with a secondary, secure hardware system (video chip, frame buffer) to prevent unauthorised access to sensitive information. The user interface can therefore be thought of as trusted when sensitive information is being displayed. This hardware solution would however be prohibitively expensive to implement in a mobile wireless device (typically a ‘smartphone’, enhanced mobile telephone, PDA or other personal, portable computing device) because of space and cost constraints.
Hence, mobile wireless devices offer very considerable challenges to the designer of a platform security architecture. To date, there have been no effective proposals for trusted user interfaces for secure mobile wireless devices.
In a first aspect of the present invention, there is a mobile wireless device programmed with software which provides a trusted user interface for the device by allowing the content of a secure screen memory to be accessible or modifiable only by authorised applications, the software operating automatically to detect whether an application is an authorised application, to thereby eliminate the need to deploy additional secure hardware as a mechanism for ensuring the integrity of the secure screen memory.
In one implementation, the address locations of the secure screen memory are known only to the window server and the kernel, which can make this memory available solely to executable code with the appropriate capability. ‘Capability’ refers to a property assigned to executable code which defines the sensitive actions which that code can perform or the sensitive resources which that code can access.
Secure and non-secure frame buffers are usually physically distinct parts of the same RAM based screen memory and hence no costly hardware duplication is required for implementation (e.g. no separate secure hardware crypto-processor, memory or display processor, as required in some prior art solutions).
The secure screen memory provides a trusted resource so that sensitive dialogs (e.g. entering PINs or digitally signing a document) can take place in a secure environment. Normally, the entire screen memory address is public information, making the entire screen memory fully available to any application; hence, even sensitive dialogs would use screen memory which can in theory be looked at by malicious software, enabling that malicious code to grab PIN data etc. or corrupt a trusted user interface.
But with the present invention, unauthorised applications are prevented from accessing the data displayed by the secure frame buffer because they are able to access only the non-secure screen memory. Hence, malicious applications cannot retrieve data from a trusted dialog or compromise that data. Further, as the present invention is a software only solution, it requires no new hardware per se—the only requirement is that the software window server and the video device driver run by the kernel can select content from different parts of screen memory—i.e. secure and non-secure frame buffers.
A further feature is that input events such as keyboard, mouse and pen events are collected by the kernel and sent to the window server only. The window server is responsible for dispatching events to the appropriate window's process owner. In trusted user interface (UI) mode, no input events can be globally captured or redirected in order to prevent an un-trusted application to grab sensitive information typed by the user, such as a password.
In an implementation, there is a visual indication is provided to the user when the trusted user interface is active; the indication can be hardware based, such as a particular LED being lit. It can also be software based, such as a particular screen icon or message being displayed in an area of the screen forbidden to other applications. In all cases it is under the control of the kernel. Only the window server, owner of the secure frame buffer, can ask the kernel to switch this indicator on or off, hence providing a way for the user to identify a genuine trusted dialog from a fake one.
In another aspect, there is an operating system adapted to run on a secure mobile wireless device in which the operating system provides a trusted user interface for the device by allowing the content of a secure screen memory to be accessible or modifiable only by authorised applications, the software operating automatically to detect whether an application is an authorised application, to thereby eliminate the need to deploy additional secure hardware as a mechanism for ensuring the integrity of the secure screen memory.
The present invention will be described with reference to the security architecture of the Symbian OS object oriented operating system, designed for single user wireless devices. The Symbian OS operating system has been developed for mobile wireless devices by Symbian Ltd, of London United Kingdom.
In this architecture, a trusted path between the user and the OS kernel is provided: this prevents untrusted applications from retrieving or compromising data from a trusted dialog.
1 Trusted Computing Platform
1.1 Trusted Computing Base
A trusted computing base (TCB) is a basic architectural requirement for robust platform security. The trusted computing base consists of a number of architectural elements that cannot be subverted and that guarantee the integrity of the device. It is important to keep this base as small as possible and to apply the principle of least privilege to ensure system servers and applications do not have to be given privileges they do not need to function. On closed devices, the TCB consists of the kernel, loader and file server, on open devices the software installer is also required. All these processes are system-wide trusted and have therefore full access to the device. This trusted core would run with a “root” capability not available to other platform code (see section 2.1).
There is one other important element to maintain the integrity of the trusted computing base that is out of the scope of this invention, namely the hardware. In particular, with devices that hold trusted computing base functionality in flash ROM it is necessary to provide a secure boot loader to ensure that it is not possible to subvert the trusted computing base with a malicious ROM image.
1.2 Trusted Computing Environment
Beyond the core, other system components would be granted restricted orthogonal system capabilities and would constitute the Trusted Computing Environment (TCE); they would include system servers such as phone and window servers . . . For instance the window server would not be granted the capability of phone stack access and the phone server would not be granted the capability of direct access to keyboard events. It is strongly recommended to give as few system capabilities as possible to a software component to limit potential damage by any misuse of these privileges.
The TCB ensures the integrity of the full system as each element of the TCE ensures the integrity of one service. The TCE cannot exist without a TCB but the TCB can exist by itself to guarantee a safe “sand box” for each process.
2 Process Capabilities
A capability can be thought of as an access token that corresponds to a permission to undertake a sensitive action. The purpose of the capability model is to control access to sensitive system resources. The most important resource that requires access control is the kernel executive itself and a system capability (see section 2.1) is required by a client to access certain functionality through the kernel API. All other resources reside in user-side servers accessed via IPC [Inter Process Communication]. A small set of basic capabilities would be defined to police specific client actions on the servers. For example, possession of a make calls capability would allow a client to use the phone server. It would be the responsibility of the corresponding server to police client access to the resources that the capability represents. Capabilities would also be associated with each library (DLL) and program (EXE) and combined by the loader at run time to produce net process capabilities that would be held by the kernel. For open devices, third party software would be assigned capabilities either during software installation based on the certificate used to sign their installation packages or post software installation by the user. The policing of capabilities would be managed between the loader, the kernel and affected servers but would be kernel-mediated through the IPC mechanism.
The key features of the process capability model are:
“Root” capability—Used by the Trusted Computing Base only, it gives full access to all files in the device.
System Capabilities
Some system servers require some specific access to the Trusted Computing Base.
Because of the object-oriented implementation of Symbian OS, the kind of resources required by a system server is most of the time exclusive to it. Therefore, one system server would be granted some system capability that would be orthogonal to those required by another. For instance, the window server would be granted access to keyboard and pen events issued by the kernel but it would not have permission to access the phone stack. In the same way, the phone server would be granted access to the phone stack but would not have permission to collect events from the kernel. As examples, we can name:
2.2 User-Exposed Capabilities: Mapping Real-World Permissions
The process of generating capabilities can be difficult. One has first to identify those accesses that require policing and then to map those requirements into something that is meaningful for a user. In addition, more capabilities means greater complexity and complexity is widely recognised as being the chief enemy of security. A solution based on capabilities should therefore seek to minimise the overall number deployed. The following examples map fairly broadly onto the main threats which are unauthorised access to system services (eg. the phone stack and preserving the confidentiality/integrity of user data.
It is necessary to make a distinction between PhoneNetwork and LocalNetwork because it is possible to transmit information across a network without spending any money (eg. Bluetooth piconet). This kind of access may be a very useful third party software enabler but nonetheless represents a local way of leaking sensitive information via a trojan horse so it must be protected with a capability, albeit LocalNetwork PhoneNetwork, if granted by the user, would allow trojans seeking to use the phone network as their exit route; that is potentially much more damaging and hence the blunt warning in its description.
Root and system capabilities are mandatory; if not granted to an executable, the user of the device cannot decide to do it. Their strict control ensures the integrity of the Trusted Computing Platform. However the way servers check user-exposed capabilities or interpret them may be fully flexible and even user-discretionary.
2.3 Assigning Capabilities to a Process
The association of a run-time capability with a process involves the loader. In essence, it transforms the static capability settings associated with individual libraries and programs into a run-time capability that the kernel holds and can be queried through a kernel user library API. The loader applies the following rules:
It has to be noted that:
These rules
The examples below show how these rules are applied in the cases of statically and dynamically loaded libraries respectively.
2.3.1 Examples for Linked DLLs
The preferred implementation defines a system capability called TrustedUI. Processes running with this capability are defined as trusted for using the trusted user interfaces.
3.1 Identification of Trusted Dialogs by the User.
A trusted user interface is required to prevent spoofing of trusted user interface by malicious third party software and thereby provide a trusted path to the user interface within the TCB. This is very important, particularly as we move to the world of multi-functional trusted personal devices acting as smart wallets. For instance, both the PIN enter dialog and the transaction sign dialog would benefit from a comprehensive trusted user interface. If lacking, a malicious application could steal PIN data and use data protected by this PIN without the knowledge of the user.
There are two ways of showing that a trusted user interface is active:
However, trusted dialogs within the context of the Symbian OS platform is about more than a trusted visual indicator and would raise further requirements on client access to the display manager APIs (eg. the window server). It is also about displaying information in a frame buffer that untrusted applications (like games) cannot access and ensuring that keystrokes cannot be captured from a trusted dialog by an untrusted application.
3.3 Identification of Use Cases
Games are valuable because of their popularity amongst customers. Their numbers, qualities and “play-ability” are often used as main selling point for smart phones. Usually games require direct access to the screen memory or to a graphic accelerator in order to perform fast bitmap operations. However allowing direct access to the screen is an open door to the following threats:
If the economic risk of denial of service attacks is low (the user cannot use his device but other users, network operators and service providers are not touched), the attacks on confidential data are more serious. The attacker might be able to breach the users privacy and/or to spend users money by accessing confidential data.
To sum up, games have got two main characteristics that require contradictory security features:
It is a fundamental security feature that system capabilities must be restricted to core components only. The more applications are granted system capabilities the less relevant the capability model is. This poses a particular challenge for games.
3.4 Giving Direct Screen Access to Games Without Compromising Trusted Dialogs
Conventionally, the screen memory address is mapped as global, so in practice every application knowing the address can access the screen memory directly. This address is fixed for each type of mobile wireless devices and therefore if published it can be reused by anyone for this device.
An implementation of the present invention physically separates the screen memory associated with untrusted applications from the screen memory used by trusted dialogs. The window server will be liable for telling the video driver which frame buffer should be displayed.
3.4.1 Assumptions
Even if “two frame buffers” requires more screen memory, it is a good solution for the following reasons
In order to protect the user against fake trusted dialog attacks, a LED or reserved screen space must be used. A LED would be preferable, saving screen space and probably be more easily understood by users.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0212308.1 | May 2002 | GB | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/GB03/02309 | 5/28/2003 | WO |
