Platform Security For All

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. Increasing access to critical APIs.

TCE

Decreasing level of trust. Decreasing access to 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Ÿ %GGIWWWIVZMGIWSZIVWLSVXPMROGSRRIGXMSRW WLSVXVERKIGSQQYRMGEXMSRWWYGLEW &PYIXSSXLSVMRJVEVIH 

Ÿ=SY[MPPRIIHXLMWGETEFMPMX]

'EXIKSV]

LocalServices

%TTPMGEXMSR YWYEPP] YWIVKVERXEFPI

%GGIWWHEXEKMZMRKXLIPSGEXMSRSJXLITLSRI

Location

%GGIWWVIQSXIWIVZMGIW WYGLEW;M*MSVSZIV XLIEMVWIVZMGIW 

NetworkServices

6IEHXLIYWIV«WTIVWSREPHEXE %GGIWWPMZIHEXEEFSYXXLIYWIVERHXLIMV MQQIHMEXIIRZMVSRQIRX WYGLEWEYHMS TMGXYVIERHZMHISVIGSVHMRK 

ReadUserData

UserEnvironment

9THEXIERHSVHIPIXIXLIYWIV«WTIVWSREPHEXE

WriteUserData

%GGIWWEPPGSQQYRMGEXMSRWIUYMTQIRXHVMZIVW HMVIGXP]

CommDD

'EVV]SYXKIRIVEPJMPIEHQMRMWXVEXMSRXEWOW %GGIWWGVMXMGEPQYPXMQIHMEJYRGXMSRW IK HMVIGXEGGIWWXSQYPXMQIHMEHIZMGIHVMZIVWERH TVMSVMX]EGGIWWXSQYPXMQIHME%4-W  1SHMJ]SVEGGIWWRIX[SVOTVSXSGSPGSRXVSPW /MPPTVSGIWWIWXYVRSJJYRYWIHTIVMTLIVEPW JSVGIXLITLSRIXSTS[IVSJJ[EOIYTSVKS MRXSWXERHF]

DiskAdmin

MultiMediaDD

NetworkControl

PowerMgmt

6IKMWXIVEWIVZIVTVSGIWW[MXLETVSXIGXIH REQI

ProtServ

6IEHGSRJMHIRXMEPRIX[SVOSTIVEXSVQSFMPI TLSRIQERYJEGXYVIVERHHIZMGIWIXXMRKW

ReadDeviceData

%GGIWWPSKMGEPHIZMGIHVMZIVWXLEXTVSZMHI MRTYXMRJSVQEXMSREFSYXXLIQSFMPITLSRI«W WYVVSYRHMRKW

SurroundingsDD

7MQYPEXIOI]TVIWWIWERHTIRMRTYXERHXS GETXYVIWYGLIZIRXWJVSQETVSKVEQ

SwEvent

'VIEXIEXVYWXIHYWIVMRXIVJEGIERHHMWTPE] HMEPSKWMREWIGYVIYWIVMRXIVJEGIIRZMVSRQIRX 'VIEXIYTHEXIWIXXMRKWXLEXGSRXVSPXLI FILEZMSVSJXLIHIZMGI 9WILMKLP]WTIGMEPM^IHJYRGXMSRWGVMXMGEPXS 7]QFMER37

7]WXIQ

TrustedUI

WriteDeviceData TCB, DRM, ERH ALLFiles

1ERYJEGXYVIV

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 malwareinfected 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 usergrantable 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 selfsigned, 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 noncommercial 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-981bc060036d7126/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 Japanese Korean

Spanish Russian