--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,789 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B" xml:lang="en"><title>Symbian
+OS v9 Security Architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>This documents contains a high level description of the platform security
+model implemented in Symbian OS v9.x and beyond. </p>
+<section id="GUID-80B8E189-3F47-5684-A6CC-37E30B3A73F5"><title>Contents</title> <ul>
+<li id="GUID-372B5FEC-6E92-5EFA-BD15-4CAF14FEDC7B"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-E103331E-23BE-5829-9C2A-795D98AA4A4A">1 Introduction</xref> </p> </li>
+<li id="GUID-3927F321-92C4-5172-859B-206E75C5CAE2"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-C462ED45-0B3F-5BEA-9AF6-D03F6CD7B373">2 Symbian Platform Security Background</xref> </p> <ul>
+<li id="GUID-FBE958D4-B137-5757-AE21-571197439131"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6B05D4C8-7BBA-5DAF-BEDE-343926A8DC72">2.1 Symbian Security Policy Requirements</xref> </p> <ul>
+<li id="GUID-D9C80AF7-B2A8-59B9-A0A2-8A9CF17B5C47"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-255CAE5E-8342-593E-BCB2-B3257EAB9C13">2.1.1 Prevention</xref> </p> </li>
+<li id="GUID-41874D6C-4EC7-5FF6-A7D8-D2C3F57CFAE5"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-764EA8A8-2768-5B12-8D38-6C031E27F6D3">2.1.2 Detection</xref> </p> </li>
+<li id="GUID-6D68D224-4FAE-5BE5-85AC-C5C0FBBB6511"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-F2B08632-CBBB-5698-B852-5FAFE5A94114">2.1.3 Reaction</xref> </p> </li>
+</ul> </li>
+<li id="GUID-C95D8F9E-7FBB-503E-BDD1-D8D19DAFF04A"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6A22DD08-25C6-58B5-B8DF-B9C94BFBC651">2.2 The Security Architecture</xref> </p> </li>
+</ul> </li>
+<li id="GUID-107B388D-16EF-53AC-A431-7FB6B20EF0C9"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-CEC2A903-E69B-5F0F-B1FB-AF13B368B1EF">3 Security Architectural Countermeasures</xref> </p> <ul>
+<li id="GUID-9A5DE41D-AA37-5BE9-91A7-B7A02C2AE3D7"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-9750B6A9-33E5-5470-A505-52646E7D8648">3.1 Trusted Computing Platform</xref> </p> <ul>
+<li id="GUID-EC4EB7C9-3752-5B84-955D-4F44EF40061A"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-BB6A8038-7230-5EF8-A2E7-2F6DB2A69A6D">3.1.1 Trusted Computing Base</xref> </p> </li>
+<li id="GUID-0173F5DE-0C2E-59C3-B2D1-7E671670293D"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-3469D51F-A7E2-54B8-A5EB-CB2842C1A3F3">3.1.2 Trusted Computing Environment</xref> </p> </li>
+</ul> </li>
+<li id="GUID-C36D4525-F356-5921-A898-0379A33E38E6"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-CA023029-C0F8-5803-8A38-A6161B3E6A6F">3.2 Process Capabilities</xref> </p> <ul>
+<li id="GUID-4E80D166-0ACA-5210-B626-AF226B22854C"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-1EC03F83-6724-552C-BC95-2DB13C7E632B">3.2.1 Mapping system permissions – System Capabilities</xref> </p> </li>
+<li id="GUID-9EACD773-1344-5EBA-917A-A0FC0EC2B080"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-E10EF8B9-7AC8-521D-B195-6BB7E88BED02">3.2.2 Mapping real-world permissions – User Capabilities</xref> </p> </li>
+<li id="GUID-30F298F8-BE1F-59BF-95F0-27AAD7049B53"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-861A61E2-A364-51B3-B53D-BA8D08874AE4">3.2.3 Assigning capabilities to a process</xref> </p> </li>
+<li id="GUID-63079CA3-44F2-5E4A-8E20-2399A3E7CA92"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-3ED27AA2-9198-59B7-B776-BC43F5FA3119">3.2.4 Capability Permission lifetime</xref> </p> </li>
+</ul> </li>
+<li id="GUID-117A47DF-B8E2-5E52-AFEC-649252629CDF"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-F90646D0-321E-5552-9942-BF7A985C46A1">3.3 Process Identification</xref> </p> <ul>
+<li id="GUID-337A27E6-32FE-5C3F-8BF2-A2C4721C8760"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-07FAE266-EB4B-5462-A2A7-6962D4CCED24">3.3.1 Secure Identifier (SID)</xref> </p> </li>
+<li id="GUID-58910FB5-BC54-5FB3-954C-EC705F6F933B"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-088EA3F8-5209-56F4-9B24-90BF819D10E3">3.3.2 Vendor Identifier (VID)</xref> </p> </li>
+<li id="GUID-EC4FC13D-AB17-5C6E-8EC6-4817BE64EE09"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-0F55AE1B-0407-5CD8-A678-D0AE39D81406">3.3.3 Kernel’s & Loader’s role</xref> </p> </li>
+</ul> </li>
+<li id="GUID-69F5BEFF-9A5C-5507-BC37-310DB1D31593"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-03558B99-2B98-579C-AD59-CF66BD98F69F">3.4 Data Caging</xref> </p> <ul>
+<li id="GUID-5FA43EF4-5CAD-5D5E-8D28-232348E1E640"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-394AF3B0-FA51-5C99-8FBD-73A707AB177C">3.4.1 Caging processes</xref> </p> </li>
+<li id="GUID-48CB6C12-511F-5878-BE25-A8CD5B2DEADC"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-93AD2587-56D2-5553-84D4-C98FC6BA951C">3.4.2 Removable media</xref> </p> </li>
+</ul> </li>
+<li id="GUID-079E308D-3FBA-5B3A-B635-9592B6C91225"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6478908A-06BB-5FF6-BBFA-4ECE3B815A8A">3.5 SWInstall – Enhancing perimeter security</xref> </p> <ul>
+<li id="GUID-18EEAB03-A6E8-59F4-A585-C35532949458"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6F7D320F-97C3-5792-9D48-B960489A0A2B">3.5.1 Software validation</xref> </p> </li>
+<li id="GUID-6766B8B5-2C1E-5ED0-8D6E-0B1CE3972268"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-5C6114AC-F485-5720-BB97-9AEAA8F04E75">3.5.2 Capability calculation</xref> </p> </li>
+<li id="GUID-E60A7D50-5287-5E6F-B572-3BE69F2DDA63"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-FAD0881C-EF83-5B0A-BD9E-B18AC6529A4F">3.5.3 Configuring the installer</xref> </p> </li>
+<li id="GUID-077943D6-65F9-5047-A684-F579C4FB7E5A"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-F63BC928-31A0-5FD1-B846-48B678F06BFE">3.5.4 Installation in place or dual phase installation</xref> </p> </li>
+</ul> </li>
+<li id="GUID-75C6CD9B-AB63-509B-84D3-9AAFB37DD3AC"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-9527DAD1-61F3-56FA-AA64-0E58FB187495">3.6 Secure backup and restore</xref> </p> <ul>
+<li id="GUID-7A4BABCD-E7DF-54AA-B2D4-25BA58FAAE2E"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6BADA2AA-519B-5A79-A2FA-EC9B6648BD1F">3.6.1 Active Backup and Restore for Private Data</xref> </p> </li>
+<li id="GUID-0B9BD3E2-CF85-541F-9E11-47AE71F0C4D9"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-D122D4DC-0D32-5252-9B67-B3D66F3737D8">3.6.2 Backup and Restore of Executables via Software Install</xref> </p> </li>
+</ul> </li>
+</ul> </li>
+<li id="GUID-BC48319D-4B20-5FEF-B5BF-96F5C5EB5AEB"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-830F2821-5614-5083-868C-0D6CEF6D4B0D">4 Additional information</xref> </p> <ul>
+<li id="GUID-359012B4-E556-5AB1-85BB-897CE023C66C"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-CAC87EF9-34AB-5B4B-BF5C-35D96730C12E">4.1 References</xref> </p> </li>
+<li id="GUID-DD6CEA74-A6B9-59DC-A4A3-E96F04EF8C3D"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6A8792B7-03AD-505D-892A-1D08ED4C81AB">4.2 Glossary</xref> </p> </li>
+</ul> </li>
+</ul> </section>
+<section id="GUID-E103331E-23BE-5829-9C2A-795D98AA4A4A"><title>1 Introduction</title> <p>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. </p> <p>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. </p> </section>
+<section id="GUID-C462ED45-0B3F-5BEA-9AF6-D03F6CD7B373"><title>2 Symbian Platform
+Security Background</title> <p>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 <b>Symbian Platform Security Architecture</b>.
+We also look at the substantial number of issues that the adoption of such
+platform security architecture poses. </p> <p id="GUID-6B05D4C8-7BBA-5DAF-BEDE-343926A8DC72"><b>2.1
+Symbian Security Policy Requirements</b> </p> <p>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. </p> <p id="GUID-255CAE5E-8342-593E-BCB2-B3257EAB9C13"><b>2.1.1
+Prevention</b> </p> <p>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. </p> <p>As said in [4], <i>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</i>. 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. </p> <p id="GUID-764EA8A8-2768-5B12-8D38-6C031E27F6D3"><b>2.1.2
+Detection</b> </p> <p>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. </p> <p id="GUID-F2B08632-CBBB-5698-B852-5FAFE5A94114"><b>2.1.3 Reaction</b> </p> <p>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. </p> <p id="GUID-6A22DD08-25C6-58B5-B8DF-B9C94BFBC651"><b>2.2
+The Security Architecture</b> </p> <p>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. </p> <p>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: </p> <ul>
+<li id="GUID-DCA4E741-016D-5B4F-A1FF-9D3E4B1A7D41"><p> <b>Firewall protection</b> of
+key system servers through the use of <b>capability-based access control</b>.
+The capability model is deliberately limited to a small number of capabilities. </p> </li>
+<li id="GUID-6A5211F8-DAA6-54BB-B091-9B74DD352D64"><p> <b>Data caging </b> which
+creates a protected part of the file system which rogue apps are not able
+to access. </p> </li>
+</ul> <p>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. </p> <p>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. </p> <p>All these
+points should be borne in mind as we move on to detail the architectural aspects
+of the model in the next section. </p> </section>
+<section id="GUID-CEC2A903-E69B-5F0F-B1FB-AF13B368B1EF"><title>3 Security
+Architectural Countermeasures</title> <p>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. </p> <p>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: </p> <ul>
+<li id="GUID-F2DB9FD3-4D02-50BD-93E5-97D575BC4A20"><p>The very nature of the
+Symbian platform is to be mono-user. </p> </li>
+<li id="GUID-74DA1B3D-737D-5B90-93B6-89CB4CD56876"><p>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. </p> </li>
+<li id="GUID-893338DD-7249-5DB8-97A8-BBA773048CFC"><p>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. </p> </li>
+</ul> <p>To avoid any confusion while reading this document, please pay attention
+to the following definitions: </p> <ul>
+<li id="GUID-A3CF9AE1-1550-5CF1-9F59-7C1818C0ABB5"><p>An <b>executable</b> is
+a file containing Symbian executable code. This can be a library (DLL) or
+a program (EXE). </p> </li>
+<li id="GUID-91387A05-431F-514D-905A-AA7DC5AEDB4F"><p>A <b>program</b> is
+an executable that once, loaded will trigger the creation of a <b>process.</b> </p> </li>
+<li id="GUID-C1949968-5B03-56A6-BEE1-D37AF8C43B70"><p>A <b>library</b> is
+an executable that is linked to another executable or that processes can dynamically
+load. </p> </li>
+</ul> <p id="GUID-9750B6A9-33E5-5470-A505-52646E7D8648"><b>3.1 Trusted Computing
+Platform</b> </p> <p id="GUID-BB6A8038-7230-5EF8-A2E7-2F6DB2A69A6D"><b>3.1.1
+Trusted Computing Base</b> </p> <p>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. </p> <p>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. </p> <p id="GUID-3469D51F-A7E2-54B8-A5EB-CB2842C1A3F3"><b>3.1.2
+Trusted Computing Environment</b> </p> <p> <i>“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</i> </p> <p>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. </p> <p>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. </p> <p id="GUID-CA023029-C0F8-5803-8A38-A6161B3E6A6F"><b>3.2
+Process Capabilities</b> </p> <p>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 <i>system</i> 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. </p> <p>The key features
+of the process capability model are: </p> <ul>
+<li id="GUID-B3DA2817-97C8-55A7-8462-C1498772EFC2"><p>It is primarily focused
+around Symbian platform system servers and client-server IPC interactions
+between processes. </p> </li>
+<li id="GUID-2A22A61B-BAAD-5CA7-974B-7D6FCFD11BF0"><p>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. </p> </li>
+<li id="GUID-257E42BE-1E6F-5863-BE26-8EF23C4C642B"><p>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. </p> </li>
+<li id="GUID-CDAF1309-850A-5130-856D-62535F086776"><p>Not all servers would
+have to handle client capabilities. </p> </li>
+<li id="GUID-54441D51-F433-55DC-B4E8-F3BE32BE56C8"><p>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. </p> </li>
+</ul> <p id="GUID-1EC03F83-6724-552C-BC95-2DB13C7E632B"><b>3.2.1 Mapping system
+permissions – System Capabilities</b> </p> <p> <i>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.</i> </p> <p> <b> Tcb </b> 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. </p> <p> <b> CommDD </b> Grants direct
+access to all communication device drivers, including phone baseband software. </p> <p> <b> PowerMgmt </b> 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. </p> <p> <b> MultimediaDD </b> Grants
+direct access to all multimedia device drivers </p> <p> <b> ReadDeviceData </b> Grants
+read access to device, network operator, and phone manufacturer confidential
+settings or data. </p> <p> <b> WriteDeviceData </b> 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. </p> <p> <b> Drm </b> Grants access to rights-protected
+content </p> <p> <b> TrustedUI </b> Grants the right to create a trusted UI
+session, and therefore to display dialogs in a secure UI environment. </p> <p> <b> ProtServ </b> Grants
+the right to a server to register within the protected name space – to limit
+scope for malware to spoof sensitive system servers. </p> <p> <b> DiskAdmin </b> Grants
+access to disk administration operations that affect more than one file or
+one directory (or overall filesystem integrity/behaviour, etc). </p> <p> <b> NetworkControl </b> 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. </p> <p> <b> AllFiles </b> Grants
+read access to entire file system. Grants write access to other processes'
+private directories. </p> <p> <b> SwEvent </b> Grants the right to generate
+software key & pen events and to capture any of them regardless of the
+foreground status of the application </p> <p> <b> SurroundingsDD </b> Grants
+access to device drivers that provide input information about the surroundings
+of the device. </p> <p id="GUID-E10EF8B9-7AC8-521D-B195-6BB7E88BED02"><b>3.2.2
+Mapping real-world permissions – User Capabilities</b> </p> <p>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: </p> <p> <b> NetworkServices </b> <b> </b> 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. </p> <p> <b> LocalServices </b> <b> </b> 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. </p> <p> <b> ReadUserData </b> Grants read access to data belonging
+to the phone user. This capability supports the <i>confidentiality </i> of<i> </i> 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. </p> <p> <b> WriteUserData </b> Grants write access to user data.
+This capability supports the management of the <i>integrity </i> 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. </p> <p> <b> Location </b> 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. </p> <p> <b> UserEnvironment </b> 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. </p> <p>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. </p> <p>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. </p> <p id="GUID-861A61E2-A364-51B3-B53D-BA8D08874AE4"><b>3.2.3
+Assigning capabilities to a process</b> </p> <p>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. </p> <ol id="GUID-8770138F-B858-570C-98F0-8CAF365AA656">
+<li id="GUID-D41EEC0F-FFBC-57BA-91C7-72312512AC6A"><p> <b> The capabilities
+of a process never change.</b> 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. </p> </li>
+<li id="GUID-732F0118-3C18-50A0-9D57-A7136F39B0CE"><p> <b> A process cannot
+load a DLL with less capability than itself.</b> 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. </p> </li>
+</ol> <p>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. </p> <p id="GUID-3ED27AA2-9198-59B7-B776-BC43F5FA3119"><b>3.2.4
+Capability Permission lifetime</b> </p> <p>There are two possible alternatives
+for interpretation of the presence of a user-exposed capability at capability-aware
+servers: </p> <p> <b>Blanket permission</b>: 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. </p> <ul>
+<li id="GUID-A56156C5-3B8C-5566-8F74-BAC190C849C9"><p> <b>Single action permission</b>:
+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. </p> </li>
+</ul> <p>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. </p> <p>The advantages of this design are: </p> <ul>
+<li id="GUID-76BB16EB-7469-515F-9F30-040AE2A91950"><p>To maintain the time
+of check as close as the time of use as possible (to avoid any TOCTOU flaws) </p> </li>
+<li id="GUID-567F2967-2988-5652-B4A2-9A9B8C2ED6B5"><p>To avoid the server
+storing capability-related information for a process. </p> </li>
+</ul> <p>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. </p> <p id="GUID-F90646D0-321E-5552-9942-BF7A985C46A1"><b>3.3
+Process Identification</b> </p> <p>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. </p> <p id="GUID-07FAE266-EB4B-5462-A2A7-6962D4CCED24"><b>3.3.1
+Secure Identifier (SID)</b> </p> <p>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. </p> <p>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. </p> <p id="GUID-088EA3F8-5209-56F4-9B24-90BF819D10E3"><b>3.3.2
+Vendor Identifier (VID)</b> </p> <p>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. </p> <p id="GUID-0F55AE1B-0407-5CD8-A678-D0AE39D81406"><b>3.3.3 Kernel’s & Loader’s
+role</b> </p> <p>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. </p> <p id="GUID-03558B99-2B98-579C-AD59-CF66BD98F69F"><b>3.4
+Data Caging </b> </p> <p id="GUID-394AF3B0-FA51-5C99-8FBD-73A707AB177C"><b>3.4.1
+Caging processes </b> </p> <p id="GUID-9C9307AE-4B3C-5CE8-B66C-FE3E40A2C1C4"><b>3.4.1.1
+Location-based concept</b> </p> <p>Data caging involves separating code from
+data in the file system such that a simple trusted path is created on the
+platform. </p> <ul>
+<li id="GUID-C7AB7740-5EEA-5513-8FEC-6F96C7E52AB2"><p>A new <codeph>/sys</codeph> directory
+hierarchy is created, with all executable code residing in the <codeph>/sys/bin</codeph> subdirectory.
+The central idea is that by “caging” non-TCB processes into their own part
+of the file system, the <codeph>/sys </codeph> 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 <codeph>/sys</codeph> sub-tree.
+In addition, the loader would disallow any attempt to execute code residing
+elsewhere than <codeph>/sys/bin</codeph>. </p> </li>
+<li id="GUID-D710C501-9913-565A-9BD1-FCE531AA7BC5"><p>A new <codeph>/resource</codeph> 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. </p> </li>
+<li id="GUID-4C6FB170-58EF-580B-B787-3E27DA422CAF"><p>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 <codeph>/private/<app_SID></codeph>,
+where SID is a Secure Identifier used to distinguish between the <codeph>/private</codeph> sub-directories.
+Applications can, for example, use their sub-tree to hold various private
+data files. </p> </li>
+</ul> <p>Directories not under <codeph>/sys</codeph> or <codeph>/private</codeph> or <codeph>/resource</codeph> 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 <codeph>/sys/bin</codeph>.
+In that sense, data caging is a simpler and more robust. </p><table id="GUID-1F570514-0235-4164-9EE4-93C2748768F0"><title>Data
+caging – capabilities for data caging</title>
+<tgroup cols="11"><colspec colname="col1"/><colspec colname="col2"/><colspec colname="col3"/><colspec colname="col4"/><colspec colname="col5"/><colspec colname="col6"/><colspec colname="col7"/><colspec colname="col8"/><colspec colname="col9"/><colspec colname="col10"/><colspec colname="col11"/>
+<tbody>
+<row>
+<entry/>
+<entry nameend="col3" namest="col2"><filepath>/resource</filepath></entry>
+<entry nameend="col5" namest="col4"><filepath>/sys</filepath></entry>
+<entry nameend="col7" namest="col6"><filepath>/private/ownSID</filepath></entry>
+<entry nameend="col9" namest="col8"><filepath>/private/anyOther</filepath></entry>
+<entry nameend="col11" namest="col10"><filepath>/anyOther</filepath></entry>
+</row>
+<row>
+<entry>Capabilities </entry>
+<entry>Read</entry>
+<entry>Write</entry>
+<entry>Read</entry>
+<entry>Write</entry>
+<entry>Read</entry>
+<entry>Write</entry>
+<entry>Read</entry>
+<entry>Write</entry>
+<entry>Read</entry>
+<entry>Write</entry>
+</row>
+<row>
+<entry>None</entry>
+<entry>Yes</entry>
+<entry>No</entry>
+<entry>No</entry>
+<entry>No</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>No</entry>
+<entry>No</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+</row>
+<row>
+<entry>AllFiles</entry>
+<entry>Yes</entry>
+<entry>No</entry>
+<entry>Yes</entry>
+<entry>No</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+</row>
+<row>
+<entry>TCB</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>No</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>No</entry>
+<entry>No</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+</row>
+<row>
+<entry>AllFiles+TCB</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+<entry>Yes</entry>
+</row>
+</tbody>
+</tgroup>
+</table> <p>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. </p> <p>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. </p> <p id="GUID-89E1EC84-A373-53AF-A586-D5FF635B0B62"><b>3.4.1.2
+Import directory concept</b> </p> <p>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: </p> <ul>
+<li id="GUID-B457A88B-AABA-5F44-B054-A9C2873D3693"><p>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. </p> </li>
+<li id="GUID-9A510686-D67A-5B1C-8FC7-F47FE9D64D38"><p>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. </p> </li>
+<li id="GUID-3E197C12-3108-50CF-95EA-28E70C95F51A"><p>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. </p> </li>
+<li id="GUID-2DAF2C55-178F-573F-860E-CFD7C6149A1A"><p>The creation of an import
+directory is under the responsibility of the process developer. </p> </li>
+</ul> <p id="GUID-C79F6795-744F-5ED0-8F3F-5720FF1BE229"><b>3.4.1.3 Sharing
+files and data</b> </p> <p>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. </p> <p id="GUID-93AD2587-56D2-5553-84D4-C98FC6BA951C"><b>3.4.2
+Removable media</b> </p> <p>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. </p> <p>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. </p> <p>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. </p> <p id="GUID-6478908A-06BB-5FF6-BBFA-4ECE3B815A8A"><b>3.5
+SWInstall – Enhancing perimeter security</b> </p> <p>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. </p> <p id="GUID-6F7D320F-97C3-5792-9D48-B960489A0A2B"><b>3.5.1
+Software validation</b> </p> <p>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. </p> <p id="GUID-5C6114AC-F485-5720-BB97-9AEAA8F04E75"><b>3.5.2
+Capability calculation</b> </p> <p>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. </p> <p>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. </p> <p id="GUID-FAD0881C-EF83-5B0A-BD9E-B18AC6529A4F"><b>3.5.3 Configuring the installer</b> </p> <p>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. </p> <p id="GUID-F63BC928-31A0-5FD1-B846-48B678F06BFE"><b>3.5.4
+Installation in place or dual phase installation</b> </p> <p>Symbian installation
+package files include a <i>SISSignedController</i> 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. </p> <p id="GUID-9527DAD1-61F3-56FA-AA64-0E58FB187495"><b>3.6 Secure
+backup and restore </b> </p> <p>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. </p> <p>The security architecture
+needs to consider three different types of files in the context of backup
+and restore. </p> <ol id="GUID-EB24EA75-D1CC-5792-8EEB-0F12AA327006">
+<li id="GUID-DC0AAA67-0969-5AA0-8DCF-0822DD6FF33E"><p> <i>Public files</i> 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 <i>passive
+backup</i>. 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. </p> </li>
+<li id="GUID-DC14C663-D4A9-58EA-B0A6-0E14CFB732F9"><p> <i>Private files</i> are
+those belonging to particular applications which store them in the <codeph>/private/</codeph> 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 <i>active backup</i> 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. </p> </li>
+<li id="GUID-6B7B6670-9F95-5DA1-8945-BF79052A3509"><p> <i>Executable binaries</i> are
+those stored in the <codeph>/sys/bin/</codeph> 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. </p> </li>
+</ol> <p id="GUID-6BADA2AA-519B-5A79-A2FA-EC9B6648BD1F"><b>3.6.1 Active Backup
+and Restore for Private Data</b> </p> <p>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. </p> <p id="GUID-D122D4DC-0D32-5252-9B67-B3D66F3737D8"><b>3.6.2
+Backup and Restore of Executables via Software Install</b> </p> <p>As described
+in <xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-F63BC928-31A0-5FD1-B846-48B678F06BFE">3.5.4</xref> each
+installation package file includes a <i>SISSignedController</i> 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 <codeph>\sys\bin</codeph> 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 <codeph>\sys\bin</codeph>. 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. </p> </section>
+<section id="GUID-830F2821-5614-5083-868C-0D6CEF6D4B0D"><title>4 Additional
+information</title> <p id="GUID-CAC87EF9-34AB-5B4B-BF5C-35D96730C12E"><b>4.1
+References</b> </p> <p>[1] High Level Requirements for Release 7.0 of the
+Symbian Platform v0.04, Mark Wilce, Symbian, March 2001. </p> <p>[2] “Creating
+a Secure WinCE 3.0 Device”, Maricia Alforque, Microsoft Corp., © October 2000, <xref href="http://msdn.microsoft.com/library/techart/winsecurity.htm" scope="external">http://msdn.microsoft.com/library/techart/winsecurity.htm</xref> </p> <p>[3] Mobile Station Application Execution Environment (MExE): Functional
+Description, Stage 2, 3GPP TS 23.057 v4.0.0, <xref href="ftp://ftp.3gpp.org/Specs/2000-12/Rel-4/23_series/23057-400.zip" scope="external">ftp://ftp.3gpp.org/Specs/2000-12/Rel-4/23_series/23057-400.zip</xref> </p> <p>[4]
+The -Inevitability of Failure: The Flawed Assumption of Security in Modern
+Computing Environments, Loscocco et al, National Security Agency, October
+1998, <xref href="http://www.cs.utah.edu/flux/fluke/html/inevitability.htm" scope="external">http://www.cs.utah.edu/flux/fluke/html/inevitability.htm</xref> </p> <p>[5] <xref href="http://www.theregister.co.uk/content/4/17821.html" scope="external">http://www.theregister.co.uk/content/4/17821.html</xref> </p> <p>[6]
+Security Analysis of the Palm Operating System and its Weaknesses Against
+Malicious Code Threats, Kingpin and Mudge, @Stake, April 2001 formerly at <xref href="http://www.atstake.com/research/reports/security_analysis_palm_os.pdf" scope="external">http://www.atstake.com/research/reports/security_analysis_palm_os.pdf</xref> but
+now at <xref href="http://www.quands.info/pdf/security_analysis_palm_os.pdf" scope="external">www.quands.info/pdf/security_analysis_palm_os.pdf</xref>. </p> <p id="GUID-6A8792B7-03AD-505D-892A-1D08ED4C81AB"><b>4.2 Glossary</b> </p> <table id="GUID-60365022-B96D-50EA-BA49-94AB5AD85CD5">
+<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
+<thead>
+<row>
+<entry>Term</entry>
+<entry>Meaning</entry>
+</row>
+</thead>
+<tbody>
+<row>
+<entry><p>API </p> </entry>
+<entry><p>Application Programming Interface </p> </entry>
+</row>
+<row>
+<entry><p>CA </p> </entry>
+<entry><p>Certificate Authority </p> </entry>
+</row>
+<row>
+<entry><p>DLL </p> </entry>
+<entry><p>Dynamic Link Library </p> </entry>
+</row>
+<row>
+<entry><p>executable </p> </entry>
+<entry><p>A file containing native code: libraries (DLL) and programs (EXE) </p> </entry>
+</row>
+<row>
+<entry><p>F32 </p> </entry>
+<entry><p>The Symbian Platform File Server </p> </entry>
+</row>
+<row>
+<entry><p>IPC </p> </entry>
+<entry><p>Inter Process Communication </p> </entry>
+</row>
+<row>
+<entry><p>OEM </p> </entry>
+<entry><p>Original Equipment Manufacturer </p> </entry>
+</row>
+<row>
+<entry><p>PKI </p> </entry>
+<entry><p>Public Key Infrastructure </p> </entry>
+</row>
+<row>
+<entry><p>SWInstall </p> </entry>
+<entry><p>Software Install – provides service of native application installation. </p> </entry>
+</row>
+<row>
+<entry><p>UI </p> </entry>
+<entry><p>User Interface </p> </entry>
+</row>
+<row>
+<entry><p>UID </p> </entry>
+<entry><p>Unique Identifier. In the Symbian platform this is a 32-bit word
+which is used to uniquely identify an object or its type. </p> </entry>
+</row>
+</tbody>
+</tgroup>
+</table> </section>
+</conbody></concept>
\ No newline at end of file