Sony Ericsson UIQ 3 User Manual
Developers guidelines
October 2006
Signing applications
for Sony Ericsson UIQ 3 phones
Developers guidelines | Signing applications
Preface
Purpose of this document
This document describes how to handle signing of native Symbian™ OS v9 applications for
Sony Ericsson phones. The document is intended for developers of UIQ™ 3 C++ applications who want
insight in the implications of Symbian Platform Security (PlatSec) on the deployment and installation of
applications in these phones.
Readers who will benefit from this document include support engineers and software developers.
It is assumed that the reader is familiar with C++ program development and deployment in general.
These Developers guidelines are published by:
Sony Ericsson Mobile Communications AB,
SE-221 88 Lund, Sweden
Phone: +46 46 19 40 00
Fax: +46 46 19 41 00
www.sonyericsson.com/
© Sony Ericsson Mobile Communications AB,
2006. All rights reserved. You are hereby granted
a license to download and/or print a copy of this
document.
Any rights not expressly granted herein are
reserved.
Second edition (October 2006)
Publication number: EN/LZT 108 8297 R2A
This document is published by Sony Ericsson
Mobile Communications AB, without any
warranty*. Improvements and changes to this text
necessitated by typographical errors, inaccuracies
of current information or improvements to
programs and/or equipment, may be made by
Sony Ericsson Mobile Communications AB at any
time and without notice. Such changes will,
however, be incorporated into new editions of this
document. Printed versions are to be regarded as
temporary reference copies only.
*All implied warranties, including without limitation
the implied warranties of merchantability or fitness
for a particular purpose, are excluded. In no event
shall Sony Ericsson or its licensors be liable for
incidental or consequential damages of any
nature, including but not limited to lost profits or
commercial loss, arising out of the use of the
information in this document.
2 October 2006
Developers guidelines | Signing applications
Sony Ericsson Developer World
On www.sonyericsson.com/developer, developers will find documentation and tools such as phone White
Papers, Developers Guidelines for different technologies, SDKs and relevant APIs. The website also contains discussion forums monitored by the Sony Ericsson Developer Support team, an extensive Knowledge Base, Tips & Tricks, example code and news.
Sony Ericsson also offers technical support services to professional developers. For more information
about these professional services, visit the Sony Ericsson Developer World website.
Document conventions
Products
Sony Ericsson mobile phones are referred to in this document using generic names as follows:
Generic names
Series
P990 P990i, P990c
M600 M600i, M600c
W950 W950i, W950c
W958 W958c
Sony Ericsson mobile phones
Abbreviations
ACS Advanced Cryptographic System
API Application Programming Interface
DRM Digital Rights Management
HAL Hardware Abstraction Layer
IMEI International Machine Equipment Identity
MMP File extension for the Project Definition File
SDK Software Development Kit
USB Universal Serial Bus
3 October 2006
Developers guidelines | Signing applications
Typographical conventions
Code is written in Courier font, for example: TInt CCamera::CamerasAvailable()
Trademarks and acknowledgements
Symbian, Symbian OS, UIQ Technologies, UIQ and other Symbian marks are all trademarks of Symbian
Ltd.
Other product and company names mentioned herein may be the trademarks of their respective owners.
Document history
Change history
2006-05-10 Version R1A First version published on Developer World
2006-10-03 Version R2A Updated with reference to W958c
4 October 2006
Developers guidelines | Signing applications
Contents
Symbian OS v9 security architecture ........................................................................7
Introduction ...............................................................................................................8
Capabilities ................................................................................................................ 8
Restricted and unrestricted APIs ...........................................................................8
Identifiers ...................................................................................................................9
Unique Identifiers, UIDs .........................................................................................9
Secure Identifier, SID .............................................................................................9
Vendor Identifier, VID ............................................................................................. 9
Data caging .............................................................................................................10
Unsigned - sandboxed applications .......................................................................10
Symbian Signed applications ..................................................................................11
Capability mapping ..............................................................................................11
Developer certificates ..........................................................................................13
ACS publisher ID .................................................................................................13
Publisher certifiers ...............................................................................................13
Signing freeware applications .............................................................................13
Symbian OS v9 application signing .........................................................................14
Planning for development .......................................................................................15
Signing or not ......................................................................................................15
Required capabilities ...........................................................................................15
Creating a Symbian Signed application ..................................................................18
General signing procedure ..................................................................................18
Symbian Signed portal account registration .......................................................19
UID allocation ......................................................................................................19
ACS publisher ID .................................................................................................21
Developer certificates ..........................................................................................21
Testing procedures and tools ..............................................................................25
Submitting an application to Symbian Signed ....................................................25
Appendix ....................................................................................................................28
Functions listed by capability ..................................................................................29
Capability: AllFiles ...............................................................................................29
Capability: CommDD ...........................................................................................29
Capability: DiskAdmin .........................................................................................30
Capability: Drm ....................................................................................................31
Capability: LocalServices ....................................................................................36
Capability: Location .............................................................................................38
Capability: MultimediaDD ....................................................................................39
Capability: NetworkControl .................................................................................40
Capability: NetworkServices ................................................................................43
Capability: PowerMgmt .......................................................................................50
Capability: ProtServ .............................................................................................50
Capability: ReadDeviceData ................................................................................50
Capability: ReadUserData ...................................................................................54
Capability: SurroundingsDD ................................................................................65
Capability: SwEvent .............................................................................................65
Capability: Tcb .....................................................................................................66
Capability: TrustedUI ...........................................................................................66
Capability: UserEnvironment ...............................................................................66
5 October 2006
Developers guidelines | Signing applications
Capability: WriteDeviceData ................................................................................66
Capability: WriteUserData ...................................................................................74
Capability: Illegal ..................................................................................................82
6 October 2006
Developers guidelines | Signing applications
Symbian OS v9 security architecture
This chapter gives a general overview of the Symbian OS v9 security features as implemented in
Sony Ericsson mobile phones.
7 October 2006
Developers guidelines | Signing applications
Introduction
Symbian OS version 9.x is specifically intended for mid-range phones to be produced in large numbers of
units. The open development platform, featuring many new key technologies, offers large opportunities for
ISVs (Independent Software Vendors) to find markets for their products.
Introduction of new functionality, such as DRM (Digital Rights Management), Device Management and
enhanced networking functionality, has required changing of the Symbian OS core to support vital security concepts such as data protection or “caging” and restricting usage of some “sensitive” APIs.
Symbian OS v9 Platform Security (PlatSec) has been enhanced to provide a high degree of protection
against malicious or badly implemented programs, which means that such programs are efficiently
detected and prevented from executing on the platform. On the other hand, applications that have been
tested and found “trustworthy”, can gain authorization to be installed and executed on the platform, without further security confirmations on the user level. This authorization is done via the Symbian Signed programme which include procedures for signing of applications using certificates, both in the development
phase and when the application is to be packaged and distributed to the market.
This document is primarily intended to guide Symbian OS v9 application developers in the process of creating applications to be authorized via the Symbian Signed programme.
Capabilities
The term “capability” has been introduced with Symbian OS v9 Platform Security. A capability can be
assigned to a program, guaranteeing that the process started by the program uses the associated
Symbian OS v9 functionality (for example an API) in a safe way. Thus, a capability can be regarded as a
granted protection of its associated APIs. The protection is granted either by a digital signature, or by a
user permission given for an unsigned application at installation.
An application can be signed at different levels of trust. The higher level of trust, the more sensitive capabilities can be granted access. Capabilities are therefore grouped into four different sets, each applicable
for a certain level of trust. For more information, see “Capability mapping” on page 11.
Restricted and unrestricted APIs
A majority of Symbian APIs are classified as “unrestricted”, which means that they require no authorization, since they have no harmful security implications on the device or network integrity. Unrestricted APIs
are not associated with capabilities, since no protection is needed.
APIs with potential security implications are referred to as “restricted”. Restricted APIs are grouped into
capabilities based on their functionality. Applications are granted access to capabilities rather than to APIs
in order to simplify the process of authorization.
8 October 2006
Developers guidelines | Signing applications
Identifiers
Symbian OS v9 Platform Security also requires that applications can be uniquely identified and strictly
classified to reflect their PlatSec level of trust. For example, signed and unsigned application are clearly
separated by having UID values in separated value ranges.
Unique Identifiers, UIDs
In Symbian OS, objects are identified by three 32 bit globally unique identifiers, referred to as UID1, UID2
and UID3.
• UID1 is a system level identifier, distinguishing for example executables, DLLs and file stores.
• UID2 distinguishes objects with the same UID1 based on different interfaces. For example GUI applications have a common UID2 value.
• UID3 can be seen as a project identifier, for example, all objects belonging to a given program may
share a UID3 value.
With Symbian OS v9, allocation of UID3 values has been changed to further enhance security, for example to implement the data caging feature. Applications developed for public distribution must be assigned
a globally unique UID3 value, which is utilized through an automated UID allocation system implemented
within the Symbian Signed programme.
Allowed UID values have been split into one protected range for signed application and one unprotected
range for unsigned applications. Only signed applications can use UIDs in the protected range, and only
protected range UID values are allowed for signed applications. This is validated in the Symbian Signed
process. On the other hand unsigned applications are not allowed to use UIDs in the protected range, and
can only be installed with a UID from the unprotected range of values.
Secure Identifier, SID
Symbian OS v9 applications are assigned a SID value, which is automatically set to the UID3 value, unless
explicitly specified by the developer. The SID value determines the name of the folder where private application data is stored.
The SID value can be specified in the .MMP file of the application, but this option should only be used in
special cases. Normally the automatically set value of UID3 should be accepted.
Vendor Identifier, VID
A Vendor ID can be used at runtime to identify the source of the binary. It is mainly of interest for phone
manufacturers and network operators, for example when needing to restrict access to a certain service to
applications from specific vendors. Most developers have no need for a VID, and the default VID value (0)
can then be used.
9 October 2006
Developers guidelines | Signing applications
IF a VID value other than 0 is to be used, it is specified in the .MMP file of the application. VID values must
not be specified for unsigned applications.
Data caging
Data caging has been introduced in Symbian OS v9 to prevent one application to overwrite data belonging to another application.
The file system has the following structure:
• \sys : This is the restricted system area which is only accessible for highly trusted system processes.
• \sys\bin : Holds all executables such as EXEs, DLLs and plug-ins.
• \private : Each application has its own private view of the file system consisting of \pri-
vate\<SID>\. This folder is only accessible by the application itself, the software installation program and applications trusted with capabilities on the highest level (granted by the phone
manufacturer).
• \resource : A public, read-only directory allowing files to be publicly shared without compromising
integrity. An application should, for example, put its UI resource files and icon files in
\resource\apps.
Other directories are public and can be read from or written to by any program.
Unsigned - sandboxed applications
Unsigned applications are applications that have not been authorized through any signing process.
Unsigned applications are allowed access to all unrestricted APIs and a small number of restricted APIs.
Such applications are often referred to as “Unsigned - Sandboxed”, which implies that they have access
to a limited number of APIs (the sandbox).
Unsigned - sandboxed applications using any of the restricted APIs, still need to be authorized by the user
at install time. When the application is installed on the phone, the user is prompted to accept that the
application is granted “blanket” permissions to any functions that it requires. If the user accepts, the application is granted permission to the functions as long as it is installed in the phone. If the user rejects, the
installation is aborted.
Some capabilities can only be granted “one-shot” permissions when assigned to an unsigned application.
Every time the application needs access to one of these capabilities, the user is prompted to accept the
action that the application is about to perform. If the user rejects, an error condition is raised, which have
to be managed by the code.
10 October 2006
Developers guidelines | Signing applications
The following table lists allowed user granted permissions per capability for unsigned applications:
Capability User granted permission
NetworkServices One-shot
LocalServices Blanket
ReadUserData One-shot
WriteUserData One-shot
UserEnvironment Blanket
Location One-shot
Note: An application that could be deployed as an unsigned - sandboxed application may as well be subdued to the Symbian Signed process. When an application like this has been signed, no user interaction is
required at installation, and the mapped capabilities are automatically granted blanket permissions.
Note: Sony Ericsson strongly recommends users only to install signed applications in their phones and
only allows signed applications to be distributed through its official sales channels, thus encouraging
developers who want to market their applications for wide use with Sony Ericsson phones, always to
favour signed applications before unsigned.
Symbian Signed applications
The security enhancements of Symbian OS v9, have enforced a number of changes in the Symbian
Signed process. As a consequence, also developer procedures for having applications Symbian Signed
have changed considerably.
Capability mapping
Capabilities are categorized into three separate sets on different levels, depending on their potential
impact on the device, the network or the user. The more serious impact a capability might have, the higher
level of trust is required by an application to access it, and the more testing is needed in the Symbian
Signed process to make sure that the application makes use of the capability in a safe and secure manner.
Note that unrestricted APIs have no capabilities associated with them. As mentioned above, they can be
included even in unsigned applications and are automatically given blanket permission at installation.
The three cabability sets are:
• Basic capabilities
Applications requiring basic capabilities can either be Symbian Signed or unsigned. When installing an
unsigned application requiring one or more of the basic capabilities, the user is prompted to grant
11 October 2006
Developers guidelines | Signing applications
blanket or one-shot permissions at install time. Only standard (generic) testing is required for an application to be Symbian Signed.
• Extended capabilities
Highly trusted applications may be granted access to this set. For an application utilizing one or more
capabilities in this set to be Symbian Signed, it has to go comply to extended testing criteria. The
developer of the application must also explicitly declare which APIs of the capability are used, and why
they are needed.
• Phone manufacturer approved capabilities
The highest level of trust is required for applications that may have an impact on the functionality of the
device. The only way for an application to have access to these capabilities is through a “channeled”
signing procedure which involves approval by Sony Ericsson.
Basic Capabilties
• LocalServices
• UserEnviornment
• NetworkServices
• Location
• ReadUserData
• WriteUserData
Unsigned Applications
(user grantable blanket or one shot permission)
Optional signed to avoid blanket or one shot prompts
Extended Capabilties
• ReadDeviceData
• WriteDeviceData
• SWEvent
• ProtSrv
• Power Mgmt
• SurroundingsDD
• TrustedUIDeclarative
Manufactuer Capabilties
• DRM
• NetworkControl
• MultimediaDD
• TCB
• AllFiles
• CommDD
• DiskAdmin
Symbian Signed
(Requires generic test criteria adherence)
Channel Certification
(Signed Symbian + manufacturer independant tests)
Access rights to capabilities are cumulative, for example, an application signed with the basic set is also
granted access to all the unrestricted APIs.
An application signed for a particular set is not granted access to all capabilites of the set. The installer
gives permissions only to those capabilities that the application actually requires.
12 October 2006
Developers guidelines | Signing applications
Developer certificates
As a consequence of the Symbian OS v9 enhanced platform security, applications that require access to
restricted APIs can not be installed on targeted devices before they have been signed, which in turn
makes it impossible to test applications on real mobile phones during the development process. To take
care of this, special developer certificates can be achieved via the Symbian Signed programme. Developer certificates are valid for a number of of phones, identified by their IMEI number, and allow developers
to sign applications temporarily during development for installation and testing on real devices.
Testing on emulators does not normally require developer certificates.
ACS publisher ID
An application using capabilities in the extended or phone manufacturer approved sets, must be signed
with an ACS publisher ID certificate when a developer certificate is requested and when the finished application is sent to be Symbian Signed. The ACS publisher ID is used to verify the identity of the developer
and to certify that the application has not been modified during upload to the Symbian Signed portal. An
ACS publisher ID is issued by Verisign and is valid for one year. It can be used to sign an unlimited number
of applications during that period. More information on how to acquire an ACS publisher ID and the costs
for it, can be found on http://www.verisign.com/products-services/security-services/code-signing/sym-
bian-content-signing/index.html
Publisher certifiers
ACS publisher IDs are only available to recognized organizations, for example registered companies.
Developers who are not qualified for an ACS publisher ID of their own, can use an alternate route for having their applications signed. Publisher certifiers are organizations having the right to certify applications
for themselves or others, using their own ACS publisher ID. They are certified by Symbian to perform
application testing and finally make the application Symbian Signed. Normally this procedure is connected with agreement between the developer and publisher that the application is to be distributed
through the sales channel of the publisher.
Signing freeware applications
Freeware applications can also be Symbian Signed via a procedure similar to the one described above for
publisher certifiers. One condition is that the application actually is freeware, that is, it is distributed and
can be used without any costs for the user. It is also required that the application displays a special freeware disclaimer at installation.
Details about the preconditions for freeware signing and the process for it, can be found on
https://www.symbiansigned.com/app/page/freeware
.
13 October 2006
Developers guidelines | Signing applications
Symbian OS v9 application signing
This chapter describes the practical implications of Symbian OS v9 platform security and the steps developers need to take during development of Symbian Signed applications.
14 October 2006
Developers guidelines | Signing applications
Planning for development
There are a number of considerations to take in the beginning of the development process for a Symbian
OS applications. Apart from the normal system analysis and design, also the design implications on signing requirements and testing procedures specific for the Symbian OS v9 platform must be taken into
account.
Signing or not
As mentioned above, many applications do not require any capabilities and thus can be installed and executed in the “unsigned – sandboxed” environment. This may be an alternative for applications intended for
personal use or for limited groups of users. For most commercial purposes and for widely spread applications, taking the costs and extra work needed for going through the Symbian Signed processes gives several advantages and is therefore highly recommended also for applications that do not require signing.
Symbian Signed advantages:
• Symbian Signed applications have passed a number of tests, which guarantees a certain quality level,
giving added value for customers.
• Symbian Signed applications are made visible to Symbian partners, like network operators, distributors, phone manufacturers, and so on, via a special catalog, thus opening up a marketing channel for
developers making use of the programme.
• Sony Ericsson, Nokia and several major operators and service providers, only allow applications that
have passed the Symbian Signed programme to be exposed via their application shops.
The Symbian Signed programme requires that developers of applications to be submitted for signing have
an ACS publisher ID from Verisign. Under certain conditions an ACS publisher ID is also required for a
developer to retrieve a developer certificate for application testing on real devices. Since it may take some
time to be approved for it, an ACS publisher ID should be requested in good time before it is actually
required.
Required capabilities
To avoid some of the extra work and additional costs for using extended or phone manufacturer capabilities, it is a good idea always to analyze carefully which capabilities are necessary for the application. If it is
possible to implement a needed functionality using an API of a lower level capability set, or an unrestricted
API, this should always be preferred.
Another reason for early planning of which capabilities are needed for an application, is that a developer
certificate might be required for testing on real devices. To make testing as realistic as possible, the developer certificate should grant access to the same set of APIs as the finished application. For applications
using only unrestricted APIs, developer certificates are not required.
15 October 2006
Developers guidelines | Signing applications
Note that an application can only be granted rights to exactly the capabilities in a set that it actually
requires. When sending an application for signing, all requested capabilities must be declared for the
application to be approved.The following tables list all capabilities and describe in general terms what
functionalities each capability may grant to applications
.
Basic capabilities
LocalServices
Grants access to the local network. Applications
with this capability can normally send or receive
information through USB, Infrared and point-topoint Bluetooth profiles, but they can not use IP,
routable Bluetooth profiles, or the phone number
dialling functionalities.
UserEnvironment
Grants access to live confidential user information and the immediate environment of the user.
Protects privacy of the user.
NetworkServices
Grants access to protocols capable of routing
data beyond the device and its immediate personal and or local network, for example IP and
GSM. This capability is required for access to the
phone network, allowing, for example, dialling a
phone number or sending a text message.
Location
Grants access to the device location.
ReadUserData
Grants read access to user data. System servers
and application engines are free to grant this level
of restriction to their data.
WriteUserData
Grants write access to user data. System servers
and application engines are free to grant this level
of restriction to their data.
Extended capabilities
ReadDeviceData
Grants read access to confidential system data.
System data that is not confidential does not
need to be protected by this capability.
API examples:
COMMS
16 October 2006
WriteDeviceData
Grants write access to sensitive system data.
SWEvent
Developers guidelines | Signing applications
Grants read access to confidential system data.
System data that is not confidential does not
need to be protected by this capability.
ProtServ
Grants the right to a server to register with a protected name. Protected names begins with a “!”.
The kernel will prevent servers without this capability from using such a name, and will therefore
prevent impersonation of protected servers.
PowerMgmt
Grants the right to kill any process in the system,
to power off unused periferals, to put the device
into standby state and wake it up again, or power
it down completely. Note however, that this does
not control anything that might drain battery
power.
SurroundingsDD
Grants access to logical device drivers providing
input information about the device surroundings.
TrustedUI
API examples:
Test utilities, FEP
Mainly granted to system servers.
API examples:
WSERV
Grants the right to create a trusted UI session,
and thereby display dialogs in a secure UI environment.
Phone manufacturer capabilities
DRM
Grants access to protected content subject to
DRM rights restrictions.
NetworkControl
Grants the right to modify or access network protocol controls.
MultimediaDD
Controls access to all multimedia device drivers,
audio, camera, and so on.
TCB
Mainly granted to SWInstall and token servers.
API examples:
MMF, ICL, ECam
17 October 2006
Developers guidelines | Signing applications
Trusted Computing Base.
Grants write access to /sys and /resource.
AllFiles
Makes all files visible. Grants extra write access
to files under /private.
CommDD
Grants access to all communication device drivers, for example EComm and USB device drivers.
DiskAdmin
Grants access to some disk administration operations, for example reformatting a disk.
A complete list of functions per capability can be found in the appendix of this document, see “Functions
listed by capability” on page 29, in the Symbian developer library, http://www.symbian.com/developer/
techlib/v9.1docs/index.asp, and in the UIQ 3 SDK documentation.
For examples on how to avoid using restricted APIs, specifically in the phone manufacturer capability set,
please refer to the following article on the Tips and tricks section on Sony Ericsson Developer World:
http://developer.sonyericsson.com/site/global/techsupport/tipstrickscode/symbian/
p_avoid_restricted_apis.jsp
API examples:
Kernel, F32, SWInstall server
Mainly granted to test utilities and backup &
restore
API examples:
F32, SWInstall
API examples:
COMMS
API examples:
Shell
Creating a Symbian Signed application
In the process of developing a Symbian Signed application, several steps are connected with signing.
These steps are described in short here. For more detailed information, please refer to information found
in the Symbian Signed web portal, www.symbiansigned.com
General signing procedure
Before installing an application for testing with a developer certificate, the application must be signed with
that certificate. When sending a completed application to be Symbian Signed, the application package
must be signed with a valid ACS publisher ID certificate. In both situations the same general procedure
can be applied.
Only one extra step is required to make a signed .SIS file, compared to making an unsigned .SIS.
In the .pkg file, a line with the following syntax is added after the file header part and before the list of files
to install.
.
18 October 2006
Developers guidelines | Signing applications
*”<path>\<My_Private_Key>.key”, “<path>\<My_Cert>.cer”
[,KEY=”<My_PrivateKey_Pwd>]
for example,
*”files\devcert2.key”,”files\devcert2.cer”,KEY=”password”
MakeSis is run with the modified .pkg file create the .SIS file prepared for signing, and finally SignSis does
the signing.
An alternate signing method is to omit the extra line in the .pkg file, create the .SIS file with MakeSis and
finally use SignSis with parameters for the signing keys, for example:
signsis ?s app.sis app_signed.sis acs_id.cer private.key
Symbian Signed portal account registration
Most of the procedures involving the Symbian Signed portal requires login to a developer account giving
access to all the services needed during the development of a Symbian Signed application. For example,
requests of UIDs and Developer Certificates requires access to the account. Also downloads of Developer
certificates, signed applications, and so on, are performed from account specific pages in the portal.
To register a Symbian Signed portal account:
1. Go to the portal www.symbiansigned.com
2. Click the link “Register” in the left navigation bar.
3. Follow the instructions on the registration page.
.
UID allocation
For all Symbian OS v9 applications, signed or unsigned, a UID must be allocated. The UID must uniquely
identify the application within the “world” where it is to be used. For example an application to be used
only in one phone, requires the UID to be unique among all other applications on that phone, and an application to be sold on a global market must have a UID that is globally unique. To make sure that all allocated UIDs can be globally unique, Symbian have a system through which all developers can retrieve
UIDs for all their applications. This system is available via the Symbian Signed portal.
19 October 2006
Developers guidelines | Signing applications
In Symbian OS v9, UID ranges have been changed compared to earlier OS versions. The following table
lists UID ranges to be allocated Symbian APP, EXE or DLL files of different categories. UID classes 0-9
(range 0x00000000 – 0x9FFFFFFF) are referred to as the protected range, and classes A-F (range
0xA0000000 – 0xFFFFFFFF) as the unprotected range. UID ranges not in this table are reserved.
UID
class
0 0x00000000 - 0x0FFFFFFF Development use only. Normally this range is not used for Symbian
1 0x10000000 - 0x1FFFFFFF Legacy UID allocations. This is the UID range used for both signed
2 0x20000000 - 0x2FFFFFFF V9 protected UID allocations. UIDs in this range are allocated to
7 0x70000000 - 0x7FFFFFFF Vendor IDs. Normally only used by phone manufacturers and net-
A 0xA0000000 - 0xAFFFFFFF V9 unprotected UID allocations. UIDs in this range are allocated to
UID range Purpose
OS v9 applications, since Developer certificates are required. UID
classes A or E can be used during development and for test purposes.
The range 0x01000000 - 0x0FFFFFFF is reserved for test purposes
with pre-v9 applications.
and unsigned pre-V9 Symbian OS applications, not to be installed in
phones with Symbian OS v9 or later.
signed Symbian OS v9 applications via the Symbian Signed portal.
This requires login to the developer account.
work operators. If another developer needs a VID, it can not be
retrieved directly via the Symbian Signed portal, but requests can be
sent via email to symbiansigned@symbian.com.
unsigned applications via the Symbian Signed portal. UIDs are
retrieved via login to the developer account in the portal.
UIDs in this range can also be used for test applications and SDK
code examples, particularly this is useful for test projects, for example games.
E 0xE0000000 - 0xEFFFFFFF Development use only. This range is particularly suited for illustra-
tive/learning purposes, applications that are not to be redistributed
via a .SIS file, for example HelloWorld. UIDs can be randomly
selected from the range as long as they do not conflict with other
UIDs on the device.
F 0xF0000000 - 0xFFFFFFFF Legacy UID compatibility range. Used for pre-v9 unsigned applica-
tions that are to be installed on a v9 device. A UID in the range
0x10000000 - 0x1FFFFFFF allocated by Symbian to a pre-v9 application can be converted to one valid for v9 by simply exchanging the
first “1” to “F”. For example, a UID of 0x10034FD3 should be
changed to 0xF0034FD3.
To retrieve a UID from the Symbian Signed Portal:
1. Login to your account on www.symbiansigned.com
2. Click the link “Request UIDs” in the left navigation bar.
3. Follow the instructions on the UID request page.
.
20 October 2006
Developers guidelines | Signing applications
When logged in on the Symbian Signed portal, UIDs allocated to the account can be viewed by clicking
“View UIDs” in the left navigation bar.
ACS publisher ID
Having an application Symbian Signed requires an ACS publisher ID, either owned by the developer or by
a publisher certifier. The ACS publisher ID is used to verify the identity of the developer sending the application for signing, and to create the certificate and key necessary for a secure transfer of the application
into the Symbian Signed process.
To aquire a developer certificate for testing, an ACS publisher ID is required only if the application requires
certain capabilities or if testing is to be done on more than one phone. However, having an ACS publisher
ID simplifies the procedures for retrieving the developer certificate.
An ACS publisher ID has to be purchased from Verisign. The following is an overview of the procedures for
achieving an ACS publisher ID.
1. Go to http://www.verisign.com/products-services/security-services/code-signing/symbian-content-
signing/index.html and start the enrolment process by clicking the “Buy Now” button.
2. Enter the requred information in the form and accept the subscriber agreement. Verisign confirms that
the enrolment process is ongoing via email.
3. When Verisign has gone through the necessary authentication and verification procedures and
approved the enrolment, this is confirmed via another email.
4. Once approved, the ACS publisher ID can be picked up from the URL given in the approval email. To
start the transfer, a PIN code delivered with the approval email and the challenge phrase given by the
developer on enrolment, have to be entered in the browser window.
5. The retrieved ID is stored in the browser certificate store. To use the ACS publisher ID certificate for
signing, it first has to be exported from the store. A special tool, that can be downloaded from Verisign,
is then used to create the certificate (.cer) and private key (.key) files to be used for signing.
For more detailed information about the purchase process and the steps needed to make use of the ACS
publisher ID certificate for signing Symbian applications and request developer certificates, please refer to
the instructions at http://www.verisign.com/products-services/security-services/code-signing/symbian-
content-signing/index.html.
Developer certificates
During the initial phases of development, applications are preferrably tested in the emulator, normally set
to ignore PlatSec security restrictions. Later during development, testing on real phones is required to verify the application behavior in the targeted environment.
An application using only unrestricted APIs or user granted capabilities can be tested on real phones without being signed. An application requiring any other capability has to be signed with a developer certificate to allow it to be installed for testing on real Symbian OS phones.
21 October 2006
Developers guidelines | Signing applications
Developer certificates can be issued on three different levels, depending primarily on wich capabilities are
required and how many specific phones (identified by their IMEI) are to be used for testing. The following
table lists granted capabilites for each certificate level, and the requirements for a developer to be allowed
to request a developer certificate on a certain level.
Number of IMEIs 1 1-20 Sony Ericsson approved
Identity requirements • Registration
•IMEI
LocalServices • • •
Location • • •
NetworkServices • • •
PowerMgmt • • •
ProtServ • • •
ReadUserData • • •
SurroundingsDD • • •
SWEvent • • •
UserEnvironment • • •
WriteUserData • • •
ReadDeviceData • •
TrustedUI • •
• Registration
•IMEIs
• ACS Publisher ID
•Registration
•IMEIs
• ACS Publisher ID
• Sony Ericsson
approval
WriteDeviceData • •
AllFiles •
CommDD •
DiskAdmin •
DRM •
MultimediaDD •
NetworkControl •
TCB •
Note that this mapping is not fully conformant to the capabiliy sets (basic, extended and phone manufacturer approved) as defined in Symbian OS.
Requesting a developer certificate
Developer certificates can only be retrieved via the Symbian Signed portal by registered users. The process for retrieving a Sony Ericsson approved developer certificate is slightly different than otherwise, and is
described below.
22 October 2006
Developers guidelines | Signing applications
The image below gives an overview of the steps to go through for applications requiring basic and
extended set capabilities compared to when also manufacturer approved capabilites are required.
Extended Capabilities
(optional basic)
Register on Symbian Signed
Download the DevCertRequest tool
(generate a Certified Symbian Request (.csr) file)
•
Name of application
•
File information
•
Personal information
•
Phone IMEI and capabilities information
Request a new DevCert
(uploading the .csr file to generate a DevCert file)
Manufacturer Capabilities
Register on Symbian Signed
Download the DevCertRequest tool
(generate a Certified Symbian Request (.csr) file)
•
Name of application
•
File information, ACS Publisher ID is required
•
Personal information
•
Phone capabilities request.
(check 'Enable Phone Manufacturer Capabilities'
box to pick from the restricted APIs list.
•
Select 'Sony Ericsson' as phone manufacturer
•
Information about the Phone Manufacturer DevCert
•
Developer contact details
•
Request details (IMEIs, business reasons for
requiring access to restricted APIs.
•
Upload the .csr file
Request a new DevCert
Download generated DevCert
(DevCert file + unsigned SIS + private key > MakeSIS)
(uploading the .csr file to generate a DevCert file)
Download generated DevCert
(DevCert file + unsigned SIS + private key > MakeSIS)
The process for requesting a developer certificate not requiring phone manufacturer approval is briefly as
follows:
1. Login to your user account on www.symbiansigned.com
.
2. Download, install and run the DevCertRequest tool to generate a Certified Symbian Request (.csr) file
in your computer. When running the tool, the following information is entered into its dialogs (more
details on the tool can be found in the user guide included with the downloaded package):
23 October 2006
Developers guidelines | Signing applications
• Name and path for the certificate request (.csr) file to be generated. It is possible to select an exist-
ing file that will be overwritten.
• Private key and password. An ACS publisher ID certificate and its private key can be used, in which
case the tool allows more capabilities and IMEIs to be selected in the following steps. It is also possible to select an existing private key or let the tool generate a new one.
• Personal information. When an ACS publisher ID was selected, this information is automatically
retrieved and can not be altered.
• Capabilites required and IMEIs of phones to be used for testing. Capabilities are selected from a
list. IMEIs can be entered manually or imported from a text file.
When all information has been entered, the .csr and its private key (.key) files to be uploaded to the
Symbian Signed portal are generated.
3. Request a developer certificate by uploading the .csr to the Symbian Signed Portal.
4. Check that the developer certificate has been created and that its capabilities and IMEIs are the
requested.
5. Download the certificate. Together with the private key that the DevCertRequest tool generated, it can
be used to sign .SIS files for installation and test on phones with the specified IMEIs.
Requesting a phone manufacturer approved developer certificate
The process for requesting a developer certificate requiring phone manufacturer approval is briefly as follows:
1. Login to your user account on www.symbiansigned.com
2. Download, install and run the DevCertRequest tool to generate a Certified Symbian Request (.csr) file
in your computer. When running the tool, the following information is entered into its dialogs (more
details on the tool can be found in the user guide included with the downloaded package):
• Name and path for the certificate request (.csr) file to be generated. It is possible to select an exist-
ing file that will be overwritten.
• An ACS publisher ID certificate to be used and the corresponding private key.
• Personal information is automatically retrieved from the ACS publisher ID certificate and can not be
altered.
• Capabilites required and IMEIs of phones to be used for testing. Capabilities are selected from a
list. IMEIs can be entered manually or imported from a text file.
When all information has been entered, the .csr and its private key (.key) files to be uploaded to the
Symbian Signed portal are generated.
3. From the “Request Devcert” page in the Symbian Signed portal, click the link “Request Phone Manufacturer Approved DevCert”. This will start a workflow that is slightly different from the one where
approval from Sony Ericsson is not required. After selecting Sony Ericsson as phone manufacturer, the
following information has to be entered:
.
• Information about the developer certificate
• Developer contact details
• Request details, including the number of IMEIs, rational for accessing the requested phone manu-
facturer capabilities and application details.
• Business reasons for requiring access to restricted APIs
24 October 2006
Developers guidelines | Signing applications
4. Upload the .csr file. When uploaded, the request is forwarded to Sony Ericsson, where a steering
group reviews the request. Their decision is communicated to the developer via Symbian Signed.
5. When approved, the developer certificate can be viewed and checked and that its capabilities and
IMEIs are the requested via login to the Symbian Signed account.
6. Download the certificate. Together with the private key that the DevCertRequest tool generated, it can
be used to sign .SIS files for installation and test on phones with the specified IMEIs.
Note: Applications requiring capabilities from the phone manufacturer approved set, also have to go
through a special process, involving Sony Ericsson approval, to be Symbiand Signed. This process is
called channel certification and is described below, see “Submitting an application to Symbian Signed” on
page 25
For more information on the Sony Ericsson criteria for approving developer certificates and other
Sony Ericsson specific information on developer certificates, please refer to the FAQ found on http://
developer.sonyericsson.com/site/global/gotomarket/certification/symbiancer/dev_certs_faq/
p_devcerts_faq.jsp.
Testing procedures and tools
When testing an application to be Symbian Signed, a number of tests similar to the ones that Symbian
Signed test houses do, are recommended to make the final testing and signing as smooth as possible. For
that purpose a set of test tools are available from Symbian. Information about testing criteria and available
test tools can be found on https://www.symbiansigned.com/app/page/requirements
.
Submitting an application to Symbian Signed
Before sending an application to Symbian Signed to be tested and signed, there are several actions that
should be handled with care to avoid the costly and time consuming event that the application is not
approved and has to be changed in some way before it can be resubmitted.
To do before submitting the application
The Symbian Signed specification contains a list of tests that will be applied to an application to make
sure the application is of a high quality. The Symbian Signed Test Criteria document can be found on
https://www.symbiansigned.com/app/page/requirements
The following things should also be checked, to make testing/signing procedures run smoothly.
.
• UID Information
Make sure that the application UID (and VID if present) is owned by the submitter and from the correct
dedicated range: UID = 0x20000000 - 0x2FFFFFFF, VID = 0x70000000 - 0x7FFFFFFF or VID = 0.
Note: The owner of each UID, SID, or VID must match the ACS Publisher ID Distinguished Name (DN
field) otherwise the application will fail the Symbian Signed process.
25 October 2006
Loading...