3

Platform security for all

1st Edition, 06/08

Published by:
Symbian Software Limited
2-6 Boundary Row
Southwark
London SE1 8HP
UK
www.symbian.com

Trademarks, copyright, disclaimer

‘Symbian’, ‘Symbian OS’ and other associated Symbian marks are all
trademarks of Symbian Software Ltd. Symbian acknowledges the trademark
rights of all third parties referred to in this material. © Copyright Symbian
Software Ltd 2008. All rights reserved. No part of this material may be
reproduced without the express written permission of Symbian Software Ltd.
Symbian Software Ltd makes no warranty or guarantee about the suitability
or the accuracy of the information contained in this document. The information
contained in this document is for general information purposes only and
should not be used or relied upon for any other purpose whatsoever.

Compiled by:
Joe Odukoya
Elise Korolev

Managing Editor:
Ashlee Godwin

Design Consultant:
Sabeena Aslam

Reviewed by:
Matthew Allen
Roderick Burns
Bruce Carney
Ashlee Godwin
Craig Heath
Jo Stichbury
 4

Contents
OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

SECTION I: PLATFORM SECURITY EXPLAINED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

THE NEED FOR SECURITY ON MOBILE PHONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

SECURITY ON SYMBIAN OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

GETTING APPLICATIONS ONTO THE PHONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

KEEPING ‘PRIVATE’ INFORMATION PRIVATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

THE BENEFITS OF A GOOD SECURITY SYSTEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

SECTION II: DEVELOPER Q&AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

WHY SHOULD I WORRY ABOUT SECURITY? HOW DOES IT AFFECT ME? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

TO USE SYMBIAN SIGNED OR NOT TO USE SYMBIAN SIGNED? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

HOW DO I WORK ON A SECURE PLATFORM? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

INSTALLING YOUR APPLICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SECTION III: FURTHER MATERIAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

BOOKS FROM SYMBIAN PRESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

PLATFORM SECURITY RESOURCES FOR DEVELOPERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

SYMBIAN SIGNED RESOURCES FOR DEVELOPERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

REGIONAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
 5

Overview
This booklet provides a brief introduction to platform security on Symbian OS. While it will
give you a basic foundation, those wishing to understand the concepts in greater depth are
strongly encouraged to read the Symbian Press book Symbian OS Platform Security by Craig
Heath et al. (see developer.symbian.com/platform_security_book for more information) from
which most of the material in this booklet has been extracted.

If you want to know more about the options for signing applications there is a separate
manual, called A guide to Symbian Signed, available from developer.symbian.com/ssguide.

Introduction
Symbian OS is the market-leading operating system for advanced mobile phones. More than
200 million Symbian OS-based mobile phones have been shipped worldwide, with 222 models
across many different market segments, from mid-range feature phones to highly advanced
smartphones. In 2007, 77 million phones based on Symbian OS were sold, representing a
seven percent share of the entire global mobile phone market.

Symbian’s customers include the world’s leading mobile phone manufacturers. Symbian also
maintains close collaboration with network operators, semiconductor partners, and middleware
providers in order to guarantee a thriving ecosystem around Symbian OS and the devices that
use it. Through these relationships, Symbian is positioned to deliver the world’s most-used
mobile software platform for smartphones.

One of the core benefits of Symbian OS is its 'openness;' the ability for applications to be
installed on Symbian OS-based devices in order to deliver new services or to provide a more
personalized experience for the user. Preserving this benefit, while also ensuring that the
mobile phone user is protected from security threats (such as those typically seen with
desktop computers), is the main goal of Symbian’s platform security design.

The large installed base of devices built on Symbian OS and the increasing popularity of these
devices makes them a likely target for viruses and other malware. However, in the two years
since Symbian introduced its security architecture (in Symbian OS v9) there have been no
reported cases of viruses or other malicious code affecting mobile phones based on Symbian
OS v9.x.
 6

Section I: Platform Security Explained

The need for security on mobile phones
The increasing popularity of mobile phones, combined with their inherently personal nature,
make them vulnerable to security threats. In particular, mobile phones based on Symbian OS
have a large number of advanced features such as video recording, multi-megapixel cameras,
and MP3 players. This means that users are more inclined to carry large amounts of personal
data with them, stored on their mobile phone. In addition, Symbian OS-based phones allow
users to download and install applications to extend those already available on the device.
There is a risk that these ‘after-market’ applications could, either deliberately or unintentionally,
compromise the phone, the network the phone is running on, or the user’s personal data.

Without proper security management, applications can perform undesirable actions such as:
• tampering with user’s data, including accessing the user’s private data and forwarding it
• creating billable events, such as sending premium rate text messages or dialling premium
rate phone numbers, without the user’s knowledge or consent
• executing instructions that cause the mobile phone to become unstable.

Symbian’s security architecture has therefore been designed with the following key factors in mind:
• to protect the phone from badly written software
• to protect the phone from potential viruses and other malicious programs
• to protect the user from fraudulent applications which cause billable events (i.e., spending
money on the user’s behalf ) without the user’s knowledge and consent
• to improve trust by signing applications with a tamper-proof digital signature to identify
their origin
• to protect the user’s private data from unauthorized access
• to protect paid-for content from piracy.

Security on Symbian OS
To secure Symbian OS v9.x, Symbian reviewed the APIs offered by the platform and assigned
them into groups according to both their functionality and how critical they are to the overall
functioning of the system. Access to a group of APIs is controlled by an access permission
known as a ‘capability.’ In order to access a particular API group an application needs to have
the right capability assigned to it.

Not all capabilities are available to all code; permissions are granted based on the
trustworthiness of an application.

There are three trust tiers in Symbian OS:

• Trusted Computing Base (TCB).
This contains the most trusted parts of the OS. It is responsible for maintaining the integrity
of the system and it’s also the part that is least restricted (i.e., it has access to the full
range of capabilities available). The Trusted Computing Base consists of the Symbian OS
kernel, the file system, and the software installer (the software installer, and how it
provides a path for applications to enter the trust tiers, is illustrated in Figure 3).
• Trusted Computing Environment (TCE).
This is the next tier of trust. Its code has access to only a subset of capabilities. The
Trusted Computing Environment largely consists of system servers (i.e., processes that
manage and control access to system resources), such as the window server process that
controls access to the screen hardware.
 7

Each server is only given the capabilities it needs in order to perform its function. So, for
example, the window server does not have access to any capabilities that are used for
communications or for the reading and writing of user data. In this way it is not possible
for a misbehaving system server to compromise the security of another server since it does
not have access to the same APIs.
• Application.
Code running outside of the Trusted Computing Environment has access only to those APIs
that are unlikely to pose a security risk. The APIs available in the Application tier are
grouped by capabilities that relate to user-level features or actions, that is, those that a
user can understand. These capabilities are often known as ‘user’ capabilities or
'application' capabilities. Untrusted applications must request permission from the user
before accessing these APIs. For example, creating a network connection potentially costs
the user money and therefore unsigned or self-signed code must gain permission before it
can do so.

Figure 1 illustrates the comparative levels of trust and the corresponding ability of an
application to access critical APIs.

TCB

Increasing level of trust. Decreasing level of trust.

Increasing access to Decreasing access to
critical APIs. TCE critical APIs.

Application

Figure 1: The relationship between trust and the ability of an application to access critical APIs.
 8

The capabilities available in each trust tier are shown in Figure 2 below.

Trusted Computing Base

Full access to all APIs and files
(kernel, installer, file server)

Trusted Computing Environment

Servers with 'System Capabilities'

Most third-party applications need

only 'Application Capabilities,'
(usually grantable by the user)

Figure 2: The capabilities available in each trust tier.

Consider a local multi-player game that communicates over Bluetooth. This would need the
LocalServices capability to make use of a Bluetooth connection. However, it may not need
any other capabilities and therefore the application should not request any other capabilities.
Application developers should ensure that they ask for as few capabilities as possible, as this
helps to ensure that the security of the phone cannot be compromised by accidental errors in
the application itself.

The process of granting capabilities to applications is managed by the signing process which is
covered briefly in the next section.

Some applications do not make use of any capabilities, because they call only APIs that are
deemed ‘safe’ and unlikely to pose a security risk. On most Symbian smartphones, such
applications do not need to be signed by a certification authority. When signing is necessary,
such an application may simply be self-signed by the application developer. Unsigned and
self-signed applications are treated as 'untrusted,' but nevertheless can be installed and run
on the phone because they are prevented from calling any privileged APIs for which
capabilities are required.
 9

Figure 3: The software installer provides a path for applications to enter the trust tiers.

Getting applications onto the phone

As the introduction explained, one of the fundamental benefits of Symbian OS is its
‘openness.’ The ability to add new features and services by installing after-market applications
gives the user great flexibility. Mobile phones can be customized simply by downloading and
installing applications such as games, productivity tools, photo editors, blogging applications, etc.

When a trusted application is installed it is given certain access permissions; the application is
granted access to the set of APIs it needs in order to operate. An untrusted application, once
installed, can also request permission from the user to access certain capabilities. For example,
if the application needs to connect to a remote server it will need to create a data connection,
which could cost the user money. The application can request permission from the user to
create that data connection (i.e., to gain access to the NetworkServices capability).

If, however, the application needs access to more sensitive APIs, or does not want to rely on
the user granting permissions, the application author can request the necessary capabilities via
the signing process. Before an application is signed it has to meet the requirements specified
by the Symbian Signed Test Criteria to ensure that the application is reasonably robust, stable,
and well behaved.
 10

The application developer is required to declare the capabilities (i.e., the groups of APIs) that
the application needs access to. If the application passes the testing process, it is given the
rights to access the requested capabilities.

More detail on the signing process, the testing involved, and the different signing options
available are given in the Symbian booklet A guide to Symbian Signed. However, the five key
points to remember are:

1. An application can still run on a Symbian smartphone and use a large set of APIs even if it
has not been Symbian Signed. The security settings on most Symbian OS phones allow
untrusted applications to be installed.1 A single-player game with only user interface
interaction, for example, could run perfectly well as an untrusted application.

2. An application needs to be Symbian Signed if it falls into one of these categories,

such that it:
• requires access to APIs protected by system capabilities
• wishes to avoid user prompts at installation or runtime
• needs to install even on those Symbian OS phones that are configured to refuse untrusted
applications.

3. Any application that requires access to restricted APIs in the TCE will need to demonstrate a
high degree of stability and robustness.

4. The most critical capabilities are the most protected and often require the approval of the
device manufacturer before access can be granted to an application.

5. Application developers should decide carefully which APIs they need and only request
those; do not request a capability unless it is actually required by the code. This ensures
that the application will not accidentally compromise the security of any device it runs on.

The table on the next page is a guide to correctly choosing capabilities for an application;
there are 20 different capabilities in total:

1
An untrusted application is one that is unsigned or that has been self-signed by the application developer. Such
an application can still request application capabilities, which must then be granted by the user.
 11

-J]SYRIIHXSHSXLMWŸ Ÿ=SY[MPPRIIHXLMWGETEFMPMX] 'EXIKSV]

%GGIWWWIVZMGIWSZIVWLSVXPMROGSRRIGXMSRW %TTPMGEXMSR
WLSVXVERKIGSQQYRMGEXMSRWWYGLEW LocalServices YWYEPP]
&PYIXSSXLSVMRJVEVIH  YWIVKVERXEFPI
%GGIWWHEXEKMZMRKXLIPSGEXMSRSJXLITLSRI Location
%GGIWWVIQSXIWIVZMGIWWYGLEW;M*MSVSZIV
NetworkServices
XLIEMVWIVZMGIW 
6IEHXLIYWIV«WTIVWSREPHEXE ReadUserData

%GGIWWPMZIHEXEEFSYXXLIYWIVERHXLIMV
MQQIHMEXIIRZMVSRQIRXWYGLEWEYHMS UserEnvironment
TMGXYVIERHZMHISVIGSVHMRK 
9THEXIERHSVHIPIXIXLIYWIV«WTIVWSREPHEXE WriteUserData
%GGIWWEPPGSQQYRMGEXMSRWIUYMTQIRXHVMZIVW
CommDD 7]WXIQ
HMVIGXP]
'EVV]SYXKIRIVEPJMPIEHQMRMWXVEXMSRXEWOW DiskAdmin

%GGIWWGVMXMGEPQYPXMQIHMEJYRGXMSRWIK
HMVIGXEGGIWWXSQYPXMQIHMEHIZMGIHVMZIVWERH MultiMediaDD
TVMSVMX]EGGIWWXSQYPXMQIHME%4-W 
1SHMJ]SVEGGIWWRIX[SVOTVSXSGSPGSRXVSPW NetworkControl

/MPPTVSGIWWIWXYVRSJJYRYWIHTIVMTLIVEPW
JSVGIXLITLSRIXSTS[IVSJJ[EOIYTSVKS PowerMgmt
MRXSWXERHF]

6IKMWXIVEWIVZIVTVSGIWW[MXLETVSXIGXIH
ProtServ
REQI
6IEHGSRJMHIRXMEPRIX[SVOSTIVEXSVQSFMPI
ReadDeviceData
TLSRIQERYJEGXYVIVERHHIZMGIWIXXMRKW

%GGIWWPSKMGEPHIZMGIHVMZIVWXLEXTVSZMHI
MRTYXMRJSVQEXMSREFSYXXLIQSFMPITLSRI«W SurroundingsDD
WYVVSYRHMRKW

7MQYPEXIOI]TVIWWIWERHTIRMRTYXERHXS
SwEvent
GETXYVIWYGLIZIRXWJVSQETVSKVEQ
'VIEXIEXVYWXIHYWIVMRXIVJEGIERHHMWTPE]
TrustedUI
HMEPSKWMREWIGYVIYWIVMRXIVJEGIIRZMVSRQIRX
'VIEXIYTHEXIWIXXMRKWXLEXGSRXVSPXLI
WriteDeviceData
FILEZMSVSJXLIHIZMGI
9WILMKLP]WTIGMEPM^IHJYRGXMSRWGVMXMGEPXS
TCB, DRM, ERH ALLFiles 1ERYJEGXYVIV
7]QFMER37
 12

Capabilities and their corresponding APIs are covered in extensive detail in Symbian Developer
Library documentation found online at developer.symbian.com.

Keeping ‘private’ information private

As described earlier, one of the key goals of platform security is to protect the mobile phone
user’s data from being accessed without authorization. In order to achieve this, Symbian OS
introduces the concept of ‘data caging.’ By default, applications are only able to access data
that they own. This means that:
• An application cannot access (and therefore tamper with) another application’s data,
therefore making data more secure.
• In order to access data other than its own, an application must make a request to the
owning application. The owning application will check that the requester has the necessary
capability and then supply the requested data.

For example, if an application wants to display some names and addresses from the user’s
contact list it must make a request from the owner of the contact database, which is the
Contacts engine. Having received the request, the Contacts engine will verify that the
application has the ReadUserData capability before supplying the required contact
information.

By using data caging to ensure data access is correctly policed by the owning applications,
data storage throughout the system is made more robust and secure.

The benefits of a good security system

One of the primary aims of platform security is to maintain the characteristic openness of
Symbian OS while giving the user a high degree of confidence in the applications they are
installing.

There are, of course, benefits for other parties in the chain:

• Phone manufacturers benefit from the protection of their reputations, which ultimately leads
to increased phone sales. In addition the devices are less vulnerable, leading to less
liability risk for the manufacturers.
• Operators do not have to deal with the additional support costs that are due to malware-
infected phones. Operators’ networks are also protected from attacks which would
otherwise affect their performance.
• Application developers benefit from a much larger market for third-party applications. Due
to greater levels of trust and confidence in third-party applications, users are increasingly
willing to purchase and install them. Correspondingly, manufacturers and network operators
are willing to support platforms that are open to after-market installation.
• Finally, the mobile phone users are secure in the knowledge that their personal data is safe
and that there is a much-reduced risk that their devices will be infected by malware.
 13

Section II: Developer Q&As

Why should I worry about security? How does it affect me?

Q. Why should I worry about security?

A. Mobile phones are always on and connected, making the data they hold vulnerable to
unauthorized access. Platform security helps the user feel that their personal information is
secure.

As an application developer you should consider the following questions:

• does your application need to access data on the device?
• does your application create data and, if so, does this data need to be kept confidential or
should it be shared with other applications?

All of these issues have an impact on how security-aware your application needs to be.

Q. Why hasn’t Symbian just followed the PC security model, using firewalls and anti-virus
software? This whole thing seems quite complicated.
A. Mobile phones are not PCs and therefore a PC-like approach is not appropriate. Mobile
phones are expected to continue running, for days and weeks, without the need for
rebooting or resets. They also have limited resources and Symbian OS is written to ensure
the efficient use of the resources that are available. Having platform security designed into
the OS offers maximum protection while still maintaining overall device performance in
areas such as battery life, memory usage, UI response times, and application speed.

Q. Will an application written prior to Symbian OS v9.x work on v9.x devices?

A. An application written for earlier versions of Symbian OS will need to be modified. The
changes required are clearly documented, for example, in the Symbian Developer Library
that can be found in every SDK. (A list of platform security resources is given in Section III.)

Q. How has platform security changed the software installation process?

A. Prior to the introduction of platform security any application could be installed on any
compatible device, and so users could potentially install malicious or badly written
applications onto their devices. Now, with platform security, there is much more control over
which applications can be installed on the phone and what the applications can actually do
once they are installed. This is controlled via the signing process (see the next section, To
use Symbian Signed or not to use Symbian Signed?).

Q. What do I need to take into account for the installation of my application?

A. The key questions are:
• does your application need any sensitive capabilities?
If you do not require access to any protected APIs, or only those protected by user-
grantable capabilities from the application set, then your application does not need to be
Symbian Signed – it can be installed untrusted after self-signing.
• which protected APIs do you need to access?
Careful analysis of your API requirements will tell you what capabilities will be needed for
your application to run correctly.

Q. Does Symbian platform security protect memory cards?

A. The general answer to this is ‘yes,’ as while the add-on storage is connected to the device
it is under the protection of the security architecture. However, add-on storage can be
 14

removed from the device and inserted into another device such as PC, game consoles, etc.,
which makes the data accessible and therefore its confidentiality and integrity can no
longer be guaranteed.

We strongly recommend that you do not store sensitive data on external storage.

To use Symbian Signed or not to use Symbian Signed?

Q. Do all v9.x applications need to be Symbian Signed?

A. No. Applications that use only APIs protected by user-grantable capabilities from the
application set, or those that require no capabilities at all, do not need to be Symbian
Signed.
Device manufacturers and network operators can set their own security policies, which often
prevent any unsigned application from installing. In these cases, applications may be self-
signed, which allows them to be installed, but because they are not Symbian Signed, they
are considered untrusted.

Releasing a self-signed, untrusted application may be a more practical option for non-
commercial applications which are distributed in limited numbers, rather than submitting
them to be Symbian Signed.

Q. At what point in the development process do I need to get my application Symbian Signed?
A. All applications which carry out sensitive operations need to be Symbian Signed before
they are released finally for users to install onto their phones. However, you do not need to
get your applications Symbian Signed during their development, since you can use the
Windows emulator and Open Signed (using developer certificates) for testing on phone
hardware.

Q. What is a developer certificate?

A. A developer certificate (DevCert) is used for testing during the development of an
application. It is usable with a specific phone, for a specific subset of capabilities, and it is
valid for a limited period from the date of issue.

You can get a developer certificate from a trusted signing authority such as Symbian
Signed, or a mobile phone manufacturer or network operator.

How do I work on a secure platform?

Q. There are hundreds of APIs called by my program. How do I determine which capabilities
I need?
A. First, you should make sure that your application really does need a capability. There are
many applications that are developed without using any of the sensitive system APIs that
are protected by platform security. Only about 40% of all Symbian OS APIs are grouped
assigned capabilities and most of these are so specialized that few applications need to
use them.
 15

Symbian OS defines 20 distinct capabilities, which can be classified within three broad
categories:

• TCB capability, only possessed by the Trusted Computing Base itself

• other system capabilities
• 'application' capabilities, which may be granted by the user.

It will help to define which capabilities your application will need early in the design phase.
The best two methods to do so are:
• List the general operations the application will perform and choose the required
capabilities. For example, an instant messaging application might require
NetworkServices to access the Internet and ReadUserData for reading from the
user’s address book.
• Review each API that you plan to use and record the capabilities required for each one.
Keep in mind that it may be possible to find a higher-level API which can perform the
operation required with fewer capabilities.

Note that the application may need to be approved by a third-party, such as Symbian
Signed, a network operator, or the mobile phone manufacturer in order to be granted
certain capabilities to be able to run on a real device.

Q. What determines the capabilities of a process?

A. The capabilities of a process are determined by those assigned to it at build time. A process
can load a DLL that has a larger set of capabilities than it does, as long as the DLL has
been trusted with at least the same set of capabilities that the process has.

Q. Why do DLLs need capabilities?

A. A DLL contains code that accesses APIs just like any other piece of code and it therefore
needs to adhere to the same security policies. A DLL is prevented from being loaded into
any process which has a capability that the DLL does not already have.

Q. What capabilities do plug-in DLLs need?

A. Plug-in DLLs are treated in exactly the same way as standard DLLs.

Q. What capabilities do shared DLLs need?

A. Each shared DLL will need to be assigned a set of capabilities that covers all the
capabilities requested by the applications that use the DLL.

Q. Why does my DLL need to have all of these capabilities it doesn't use?
A. A DLL may need to possess capabilities that it does not itself use, if it is to be loaded by
an application which needs those capabilities. DLLs that are intended to be shared with
third-party applications are often signed with a large set of capabilities so that they may be
used by a greater number of applications, as the DLL developer does not know in advance
which capabilities the applications will need.

Q. What is data caging? How does it work?

A. Since Symbian OS v9, a number of restrictions have been put in place so that applications
can only write data to certain filesystem locations. This prevents applications from being
able to access data owned by other applications, or tamper with the binaries of other
applications of the operating system itself.
 16

This means that it is much easier to track data and to protect the files and content from
unauthorized access.

Q. Is the private directory created automatically in data caging?

A. Yes! Each application has a directory under \private which the installer will create
automatically. You will find this directory useful, as only the application associated with this
directory can create, read, and write files there. Use this file location in order to ensure your
data is protected.

Installing your application

Q. I tested and debugged my SIS file but it still does not install correctly.
A. Tools from earlier kits will not work correctly. Also you will need at least version ‘4,0,0,1’ for
MakeSIS as it creates package archives which use the new SIS file format.

A complete list of the tools you need can be found in the Symbian Developer Library, which
accompanies each SDK and can also be found online at developer.symbian.com.

Q. I tested and debugged my SIS file but it still does not install correctly.
A. This may be because you are still trying to use a certificate that you used at the testing
stage, when using Open Signed (and developer certificates). You should rebuild your
application, using an up-to-date version of MakeSIS, to create a new SIS file in order to
remove the developer certificate references. Your SIS file should then contain the correct
binaries ready for release.

Q. My application does not require any capabilities, so why do I get a message on my phone
that it is from an ’untrusted’ source?
A. This is a standard installation warning, used if the application hasn’t been signed by a
trusted authority such as Symbian Signed.

To remove the warning, you can submit your application for either of the Express Signed or
Certified Signed options offered by Symbian Signed. This also may make your target market
feel more comfortable when installing your application, as it indicates that it comes from a
trusted source.
 17

Section III: Further Material

Below is a list of various additional resources which will help you to understand more about
how to work with platform security and Symbian Signed.

Books from Symbian Press

Symbian OS Platform Security: Software Development Using the Symbian OS Security

Architecture, Craig Heath et al., Symbian Press, 2006.

Developing Software for Symbian OS, Second Edition: A Beginner's Guide to Creating Symbian
OS v9 Smartphone Applications in C++, Steve Babin, Symbian Press, 2007.

Platform security resources for developers

Platform Security and Symbian Signed - Foundation for a Secure Platform

(developer.symbian.com/main/downloads/papers/PlatSec_and_Symbian_Signed.pdf), January 2008.

‘Platform Security Concepts’ - chapter 2 (a sample chapter) from Craig Heath's book
(developer.symbian.com/main/learning/press/books/sops/plat_sec_chap.pdf), March 2006.

Platform Security Guide in the Symbian Developer Library (e.g., for Symbian OS v9.3,
www.symbian.com/developer/techlib/v9.3docs/doc_source/guide/platsecsdk).

‘Platform Security’ – chapter 8 of Symbian OS Internals, available on the SDN++ wiki. This is
only available to SDN++ members, although the paper version is available by buying the book
(developer.symbian.com/wiki/display/ppg/Chapter+8+-+Platform+Security)

Symbian Signed resources for developers

A guide to Symbian Signed (developer.symbian.com/ssguide), March 2008.

Symbian Signed e-learning on Forum Nokia

(www.forum.nokia.com/info/sw.nokia.com/id/a29509c5-9270-412b-981b-
c060036d7126/Symbian_Signed.html), March 2008.

Signing Applications for Sony Ericsson UIQ 3 Phones

(developer.sonyericsson.com/getDocument.do?docId=84686), February 2008.

Regional
A Japanese version of Symbian OS Platform Security: Software Development Using the Symbian
OS Security Architecture, Craig Heath et al. is available
(developer.symbian.com/main/learning/press/books/sops_japan/index.jsp).
18

from

Games on Symbian OS: A Handbook for Mobile Development

This book forms part of the Technology
Series from Symbian Press. It describes
the key aspects of the mobile games
marketplace, with particular emphasis on
creating games for smartphones based on
Symbian OS v9.x.

Developing Software for Symbian OS, Second Edition

This second edition of Developing Software
for Symbian OS helps software developers
new to Symbian OS to create smartphone
applications. The original book has been
updated for Symbian OS v9 and now
includes a new chapter on application
signing and platform security, and updates
throughout for Symbian OS v9 and changes
to the development environment.

Symbian Press: developer.symbian.com/press

 19

from

Symbian OS Communications Programming,

Second Edition
Targeting Symbian OS v9.1 and v9.2,
Symbian OS Communications
Programming - Revised and updated
will introduce you to the major
communications functionality in
Symbian OS and demonstrates how
to perform common tasks in each
area.

Symbian OS C++ for Mobile Phones, Volume 3

This book will help you to become an
effective Symbian OS developer, and will
give you a deep understanding of the
fundamental principles upon which
Symbian OS is based.
20

from

The Symbian OS Architecture Sourcebook

This book conducts a rapid tour of the
architecture of Symbian OS and provides
an introduction to the key ideas of object
orientation (OO) in software, with a
detailed exploration of the architecture of
Symbian OS.

Mobile Python
Mobile Python is a practical hands-on
book that introduces the popular open
source programming language Python
to the mobile space. It teaches how to
program your own powerful - and fun -
applications easily on Nokia
smartphones based on Symbian OS and
the S60 platform.

Symbian Press: developer.symbian.com/press

 21

from

For all Symbian C++ developers:

Developing Software for Symbian OS
by Steve Babin

Symbian OS C++ for Mobile Phones – Volume 1

by Richard Harrison

Symbian OS C++ for Mobile Phones – Volume 2

by Richard Harrison

Symbian OS Explained
by Jo Stichbury

Symbian OS Internals
by Jane Sales

Symbian OS Platform Security

by Craig Heath

Smartphone Operating System Concepts with Symbian OS

by Mike Jipping

Accredited Symbian Developer Primer

by Jo Stichbury & Mark Jacobs
22

from

For enterprise and IT professionals:

Rapid Mobile Enterprise Development for Symbian OS
by Ewan Spence

For Symbian OS project managers:

Symbian for Software Leaders
by David Wood

For connectivity application developers:

Programming PC Connectivity Applications for Symbian OS
by Ian McDowall

For Java developers:

Programming Java 2 Micro Edition for Symbian OS
by Martin de Jode

For UI Developers
S60 Programming
by Paul Coulton and Reuben Edwards
 23

from

Published Booklets
Coding Standards
Coding Tips
Performance Tips
Essential UIQ - Getting Started
Getting to Market
Getting Started
Quick Recipes Taster
Java ME on Symbian OS
P.I.P.S
Carbide.c++ v1.3
Data Sharing Tips
Essential S60 - Developers’ Guide

Translated Booklets
Chinese Spanish
Japanese Russian
Korean