This documents contains a high level description of the platform security model implemented in Symbian OS v9.x and beyond.
A platform security model was introduced in Symbian OS v9. Developers can read this paper to get a high level view of the model and what it means for how they implement programs.
Some brief background information about security and mobile phones is provided in section 2. The document does not describe what infrastructure is needed to support the security model in the operating system, such as application signing programs, security incident processes, etc.
Symbian platform security covers the philosophy, architecture and implementation of the platform defence mechanisms against malicious or badly implemented code. The scope of platform security requires a holistic perspective of some complex system services and their interactions. This paper focuses on the architectural elements required to support the platform defence mechanisms. Specifically, we examine a number of architectural countermeasures that collectively constitute the Symbian Platform Security Architecture . We also look at the substantial number of issues that the adoption of such platform security architecture poses.
2.1 Symbian Security Policy Requirements
A security policy allows you to determine effective countermeasures to threats in three ways: protection, detection and reaction. These three aspects need to be enforced by different mechanisms that are outlined in the following subsections.
There is a need to prevent badly written applications from doing things they are not intended to do on the platform. This involves first of all determining whether the application is sufficiently trustworthy to be installed and then subsequently protecting the platform from errant behaviour once it is installed. In terms of determining trust, third party applications are categorised according to the degree of trust associated with their authors. The binding between trust and authorship is encapsulated within digital certificates issued by a Certificate Authority (CA). The CA performs a role within a PKI which is the organisational infrastructure used to establish and mediate the trust relationships. Individual third party applications are furthermore granted differing degrees of capability at install time within the context of the platform environment on the basis of the perceived degree of trust bestowed upon them by the PKI.
As said in [4], mandatory security mechanisms may be used both to limit trusted applications to the minimal set of privileges required for their function and to confine the damage caused by any misuse of their privileges . For this reason it is important to understand that the security architecture must be also applied to Symbian and licensees code even on a closed environment where new code cannot be installed. As for the MMU (Memory Management Unit) it will bring us several benefits like decreasing the impact of a flaw, enforcing good design and reducing dependencies between components.
The detection of errant application behaviour on the platform includes ensuring that incidents are logged and reported promptly. This means continuous monitoring of relevant incident tracking sources and first level categorisation of security breaches as being minor, significant or major. It may also include support of intrusion detection systems on the platform such as virus scanners. Detection also covers tracking the security flaws in standards we implement as well as security flaws in the platform security architecture. Finally it involves the detection of compromises in the public key infrastructure supporting application signing programs.
There is a need to respond to incidents promptly and effectively. The consequence of having no coherent response to major incidents may be a catastrophic loss of confidence in the security of the Symbian platform among our customers and users. Even if the full response mechanism is out of the scope of the Symbian platform, the security architecture should provide support to implement part of it as capability revocation and upgrade mechanisms.
The main security threat Symbian addresses with this platform security architecture is to prevent viral distribution of malicious applications; for this reason hardware attacks are not specifically addressed.
The architecture focuses in delivering prevention mechanisms. Detections and reactions rely heavily on services provided by an infrastructure external to the phone and its operating system and are not addressed in this document. The basic outline of the security architecture is analogue to a medieval castle defences. In a similar fashion it employs simple and staggered layers of security above and beyond the software installer perimeter. The key threats that the model is trying to address are those that are linked with unauthorised access to user data and to system services in particular the phone stack. The phone stack is especially important in the context of a phone because it will be controlling a permanent data connection to the Internet. There are two key design drivers lying behind the model:
Firewall protection of key system servers through the use of capability-based access control . The capability model is deliberately limited to a small number of capabilities.
Data caging which creates a protected part of the file system which rogue apps are not able to access.
There is a certain minimum amount of architectural work that had to be done to put the security architecture in place. However, there was also a requirement to minimise the impact of any scheme to the architecture of the Symbian platform. Adding platform security with minimal impact was hard to do but this desire had influenced a lot of the architectural ideas.
On the plus side, the security architecture has some distinct advantages over other approaches. It offers us the chance to get a competitive advantage by putting in place the right security architecture for a phone platform. This in turn would mean that our licensees would see the Symbian platform as a more attractive option than the competition partly because the premiums they would have to pay for device security insurance would be lower. In addition, they will have increased trust that deployment of the Symbian platform in their products will not ruin their reputation and brand.
All these points should be borne in mind as we move on to detail the architectural aspects of the model in the next section.
It is inherently difficult to work out how to partition a holistic architecture such as that required to support platform wide security. The approach we have taken here is to present a series of different views on the architectural countermeasures from various perspectives each of which highlight a particular functional element within the system. The security architecture is a combination of these elements.
The main concept of all the security countermeasures described below is to control what a process can do rather than what a user can do. This approach is quite different to well-known operating systems as Unix. The main reasons for which we made this choice are:
The very nature of the Symbian platform is to be mono-user.
The Symbian platform provides services through independent server processes. They always run and are not attach to a user session. As long as power is supplied, the Symbian platform is always on even if no user is logged on.
The Symbian platform is aimed to be used in devices used by a large public with no technology knowledge. When installing software, the user may not have the skills to decide what permissions to grant to an application. Furthermore, with always-connected devices, the consequences of a wrong or malevolent decision may impact a domain much larger than the device itself.
To avoid any confusion while reading this document, please pay attention to the following definitions:
An executable is a file containing Symbian executable code. This can be a library (DLL) or a program (EXE).
A program is an executable that once, loaded will trigger the creation of a process.
A library is an executable that is linked to another executable or that processes can dynamically load.
3.1 Trusted Computing Platform
A trusted computing base is a basic architectural requirement for robust platform security. The trusted computing base would consist 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 Symbian platform kernel and F32, on open devices the software installer (SWInstall) 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 “Tcb” system capability not available to other platform code.
There is one other important element of the trusted computing base, namely the hardware. One important recent paper [6] has outlined a hardware design that does not take operating system security into account. 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. Providing such a secure boot loader is explicitly excluded from the scope of this architecture, and it is a requirement on the base port for specific hardware platforms to provide for this.
3.1.2 Trusted Computing Environment
“There are always system components <…> that must be able to read and write at all levels <…>. The practical outcome is that an uncomfortably large part of the operating system (plus utilities, plus windowing system, plus database) often ends up in the trusted computing base” Ross Anderson
Beyond the core, other system components are granted restricted orthogonal system capability and constitute the Trusted Computing Environment, for instance, these include servers providing sockets, telephony, certificate management, database access, and windowing services. Each server just has the capabilities it requires, for instance the windowing server is not granted phone stack access and the communications servers is not granted direct access to keyboard events. These system capabilities are only available to third party code that is appropriately signed. By limiting the number and combination of system capabilities allocated to any single component, a limit is placed on the potential damage that can be caused by any vulnerability or misuse of privileges.
This is a very natural evolution of the client/server system architecture that has been widely utilised in the operating system since its very inception, and aligns well with the strengths of that architecture.
A capability is an access token that corresponds to a permission to undertake a sensitive action or group of actions. The Symbian platform security architecture purpose 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 is required by a client to access certain functionality through the kernel API. All other resources reside in user-side servers accessed via inter-process communication (IPC) (eg. the telephony server). A limited number of basic capabilities are defined to police specific client actions on the servers. For example, possession of the “network services” capability allows a client to place phone calls via the telephony server. It is the responsibility of the server to police client access to the resources that it provides.
The key features of the process capability model are:
It is primarily focused around Symbian platform system servers and client-server IPC interactions between processes.
Capabilities are associated with processes not threads. Threads in the same process share the same address space and memory access permissions. This means that any data being used by one thread can be read and modified by all other threads in the same process. In addition, threads in the same process can write to each other’s stacks and thereby divert one another’s execution path.
When the code is not running, capabilities are stored inside of executables. Capabilities stored in executables are not modifiable, as they would be stored during installation in a location that is only accessible by the Trusted Computing Base. See subsection 3.4 for the details on how this works.
Not all servers would have to handle client capabilities.
The only cryptography involved in this scheme is at the software installation stage where certificates are checked off against the appropriate root certificates, if necessary, before code is granted any requested capabilities. In some scenarios it is possible for third party developers to dispense with the use of certificates altogether, in which case users would be responsible for granting the requisite capabilities. The subsection 3.5 goes into the details of this.
3.2.1 Mapping system permissions – System Capabilities
System permissions are never exposed to the user and are therefore mandatory. Without it, a process cannot perform a protected operation. One of the main goals of this architecture for the Symbian platform is to protect what is really vital for the integrity of the System and to minimise the number of critical operations. For this reason, some Symbian components have been designed to avoid the need to restrict access to some operations without, of course, compromising their integrity.
Tcb Used by the Trusted Computing Base only, it gives access to the location executables are stored and therefore they can change their capabilities. Only the Symbian platform kernel, the file server (including the loader), and the software installer are granted this privilege.
CommDD Grants direct access to all communication device drivers, including phone baseband software.
PowerMgmt Grants the right to kill any process in the system, to switch the machine into standby state, wake it up again or power it down completely.
MultimediaDD Grants direct access to all multimedia device drivers
ReadDeviceData Grants read access to device, network operator, and phone manufacturer confidential settings or data.
WriteDeviceData Grants write access to settings that control the behaviour of the device. Note this is NOT necessarily symmetric with ReadDeviceData, and in practice is required significantly more often than that capability.
Drm Grants access to rights-protected content
TrustedUI Grants the right to create a trusted UI session, and therefore to display dialogs in a secure UI environment.
ProtServ Grants the right to a server to register within the protected name space – to limit scope for malware to spoof sensitive system servers.
DiskAdmin Grants access to disk administration operations that affect more than one file or one directory (or overall filesystem integrity/behaviour, etc).
NetworkControl Grants the right to modify or access network protocol controls, in a way that might affect more than one client application or transport connection / session.
AllFiles Grants read access to entire file system. Grants write access to other processes' private directories.
SwEvent Grants the right to generate software key & pen events and to capture any of them regardless of the foreground status of the application
SurroundingsDD Grants access to device drivers that provide input information about the surroundings of the device.
3.2.2 Mapping real-world permissions – User Capabilities
The process of identified these capabilities was a lengthy and involved one. First we attempted to identify those accesses that require policing and then tried 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. These map fairly broadly onto the main threats which are unauthorised access to the outside world and preserving the confidentiality/integrity of user data. We assert that any permission requirement can be expressed in terms of some combination of those. In a sense, these capabilities represent orthogonal groupings because they police different kinds of access together. The capabilities identified today are as follows:
NetworkServices Grants access to remote services without any restriction on its physical location. Typically, this location is unknown to the phone user. Also such services may incur cost for the phone user. This typically implies routed protocols. Voice calls, SMS, internet services are good examples of such network services. They are supported by GSM, CDMA and all IP transport protocols including Bluetooth profiles over IP.
LocalServices Grants access to remote services in the close vicinity of the phone. The location of the remote service is well-known to the phone user.In most cases, such services will not incur cost for the phone user. This typically implies a non-routed protocol. An application with this capability can normally send or receive information through Serial port, USB, IR and point-to-point Bluetooth profiles. Examples of services are IR beaming with the user's PC, Bluetooth gaming, file transfer.
ReadUserData Grants read access to data belonging to the phone user. This capability supports the confidentiality of user data. Today, Contacts, messages and calendar data are always seen as user confidential data. For other content types such as images or sounds, it may depend on context, and ultimately be up to the application owning the data to define.
WriteUserData Grants write access to user data. This capability supports the management of the integrity of user data. Note that this capability is not necessarily symmetric with ReadUserData. For instance, one may wish to prevent rogue applications from deleting music tracks but may not wish to restrict read access to them.
Location Grants access to the live location of the device. This capability supports the management of user’s privacy regarding the phone location. Location information protected by this capability can include map co-ordinates and street address, but not regional or national scale information.
UserEnvironment Grants access to live confidential information about the user and his/her immediate environment.This capability also protects the user's privacy. Examples are audio, picture and video recording, biometrics (such as blood pressure) recording.
We acknowledge that user-exposed capabilities are relatively coarse-grained but the assertion is that expanding on these levels is undesirable at this time, for reasons previously given. Only these capabilities may be exposed to users during software installation of unsigned code as discussed in section 3.5.
Security policies requiring Tcb and system capabilities are always mandatory. Their strict control ensures the integrity of Symbian Trusted Computing Platform. However the way servers check user-exposed capabilities or interpret them may be fully flexible and even user-discretionary, for example allowing user prompting if a sensitive action fails due to lack of capability.
3.2.3 Assigning capabilities to a process
The association of a run-time capability with a process requires a modification to Symbian executable loader behaviour. The loader must transform the static capability settings associated with individual executables into a run-time capability that the kernel can use to police IPC and user/kernel interface. There are two fundamental rules that govern the way the loader must work. They seem simple in their description but have far-reaching security consequences as they bring to light the trust relationship between DLLs and EXEs.
The capabilities of a process never change. There is no way of adding capabilities to a process, nor of removing capabilities from a process. All DLL code runs at the capability level of the process that loads it.
A process cannot load a DLL with less capability than itself. The need for this constraint follows from the fact that all DLL code runs at the capability level of the loading process and therefore must be at least as trusted at the loading process. DLL capabilities only reflect the level of trust that the loading process can place in them; they don’t actually authorise anything.
What this implies is that it is the EXE that ultimately holds the responsibility for what happens within the process which is created from it. The capabilities allocating to the EXE grant a level of authorisation to the process to perform its roles and responsibilities. As part of its execution, it may use shared library code. It must not be allowed to use library code that is less trusted than it itself is. This is expressed, in terms of capabilities, in rule 2. However, regardless of what library code it uses, the process will never gain authorisation to perform actions beyond those originally entrusted to it: this is rule 1. The consequence of this is, the more capable a process, the more restrictions will be placed on the DLLs it may load; conversely an process with no capability is free to use any shared library on the system, at its own discretion.
3.2.4 Capability Permission lifetime
There are two possible alternatives for interpretation of the presence of a user-exposed capability at capability-aware servers:
Blanket permission : Capability is granted as a one off act. If the capability is not present when the process is created, the request fails. All access requiring system capability will be policed this way. For example, the file server will just fail any clients attempting to access functionality in the event that they don't possess this capability. The capability would persist as long as the application is installed or until revoked. Revocation mechanisms would be introduced in several steps as they may require extra public key infrastructure from licensees and network operators.
Single action permission : Capability is checked upon each sensitive API call to the server. This means that one each access to the sensitive API call, a security notifier is thrown asking the user if they wish to grant that action. The permission only lasts for the duration of the corresponding sensitive action.
The user perception of the kind of permission must not be confused with when a server will check a required capability. For instance, an application may be granted NetworkServices as blanket permission but the telephony server will check NetworkServices capability at each relevant call made by this application. But as the user will not be asked to make a decision (to grant or not to grant NetworkServices for this call), this security check is transparent to the user.
The advantages of this design are:
To maintain the time of check as close as the time of use as possible (to avoid any TOCTOU flaws)
To avoid the server storing capability-related information for a process.
The great majority of Symbian platform servers behave in blanket permission mode. The reason behind this design decision is the majority of Symbian platform servers provide low level services where the intent and the context of an application’s requests are to some degree unknown. Therefore it would be difficult to ask the user a question with enough understandable information to let her make a well-informed decision.
Symbian Platform Security model is essentially based on capability to reduce the need of identifying applications. It allows servers to control access to their APIs without knowing their requesters and therefore avoid the need of maintaining an access control list. However in some circumstances, it is necessary to identify an application uniquely (see data caging below) and even its source i.e. the vendor. To satisfy these needs the two following concepts have been introduced.
Each executable contains a secure identifier. It is guaranteed to be locally unique (i.e. in the phone where it is installed) however there is a subset of restricted SIDs where a global uniqueness can be guaranteed. The restricted SID space will be explicitly reserved for signed applications and each SID from this range will be cross-referenced to Vendor ID to ensure that each individual SID is authorised to use that particular Vendor ID.
The SID can be explicitly specified for a particular executable or the UID can be used instead. However those two identifiers are always different entities in the kernel implementation. It is proposed that SIDs will come from a specified range of UID values, and that Symbian will provide a new mechanism to allocate suitable values.
Executables can contain a vendor identifier that allows unique identification of the source of the executable. It is expected that the VID will be used for genuine cases like restricting a tentative server API from a specific vendor to its applications. While there is a potential danger that this VID would be used for anti-competitive purposes only, we recognise that there are enough real cases where it would be useful, and that it would therefore be better for the platform to deliver a standard framework rather than risking developers to implement their own solutions. To prevent stealth of vendors’ identity, the software installer will reject the installation of executables with VIDs delivered in an unsigned installation package.
3.3.3 Kernel’s & Loader’s role
As for capabilities, the kernel is responsible for holding both the application and vendor identity for each process. When a process is created, these properties are read from the associated program, held in kernel’s memory and are guaranteed not to change during its lifetime. However, unlike capabilities, there is no rules model to be followed regarding shared library. Each process is free to load shared libraries with any value of Secure ID and Vendor ID, regardless of the identifier values in the EXE from which the process was created. For this reason, capabilities are the core of the security architecture; process identifiers are intended for use in tandem with, rather than as a replacement for, capabilities.
3.4.1.1 Location-based concept
Data caging involves separating code from data in the file system such that a simple trusted path is created on the platform.
A new /sys directory hierarchy is created, with all executable code residing in the /sys/bin subdirectory. The central idea is that by “caging” non-TCB processes into their own part of the file system, the /sys directory becomes hidden to them. The kernel and file server would check that a client process had Tcb or AllFiles capability before allowing any access to the /sys sub-tree. In addition, the loader would disallow any attempt to execute code residing elsewhere than /sys/bin .
A new /resource directory is created, which is public, but read-only for non-TCB processes. The purpose is to allow read-only files to be publicly shared without compromising their integrity.
All executable applications have got access to their own restricted area of the file system, which consists of the sub-tree below the secure directory /private/<app_SID> , where SID is a Secure Identifier used to distinguish between the /private sub-directories. Applications can, for example, use their sub-tree to hold various private data files.
Directories not under /sys or /private or /resource are public and can be read from and written to by any program. This allows the use of standard file system hierarchies that may be available on removable media. In essence, data caging involves caging processes by default into their own small part of the file system. This means that there is default protection of per-application and per-server data from other processes. Without data caging, it would become necessary to introduce access control lists into the file system to prevent rogue apps bypassing the capability model and simply reading databases directly from files. In addition, the scheme affords further protection against the threat of malicious replacement of executables in /sys/bin . In that sense, data caging is a simpler and more robust.
| /resource | /sys | /private/ownSID | /private/anyOther | /anyOther | ||||||
| Capabilities | Read | Write | Read | Write | Read | Write | Read | Write | Read | Write |
| None | Yes | No | No | No | Yes | Yes | No | No | Yes | Yes |
| AllFiles | Yes | No | Yes | No | Yes | Yes | Yes | Yes | Yes | Yes |
| TCB | Yes | Yes | No | Yes | Yes | Yes | No | No | Yes | Yes |
| AllFiles+TCB | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Note that data caging is not a huge conceptual leap from the previous version of the Symbian platform. Historically only the kernel had an unrestricted view of the real machine running the Symbian platform. Each Symbian platform process had its own view of the processor’s address space that was independent of all other processes. This was arranged and policed by the kernel and MMU hardware.
For simplicity it has been decided that the filing system is not aware of the meaning of “private user data”. A file cannot be flagged as so. It is the responsibility of each process dealing with user data to manage ReadUserData and WriteUserData capabilities. Furthermore in case of databases, the file itself can contain user private and public data and therefore trying to assign a level of privacy to a file is not obvious.
3.4.1.2 Import directory concept
Many Symbian frameworks support the concept of plug-ins: they allow new code to contribute to existing native frameworks. Application recognisers are a good example of such plug-ins. In order to be identified as valid plug-ins they often provide a resource file that must be read by process users. When the process user is unique, it makes to place this resource file under its private directory. However, following the rules previously stated that should be impossible. To conciliate both points of view without compromising security, the rules described below have been defined:
If an import directory exists immediately under the private path of a process, Software Install is allowed to put files in it from any installation package file.
If there is no import directory immediately under the private path of a process, Software Install rejects the installation of any file not extracted from this process installation package.
A process having an import directory under its private directory accepts that these files might be malevolent and are not part of its own installation package. The correct level of trust that can be given to those files is process dependent.
The creation of an import directory is under the responsibility of the process developer.
3.4.1.3 Sharing files and data
To help share data across processes, current operating system features have been enhanced and new ones have been implemented. File handles and memory chunks can be shared between processes. These methods can be used to get temporary access to a specific file or memory area that is otherwise private. The recipient of the shared handle will only be able to use the file in the mode chosen by the file opener. Also a highly efficient public & subscribe service has been implemented to enable secure asynchronous, fast distribution of data.
Executables installed by the device on removable media will be hashed. This hash as well as the executable’s capability set are securely stored on the device. At load time, the loader verifies the hash before accepting to perform the operation. If the verification fails, the executable will not be loaded. If the executable is unknown (no associated hash), the executable is loaded without any capability and its SID and VID are assigned to unknown.
Although it is out of the scope of Symbian Secure Architecture, some hardware features can increase the level of security of removable media when off the device. For instance, a password-protected card will prevent a desktop rogue application to get or modify information stored on card without the consent of the user.
As a result Symbian Secure Architecture does not guarantee integrity and confidentiality of files stored under ‘/private’ and /resource when off the device. Each program should decide what integrity checks are appropriate and what level of confidentiality they may provide.
3.5 SWInstall – Enhancing perimeter security
The software installer has been changed substantially to support the process capability model and data caging. In addition, SWInstall now conforms to an appropriate Public Key Infrastructure. As different manufacturers and network operators may have different security policy, SWInstall has been redesigned to support a number of different security policies.
A SIS file may contain zero or more signatures, and the set of capabilities that it needs. The software installer verifies each signature and constructs a certificate chain back to a trusted root. A configuration setting controls whether the software installer will check the revocation status of the certificate using OCSP. In addition, it is possible to mark SW Install root certificates as 'mandatory' certificates. If a mandatory certificate exists, then all installable packages must be signed with it, or installation fails. This enables the holder of the associated key to hold a 'veto' over what software may be installed.
Each SW Install root certificate is associated with a set of the capabilities that it is allowed to grant, called ‘meta-capabilities’. The installer calculates the largest set of capabilities that the installable may be granted as the union of the meta-capabilities associated with all successfully validated signatures.
A configuration setting determines which additional capabilities the user is allowed to grant if the set of permitted capabilities is less than the capabilities requested in the SIS file.The installer will never install software with less than its requested set of capabilities: it is either installed with all of them, or it is not installed at all.
3.5.3 Configuring the installer
At product build time, all configuration settings may be freely determined. In the field configuration settings may be altered to a more limited degree. For instance, the device manufacturer may decide or not to let the user the freedom to grant some capabilities at install time. It should be noted that a key feature of the scheme is that install packages don’t necessarily have to be signed in order to be installed and granted capabilities. This is something that OEMs may not want to permit but at least we provide the option should the system integrator (manufacturer or potentially network operator) want to permit such an installation option. This might be an attractive option for developers wishing to avoid the hassle of code signing.
3.5.4 Installation in place or dual phase installation
Symbian installation package files include a SISSignedController element which contains the information needed to install the files, together with a separate hash for each of the installable files. This is signed, and this signature is verified at installation time against one of the root certificates always present on the device. The integrity of the SISSignedController, and, by extension, of the hashes of the files in the archive, is therefore guaranteed by its signature, and Software Install keeps the SISSignedController for each installation on the device. For secure installation of executables provided on removable media, where the executables don’t need to be installed, the SISSignedController part of the installation can be provided on the card by itself, enabling Software Install’s standard authentication and other security measure to proceed as normal.
Symbian is primarily concerned with the integrity of the backup, not with the confidentiality of any data that might be stored within it. Confidentiality of data, both during the transfer to the host computer and also on the host once backed-up, is out of the scope of the Symbian Security Architecture described in this document.
The security architecture needs to consider three different types of files in the context of backup and restore.
Public files are those stored in public directories. They can’t pose any threats to the integrity of the platform, and no special security measures need to be taken from the point of view of Platform Security when they are backed up and restored. They can be backed up using the traditional method of backup, known as passive backup . This requires no extra code on the part of the Symbian platform or on the part of any applications that might create or own public files.
Private files are those belonging to particular applications which store them in the /private/ file hierarchy. The Symbian platform itself can’t know what these files are or what their sensitivity level might be, so the backup and restore policy regarding them is left under the control of each individual owning application. Applications can either specify in their resource files which private directories or files that they want copied via passive backup. Alternatively, they may make use of the active backup facilities provided by the secure platform. This enables those applications that wish to take advantage of them to backup and restore their private files securely, and are discussed in section 3.6.1 below.
Executable binaries are those stored in the /sys/bin/ directory. Were these to be restored from a backup in the same way as a simple restore of public files, this would represent a significant threat to the security of the device as Software Install would be fully bypassed and there would be no way of guaranteeing that executables had not been interfered with while they were stored off the secure device. The solution to this problem, discussed further in section 3.6.2 below, is to use Software Install’s own mechanisms to back up executables and ensure their integrity on restore.
3.6.1 Active Backup and Restore for Private Data
A process that owns private data and wants to use active backup and restore has to be able to provide all of the data that they wish to backup, and has to be able to receive the data for restore. In order to minimise the code and maintenance overheads, a standard set of reference functions will be provided in the OS that externalise from a directory tree and internalise to a directory tree. A process using active backup should use these functions to externalise its data on a stream for backup and signal when it has finished. For restoration it will internalise from a similar stream. The functions provided should be adequate for most data owning processes. Any processes which want more selective access will have to implement their own functions.
3.6.2 Backup and Restore of Executables via Software Install
As described in 3.5.4 each installation package file includes a SISSignedController with all the information needed to install the files in the SIS archive and the integrity of the SISSignedController is guaranteed by its signature. Since the only way to install something in \sys\bin is via Software Install, the stored SISSignedController elements can therefore be used during a backup operation to recreate versions of the SIS files originally used to install every executables present in \sys\bin . During the corresponding restore operation, the SISSignedController can once again be used to verify the integrity of the executable being restored and the validity of its digital signature against one of the root certificates always present on the device.
[1] High Level Requirements for Release 7.0 of the Symbian Platform v0.04, Mark Wilce, Symbian, March 2001.
[2] “Creating a Secure WinCE 3.0 Device”, Maricia Alforque, Microsoft Corp., © October 2000, http://msdn.microsoft.com/library/techart/winsecurity.htm
[3] Mobile Station Application Execution Environment (MExE): Functional Description, Stage 2, 3GPP TS 23.057 v4.0.0, ftp://ftp.3gpp.org/Specs/2000-12/Rel-4/23_series/23057-400.zip
[4] The -Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments, Loscocco et al, National Security Agency, October 1998, http://www.cs.utah.edu/flux/fluke/html/inevitability.htm
[5] http://www.theregister.co.uk/content/4/17821.html
[6] Security Analysis of the Palm Operating System and its Weaknesses Against Malicious Code Threats, Kingpin and Mudge, @Stake, April 2001 formerly at http://www.atstake.com/research/reports/security_analysis_palm_os.pdf but now at www.quands.info/pdf/security_analysis_palm_os.pdf .
| Term | Meaning |
|---|---|
|
API |
Application Programming Interface |
|
CA |
Certificate Authority |
|
DLL |
Dynamic Link Library |
|
executable |
A file containing native code: libraries (DLL) and programs (EXE) |
|
F32 |
The Symbian Platform File Server |
|
IPC |
Inter Process Communication |
|
OEM |
Original Equipment Manufacturer |
|
PKI |
Public Key Infrastructure |
|
SWInstall |
Software Install – provides service of native application installation. |
|
UI |
User Interface |
|
UID |
Unique Identifier. In the Symbian platform this is a 32-bit word which is used to uniquely identify an object or its type. |
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.