Application Integrity and Security for mobile applications in Sony Ericsson phones

Transcription

1 Tutorial March 2007 Application Integrity and Security for mobile applications in Sony Ericsson phones

2 Preface About this tutorial This tutorial has been written by Simon Judge, a freelance mobile developer who develops for Symbian, Java ME and Windows Mobile. This document describes how to set up the UIQ Symbian development environment. Any opinions in this document are those of Simon Judge and not necessarily those of Sony Ericsson. This tutorial is published by: Sony Ericsson Mobile Communications AB, SE Lund, Sweden Phone: Fax: Sony Ericsson Mobile Communications AB, 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. First edition (March 2007) Publication number: EN/LZT /3 R1A 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 March 2007

3 Sony Ericsson Developer World On developers will find documentation and tools such as phone White papers, Developers guidelines for different technologies, SDKs (Software Development Kits) and relevant APIs (Application Programming Interfaces). The Web site also contains discussion forums monitored by the Sony Ericsson Developer Support team, an extensive Knowledge base, Tips and 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 Web site. Document conventions Terminology API DLL IMEI OEM Application Programming Interface Dynamic Link Library International Mobile Equipment Identity Original Equipment Manufacturer Typographical conventions Code is written in Courier font: on (keypress "<Up>") { gotoandplay("subscribe"); } 3 March 2007

4 Trademarks and acknowledgements Symbian, Symbian OS 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 Version R1A First version 4 March 2007

5 Contents Introduction...6 Application integrity...6 Symbian platform security...7 The origins of platform security...7 Signing...7 Processes and DLLs...8 UIDs and SIDs...8 Capabilities...9 Data caging...10 Application signing...11 Self signed...11 Symbian Signed...11 ACS publisher ID...11 Developer certificates...12 Symbian Signed testing...12 Test criteria...13 Documentation and further reading March 2007

6 Introduction This document explains why mobile applications need to be more robust than typical PC or server applications. It goes on to describe Symbian platform security within UIQ 3 devices. This document forms part of the Getting Started series. Although application integrity and security may seem to be advanced topics, they are in fact Getting Started topics in that they should in fact be considered well before an application is specified, designed and coded. Application integrity should be designed in the beginning because it is very difficult to implement late in the development cycle. Furthermore, application features can often be modified or removed from the requirements and designed so as to prevent or reduce the need for 3rd party testing and certification. This document differs from existing documentation on Symbian platform security in that it also explains why it came about, clears up some common misconceptions and provides some practical tips. There is only a brief mention how to use the development tools to sign applications. This will be the subject of a future tutorial. Application integrity Programming for mobile phones introduces some new considerations that tend to be less important when programming for the PC or server: Keeping the device working. An application should not inadvertently (or deliberately in the case of malware) stop the phone from working normally, especially as it might be required for use in an emergency. Application consistency and usability. Network operators are keen to ensure that applications install, operate and uninstall in a standard way so as not to confuse users and not cause undue customer support calls. Preventing unexpected billing. Consumers and network operators require that the user know about all activities on the phone that are likely to cause an entry on the user phone bill. Conservation of resources. Battery power and memory should be used indiscriminately. Privacy of data. The user data should not be modified or sent from the phone without user permission. DRM protected applications and data should be stored in such a way as to remain protected. In terms of design and programming, this leads to some areas that require more care. These include: Provide functionality to keep the application in background when a phone interruption occurs, for example during an incoming SMS or phone call. Error check all cases where memory is allocated so as to report an error and close the program without memory leaks when this occurs. Code so as to not lose objects and not leak memory even when an error occurs. Install consistently named files to standard locations. Uninstall all application files when an application is removed. Do not write code that continually runs in a tight loop, for example polling a status, because this will cause high battery drain. Instead, use mechanisms (such as CActive, semaphores) that trigger events. 6 March 2007

7 In addition, for untrusted applications, the Symbian OS will automatically: Warn the user when a billing operation is likely to occur. Warn the user when contacts, appointments and so on are going to be used by the program. Determining whether an application is trusted is discussed later in this tutorial. Symbian platform security The origins of platform security Symbian platform security mainly came about due to network operator concerns about application integrity in phones able to add 3rd party software. Symbian decided to pre-empt network operators either closing phones altogether, avoiding Symbian phones or insisting on applications being certified on a peroperator basis. Previously, Nokia had their own Nokia OK certification and other licensees were talking about having their own certification tests that would have fragmented testing and caused significant extra work for developers. Certification has always relied on built-in phone root certificates against which a certified application signature is compared. Prior to 2003, the respective phone manufacturers supplied the built-in certificates. Hence, there was not a common certificate across all Symbian phones. For all these reasons, Symbian decided to champion a single signing scheme with a single set of certification requirements. An incidental advantage of platform security has been improved protection of applications against piracy. If the functionality of an application relies on it being signed then it is not possible to modify the application to remove piracy protection controls without it having to be re-signed - something which can not be done without the identity of the new signer being known. It is also possible to protect content using DRM. The licensee and Symbian DRM mechanisms rely on certain files not being generally accessible. Symbian platform security provides this protection. Signing Signing is the process of providing a signature as part of the install package (.sisx) that is later compared with the built-in phone certificate when an application is installed. Applications can either be unsigned, self signed or Symbian Signed. Unsigned applications These are applications with install packages that have not been signed. They can still be installed on UIQ 3.0 phones. However, they are untrusted and can only access about 60% of the phone APIs. Furthermore, some operations, for example the ability to access the Internet from the program, cause a warning to be shown when the program is run (or installed for some types of operation). 7 March 2007

8 Self signed applications These are applications with install packages that have been signed with a certificate that does not match those on the phone. Hence, such applications are treated as untrusted and behave in the same way as unsigned applications. Symbian Signed applications These are applications with install packages that have been signed with a Symbian certificate. There are several routes to getting an application Symbian Signed that will be discussed later. Tip: One of the routes to getting an application signed is via self-certifiers (see below) which should not be confused with self-signed (see above). Applications pre-declare the facilities they require to access via capabilities defined in the.mmp file (see Tutorial 1 - The UIQ Platform). Once signed, applications have full access to APIs that require the respective capabilities without any warnings from the Symbian OS to the user. Tip: It is important to understand these three distinct types of signing mentioned above. There are many instances on Internet forums where terminology has been confused. The above describes how signed and unsigned applications behave on Sony Ericsson phones. In actual fact, licensees and network operators can choose to modify the default behaviour provided by Symbian. For example: It is not possible to install unsigned applications on Nokia S60 devices. It is not possible to install any additional S60 applications on Softbank Japan phones. Processes and DLLs In terms of an application it is the OS process that is or is not allowed to do particular things based on the application pre-declared capabilities. A DLL loaded by a process also has pre-declared capabilities. However, the DLL capabilities do not change the process allowed capabilities. This is the way of ensuring that the application does not do more than has been previously authorized. A DLL must have the same or more capabilities as the process otherwise it will not be loaded. Hence, the DLL needs to be pre-declared to have a super-set of the capabilities of all processes that will need to load the DLL. UIDs and SIDs The Symbian OS requires that each binary file have a unique ID (UID). This 32-bit number is assigned by Symbian, free of charge, via the web site. The UID is used for many things, for example, during installation to detect whether a binary file has already been installed. Tip: A binary file actually has three UIDs declared in the.mmp file: UID1 UID2 UID3 The application type (EXE for Symbian 9 and later) Sub application type (for example static versus polymorphic DLL) The unique ID for the binary file. Usually what people mean when talking about UID. 8 March 2007

9 The Symbian Signed web site allocates UIDs in different ranges according to their use: UID3 Range 0x x0FFFFFFF 0x x1FFFFFFF 0x x2FFFFFFF 0xA xAFFFFFFF 0xE xEFFFFFFF 0xF xFFFFFFFF Purpose Development use (signed) Legacy signed applications Symbian Signed Unsigned Development use (unsigned) Legacy unsigned applications The Secure Identifier (SID) is a unique identifier for each executable. It is used to define the executable private directory (\private\<sid>\) and also used as a unique id for program identification during interprocess communication (IPC). The default, recommended practice is to have the SID set to the same as UID3. Capabilities There are three types of capabilities: User-grantable basic capabilities Executables that only require user-grantable capabilities do not need to be Symbian Signed. The user will see a prompt either during installation (called blanket permission) or at time of access (called one shot permission), asking, for example, whether they give permission to access private data such as the address book. Read/WriteUserData - confidential user information - one shot NetworkServices - dialling, messaging and Internet access - one shot LocalServices - infrared, Bluetooth and USB - blanket UserEnvironment - information about environment, for example Camera - blanket Location - phone location - one shot Extended capabilities These are either capabilities for which the user would not understand if they were asked for permission, or capabilities that would provide access to more sensitive data. Hence, these capabilities require Symbian Signing. Read/Write DeviceData - sensitive data PowerMgmt - killing processes, turning phone off SwEvent - capture and generate software key/pen events TrustedUI - ability to not be influenced by other apps SurroundingsDD - access to logical device drivers ProtServ - allows server to register itself as a protected name 9 March 2007

10 Phone manufacturer (Sony Ericsson) approved capabilities These capabilities provide access to facilities deep within the phone that phone manufacturers usually wish to protect. These capabilities require Symbian signing, pre-approval and sometimes legal agreement from Sony Ericsson. In practice, there are very few applications that require and will be granted capabilities requiring phone manufacturer approval. DiskAdmin - controlling (for example formatting) a drive AllFiles - view system files and private directories CommDD/MultimediaDD - access to comms and multimedia device drivers NetworkControl - manipulate network protocols DRM - access protected content TCB - access to /sys and /resource directories Capabilities should be among the first things to consider when designing and specifying a new application. They will determine if the application needs to be Symbian Signed and if it requires manufacturer approved capabilities both of which will incur extra time and development effort. It is sometimes possible to re-design features, or do things in different ways to minimize the implications of platform security. Tip: Avoid use of manufacturer approved capabilities if at all possible. They are unlikely to be approved by Sony Ericsson, unless you have a very good cause for using them. Look through the SDK documentation to determine which capabilities are required for particular APIs. However, it is not an exact science because capabilities can depend on function parameters. For example, the capabilities required to access files depend on what particular directories need to be accessed. Tip: Consider writing a simple proof of concept application to test the APIs you expect to use. Platform security violations will be displayed in Codewarrior or Carbide.c++ debug trace. Data caging Some directories are protected under Symbian OS. Access to these directories depends on the application capabilities. Each application has its own private directory that is protected from access by other applications unless they have AllFiles capability. Tip: Do not store unencrypted sensitive information in private directories assuming it to be safe. It is still possible for users to read private directory file content, for example from applications installed on removable media cards that are later placed into PC card readers. Directory Capability for Read Capability for Write Usage \sys AllFiles TCB Applications can only be executed from here \resource Not Required TCB Help files, bitmaps, fonts \private\<sid> Not Required Not Required Application data \private\<other SID> AllFiles AllFiles <all remaining> Not Required Not Required Data shared across applications 10 March 2007

11 DLLs do not have their own private directory. Instead, they use the directory of the application that loaded them. Even though it is not possible to read or write in the private directory of another application without All- Files, it is possible to add files into the import directory of that application (\private\<other SID>\import\), at installation time only. This might be used, for example, when providing data for an existing application. Tip: The use of a common location for application files (\sys and \resource) means that there is a possibility of filename classes between different applications. Hence, files should be uniquely named. The recommended way of doing this is to include the application UID somewhere in the respective filenames. Application signing Self signed A self signed application must only use user-grantable capabilities (LocalServices, ReadUserData, WriteUserData, UserEnvironment, and NetworkServices). It must also have a UID in the non protected range 0x to 0xFFFFFFFF. The makesis command is used with a pre-defined.pkg file to create a signed SIS install file. A practical example of this will be demonstrated in a future tutorial. Symbian Signed An application that is to be Symbian Signed must have a UID in the range 0x to 0x2FFFFFFF. The first stage is to sign the application with a ACS Publisher ID certificate (see below) prior to it being sent to a 3rd party test house. This signing is used to prove to the test house that the application came from the developer. Once the application has passed testing it will be re-signed by the test house with the Symbian Signed certificate that matches the certificate pre-installed in consumer phones. In a similar manner to self signing, the makesis command is used with a pre-defined.pkg file to create a signed SIS install file. The difference is that a.cer file is also used (referenced in the.pkg file) to include the ACS Publisher ID certificate. ACS publisher ID An ACS Publisher ID is used to certify the identity of the developer. It is used when a completed application is sent for Symbian Signed testing and when requesting a developer certificate (see below) from the Symbian Signed web site. An ACS publisher ID is issued by Verisign. One ID can be used to sign an unlimited number of applications for one year. 11 March 2007

12 Developer certificates Developer certificates allow applications to be granted capabilities prior to them being Symbian Signed. This allows testing on hardware during the development process. A developer certificate can only be used on a limited number of phones identified by their IMEI and is valid for six months. Tip: Testing on the UIQ emulator does not require developer certificate. In fact, the platform security can be turned on and off either on a total or per-capability basis. The certificates themselves are obtained via a DevCertRequest tool that can be downloaded from the web site. Symbian Signed testing There are several paths to getting an application Symbian Signed: 3rd party test house This is the usual route to signing for most developers. Test houses currently include NSTL, mphasis and Cap Gemini. Applications are tested against Symbian Signed Test Criteria. Applications that pass testing are signed with the Symbian Signed certificate. Self certification These are organizations that Symbian has trusted and has agreements with to test applications against their own test processes, that are regularly audited by Symbian. Examples include IBM, Avaya, Seven, DataViz, Good, Visto. Publisher certification This is similar to self certification but also allows the organization to sign, on behalf of other companies. Re-sellers or software distributors mainly use this. Examples include Handango and OpenBit. Freeware certification This is an extension of publisher certification that provides free Symbian Signed testing for freeware developers. Cellmania currently provides this service. Licensee certification This allows Sony Ericsson to provide an additional channel for certification based on 3rd party test house testing and additional phone manufacturer specific tests. This is the route to signing for applications that require phone manufacturer capabilities. 12 March 2007

13 Test criteria The Symbian Signed test criteria document can be downloaded from the web site. Most of the criteria are straightforward. Here are some tips on passing Symbian Signed: Tip 1: Specify, design and code in the requirements/criteria for Symbian Signed testing. It is always much more difficult to include these at the end of a project. Tip 2: Read the most common reasons for applications failing ( page/overview/testcriteria) on the Symbian Signed web site. Tip 3: Some applications have functionality that inherently, by design, violates the test criteria. In these cases, apply for a waiver via the Symbian Signed web site. Tip 4: Download and use the AppTest lite application from the Symbian Signed web site. Tip 5: Symbian Signed testing is usually always the last activity in the development process and hence tends to have to be done very quickly to meet deadlines. If you think this will be the case then talk to the test house well (weeks) in advance to pre-plan testing and you may be able to get your application tested in hours rather than days. Tip 6: If your release date is very critical you might consider submitting a beta version of the application earlier on in the project to flush out any unexpected problems and test a second time immediately prior to release. Documentation and further reading One application testing and certification process for the whole Symbian OS industry: Symbian Signed Developer Certificates (DevCerts): p_devcerts.jsp How to avoid using restricted APIs for UIQ 3 and Symbian OS v9 applications: p_avoid_restricted_apis.jsp 13 March 2007

14 DevCerts frequently asked questions: p_devcerts_faq.jsp Signing applications for Sony Ericsson UIQ 3 phones: Verisign Content Signing: index.html Freeware Route to Market FAQs: Sony Ericsson Channel Certification application form: Symbian Signed test criteria: 14 March 2007