Reproduced by kind permission of John Wiley & Sons.

Responsibilities in Granting Capabilities

In this chapter we discuss who is able to approve the granting of platform security capabilities to Symbian OS applications, and how they do it. In particular we discuss the Symbian Signed application signing scheme. The scheme has been adopted by the majority of mobile phone manufacturers with Symbian OS-based phones in the market, as well as major network operators and requirements bodies; however, it is important to note that the device manufacturers and operators can choose to support other schemes should they wish to do so.

Granting Capabilities to After-market Applications

Applications may be granted capabilities (that is, they may be authorized to use particular security-related sensitive APIs) either explicitly by the user at the time the application is installed or, prior to application installation, by a digital signature from a trusted authority. As we noted in Chapter 3, the mobile phone manufacturer has the final say on the specific capabilities that can be granted by the user or by signing, but in this chapter we cover Symbian’s recommended security policy, which has been developed in consultation with phone manufacturers and network operators.

With this security policy, the capabilities the user can grant are LocalServices and UserEnvironment (see Appendix A for further details on what these capabilities control). Any application requiring other capabilities will, therefore, need to be signed. Developers submit their application to a testing and certification program such as Symbian Signed. When the signed SIS file is returned, it will be permitted by the software installer to install on a mobile phone with the capabilities requested by the application.

Granting Capabilities for Built-in Code

For applications developed specifically for, or adapted for, inclusion in a mobile phone’s firmware, the same basic development processes as outlined in earlier chapters apply. However, with such applications the authority that grants access to capabilities is the mobile phone manufacturer rather than Symbian Signed.

Mobile phone manufacturers will implement their own internal quality and test processes, in order to be assured that an application’s performance criteria meet their specific needs (in a similar way to the generic Symbian Signed process and its published test criteria). Several of Symbian’s licensees have adopted the generic Symbian Signed criteria and use them in their internal processes, adding any additional tests they feel are required – for example, to help in specifically targeting a brand, device segment or functional focus.

Granting Capabilities for Libraries

When a developer releases a library that may be used by other software (either after-market software or, in the case of plug-ins, the built-in mobile phone software), the library must be trusted with at least the same set of capabilities that are held by the process loading it (the exact rules for this are covered in Chapter 2).

If the library is going to be used by add-on after-market software, one option is simply to distribute the library as a DLL file, which can be included with, and signed at the same time as, the applications using it. That way, the DLL will be trusted with exactly the same set of capabilities that the calling application has. This has some disadvantages, however. If several applications on one mobile phone include the DLL, there will be multiple copies on the phone, which could result in name clashes and version problems. Also, an update to the DLL would have to be distributed separately to all applications which include it.

A more flexible option is to distribute the DLL in a separate, signed SIS file. In this case, the SIS file would be submitted for signing, requesting the maximum set of capabilities that could be held by any of the applications loading it.

Layered Execution Environments

Execution environments, such as Java, Visual Basic and Python, create specific challenges for Symbian’s platform security architecture, as they do for all open operating systems. In order to ensure that these environments can offer the richest functionality and the best user experience, they may need to be granted a significant set of capabilities. To ensure that security is not compromised, any such environment needs to enforce a complementary security model to that provided by the native operating system; otherwise there is a danger that applications written for the layered execution environment can bypass the security controls enforced for native applications. Signing authorities need to pay special attention to the trustworthiness of the layered security model when deciding whether to approve granting of sensitive capabilities to the layered execution environment implementation.

Overview of the Signing Process

Symbian’s application certification scheme, Symbian Signed (see Figure 9.1), was launched in March 2004. Since that time it has seen significant industry adoption and endorsement, as well as providing leadership in terms of application certification best practice. The scheme has been adopted by a range of channels as a prerequisite for distribution and provides developers with access to a significant distribution route to market by (optionally) including signed applications in the exclusive Symbian Signed catalog available to licensees and channel partners.

Figure 9.1 Logo for Symbian Signed Approved Applications

With the introduction of Symbian OS platform security, Symbian Signed becomes a key enabler for applications requiring access to sensitive APIs. Changes have been made to the existing program to support the granting of capabilities, and the Symbian Signed portal has been extended to provide a ‘one-stop shop’ for all the developer’s v9 needs. This includes developer certificates and the allocation of UIDs, SIDs and VIDs.

The signing process uses a standardized Public Key Infrastructure (PKI) to provide easy to use, robust security and authentication services. Two certificates are used – the first is the Authenticated Content Signing (ACS) Publisher ID, which has a chain of trust to a public root certificate held by VeriSign. This is used to provide developer authentication. On applying for an ACS Publisher ID using the link provided on the Symbian Signed portal, you will be asked to submit information about yourself and your organization, as well as to provide referees who can verify what you submit. VeriSign, as Symbian’s Certificate Authority, will validate your identity using this information.

It should be noted that the ACS Publisher ID is only available to companies and recognized organizations. Individual developers or user groups may utilize either Channel or Publisher Certification routes to gain cost-effective access to the signing process. In addition, there are a number of routes to market available for freeware and open source developers. For more information please visit the Symbian Signed portal (www.symbiansigned.com).

The second certificate used in the process is the Content ID, which has a chain of trust to a Symbian root certificate held on the mobile phone. This second certificate is used to provide application authorization and to approve the granting of capabilities to the application based on the authorization provided by Symbian Signed. A more detailed analysis of how to get access to and make use of these certificates will follow. In short, however, the signing process consists of four key steps:

Development.
Developer authentication (using the ACS Publisher ID).
Testing against industry-agreed defined criteria.
Signing against the mobile phone’s root certificate (using the

Content ID).

Development

As detailed in Chapter, there is special provision made for deploying in-house interim development versions of applications needing capabilities on real mobile phones for testing, without the need to constantly submit the application to the full signing process. Symbian OS developer certificates permit SIS files to be signed by the developer and enable those signed SIS files to be installed on real mobile phones for application testing. The process is managed by tying the signed applications to specific mobile phone hardware. The process works on standard mobile phones and does not require specialized software builds or new hardware. The developer certificates have embedded within them the set of capabilities to which the developer is permitted access, alongside identifiers for the specific mobile phones (using hardware identifiers such as the IMEI or ESN) on which the signed application may be installed. Identifying specific mobile phones ensures that a test build of an application cannot accidentally leak out and be installed by the general public. Details of the process for obtaining and using these certificates are given later.

Developer Authentication

Developer authentication provides a mechanism to build trust in your relationship with end-users, publishers and channels by enabling those parties to reliably identify you. This enables them to associate you with reliable applications and builds confidence in the quality and stability of your products through their ongoing commercial relationship with you. Your customers have the assurance that a developer-authenticated application does, in fact, come from you, the trustworthy source. Symbian Signed achieves this through the ACS Publisher ID mentioned above. The private key of your ACS Publisher ID is your unique developer identity, which is validated using the VeriSign Class 3 public root. The identity verification procedure utilizes industry-recognized processes and database sources. However, if a mistake is made – a fraudulent identity is used or the private key is disclosed – the ACS Publisher ID may be revoked to ensure no further content-signing requests can be made using that ACS Publisher ID.

On completion of your own internal quality assurance and test processes (including validating your application’s performance against the Symbian Signed criteria), you sign your SIS file using the private key of your ACS Publisher ID. This is a crucial step before you submit your application to the Symbian Signed portal and your selected test house for testing. A step-by-step guide to this process follows later in this chapter. At this stage the application is not Symbian Signed. This signature only validates who the submitting developer is and prevents tampering with the SIS file once submitted (any changes would be detected by a change in the unique hash that is part of the digital signature).

Testing Against Defined Criteria

Once submitted through the Symbian Signed portal, the application, signed with your ACS Publisher ID, is forwarded to your selected test house. The test house will provide a quote for the testing of the application in line with their published pricing policy. This policy may be found on the portal under ‘Test House Information’.

Once you have accepted the test house’s quote, they validate the application against the test criteria (which you can freely download from the Symbian Signed portal to ensure you comply with them) and provide you with a final report. Testing consists of two main elements. The first is generic testing, which is performed on all applications to validate their stability and adherence to required processes (such as the correct use of UIDs, including correct platform identifiers in your SIS file, and efficient memory usage and cleanup). The second element consists of targeted tests based on the specific capabilities used by your application – through the use of such targeted testing the price of the test process can be reduced and provide price point benefits to the developer. It should be noted that the more capabilities you have used, the more testing is required – and hence the more costly the test cycle is likely be.

Signing Against the Phone’s Root

Applications which successfully pass the tests are handed on to the Certificate Authority (CA) where your ACS Publisher ID signature is removed and replaced with a Content ID signature with a chain of trust to the Symbian root on the phone. The Content ID is a unique certificate, which has an audit trial back to you, the developer, and also validates against the ‘trust anchor’ – the Symbian root certificate on the mobile phone. It is at this stage that the application is Symbian Signed and can be installed by users with the appropriate capabilities validated by the Software Installer.

Whilst every effort is made to ensure testing is as comprehensive as possible, there is a need to ensure the certification process is affordable to all developers. Hence the level of testing that is possible is an agreed compromise with all major stakeholders in the mobile phone industry. No testing solution can provide a 100% guarantee of quality, especially in the event of any deliberate intent to introduce security threats to the mobile phone. In the unlikely event that such a threat is actually found after testing and release, the uniqueness of the Content ID can be used to revoke an application and hence prevent it from causing further harm. We discuss revocation further shortly.

Step-by-step Guide to Signing

Getting your ACS Publisher ID

As mentioned earlier, a key aspect of Symbian Signed is the identification and authentication of the developer. This creates a relationship based on trust with the channels through which you distribute your applications.

Your ACS Publisher ID is essential to the Symbian Signed process and can be obtained via the Symbian Signed portal or directly from the Certificate Authority (CA). We suggest you take advantage of the links on the Symbian Signed portal to take you directly to the correct ACS pages on the CA’s portal; this will save time and reduce the risk of applying for the wrong type of ACS Publisher ID. Note that the ACS Publisher ID you receive for Symbian Signed is a generic, standard ID and may be used to sign applications for other platforms where appropriate. Obtaining an ACS Publisher ID suitable for use with Symbian Signed is purely a software process with no additional hardware tokens to add to the cost, the complexity or the time taken for the ID to be issued.

Figure 9.2 Requesting an ACS Publisher ID

Selecting ‘Prerequisites’ from http://www.symbiansigned.com/app/page/ process will take you to the ACS Starter Pack page shown in Figure 9.2. Select ‘Buy Now’ and complete the enrollment form. At the time of writing, the recommended browser is Microsoft Internet Explorer. Ensure information is entered correctly and accurately, as it needs to be verifiable. Also, ensure you make a careful note of your chosen challenge phrase and keep this somewhere safe – the final certificate cannot be picked up without this. Once your enrollment form data is verified you will be notified of your successful application and provided with a URL to visit to pick up your new ACS Publisher ID.

When you log on to pick up your ACS Publisher ID you will need the PIN number included in the notification email and the challenge phrase you selected as part of the enrollment process shown in Figure 9.3. IMPORTANT: Donot tick the box to protect your private key otherwise you will be unable, in future, to export it for the signing process. Follow the process and your new certificate file will be imported into your browser.

While it is a necessary part of the signing process to have the application signed with an ACS Publisher ID, this does not mean that the small developer, or the freeware or open source developer, needs to purchase one. A range of publishers are able to test applications and they use their own ACS Publisher ID to sign an application, based on commercial terms agreed between the developer and the publisher. This provides the small developer with a low-cost route to signing. In addition, Symbian has worked hard to provide a route to market for free applications, and further details about that process are available at the Symbian Signed portal (http://www.symbiansigned.com).

Developer Certificates

SIS files signed with developer certificates are validated on the mobile phone by the software installer using a different root certificate from the one used for SIS files that are signed going through the regular Symbian Signed procedures. It is, therefore, possible for a mobile phone manufacturer to choose to exclude support for Symbian developer certificates while still supporting applications signed with a regular Symbian Signed Content ID certificate. However, at the time of writing indications are that the majority of Symbian OS-based mobile phones will include both root certificates, and thus support both signing procedures.

Validation for developer certificates includes checks that:

one of the mobile phone identifiers (IMEI or ESN) in the certificate matches that of the phone the SIS file is being installed upon;
the certificate has not expired (i.e. it is less than six months old);
the binaries inside the SIS file are assigned only the capabilities listed in the certificate.

The set of capabilities allowed will vary depending on how the certificate is applied for and issued, as shown in Table 9.1.

Figure 9.3 Retrieving an ACS Publisher ID

Table 9.1 Classes of Symbian Signed Developer Certificates

No matter which of the groups you wish to secure a developer certificate for, submission is always via the Symbian Signed portal, making the process simple and transparent for the developer.

Requesting a Developer Certificate

To make the process of acquiring a developer certificate as easy as possible, Symbian has provided a free Windows-based wizard application for developers to download. This is available from the Symbian Signed portal. Once installed, you can run the wizard (see Figure 9.4) and follow a simple five-stage process to obtain your certificate.

Here’s a brief run-through of the process:

Specify the name for your output certificate request file (CSR) which the wizard will produce. The output from the wizard is a single CSR file, which contains all the necessary information for your actual certificate to be created. At the end of the wizard process, you submit your new CSR file to the Symbian Signed portal and you will be sent back a new developer certificate.
At this point you have the option to either enter the file names of your ACS Publisher ID and related private key into the entry fields - the application uses the private key to create the CSR file to be used in the creation of your developer certificate. The private key from your ACS Publisher ID is used locally by the application and is not included in the CSR file, which merely uses the certificate data (containing the public key). Or create a private/public key pair using the application and the data entered. Again the private key is used locally by the application and is not included in the CSR file. The method you choose here will affect the number of mobile phones that can be included in the final developer certificate – see Table 9.1.
Enter some personal information to be contained in the developer certificate.
Specify the mobile phone identifiers (IMEIs) you wish to include in your developer certificate. Here, you can also select which subset of available capabilities you wish to request (again, this is dependent on your actions in Step 2, and Table 9.1, which lists the capabilities available with and without an ACS Publisher ID).
Finally, you can review and confirm your choices so far, before either going back to amend them or creating the CSR file. Once the wizard has completed, you can take the CSR file and upload it to your account on the Symbian Signed portal.

Figure 9.4 Developer Certificate Request Tool

Using a Developer Certificate

When you have submitted your CSR file and it has been verified, a new certificate will be generated and returned to you. This is your developer certificate. You can begin using the new certificate immediately – much as you would use the CER and KEY files generated from your ACS Publisher ID when submitting your final SIS file to be Symbian Signed. You simply build your SIS file with the MakeSIS tool and then sign it with the SignSIS tool (see Chapter 3, Section 3.3.)

Submitting an Application for Certification

Having developed and tested your application – perhaps using the emulator as described in Chapter 3, and using developer certificates to test on a real mobile phone – we recommend that the final stages of your application quality assurance include testing against the test criteria for Symbian Signed. This will save time and money by preventing unnecessary re-submissions because the application was noncompliant in one or more of the tests. The test criteria can be found at http://www.symbiansigned.com/app/page/requirements. The page also provides a link to useful tools that may assist you in your development and testing. Once you have verified your application’s behavior against the test criteria, you are ready to submit your application to the Symbian Signed portal or Publisher/Channel process.

Preparing Your ACS Publisher ID Keys and Certificate for Signing The first step in submitting your application is to export your ACS Publisher ID keys and certificate so they can be used by the Symbian OS packaging tools (you do not need to repeat this step if you have already done it for previous submissions).

The following instructions are for Microsoft Internet Explorer. Go to ‘Tools’ and select ‘Internet Options‘ (see Figure 9.5). Select the ‘Content’ tab and under the ‘Certificates’ section select the ‘Certificates’ button

Figure 9.5 Internet Explorer Internet Options Dialog

(see Figure 9.6). Look down the list of displayed certificates and select your ACS Publisher ID. This will have your name under the issued-to column and ‘VeriSign Class 3 Code Signing 2001 CA’ under the issued-by column. Press the ‘Export’ button. Now select the ‘Yes, export private key’ option (see Figure 9.7). If you are unable to select this option, or the option is grayed out, you may need to contact VeriSign as this generally means that the private key was protected at pick up.

At the Export File format dialog, select PKCS#12. Do not select the box marked ‘Delete private key if export is successful’ – this will remove your certificate from the browser, which will make it unavailable for future signings. We would recommend you password protect, or alternatively, use PGP or a similar form of encryption, to protect the file. Finally, specify a name (for example, ExampleACSPublisherId) and location for the export file and protect access to the file once again. This last step is especially important if you choose not to password protect the keys in the earlier part of the process.

At this point you have a PFX file, which contains both the private and public keys. You now need to export this into file formats recognizable to the Symbian OS tools, using the key export tool (vs_pkcs.exe) that

Figure 9.6 Exporting your ACS Publisher ID Certificate

is available from VeriSign. The simplest way to locate this tool is to use the link provided in the paper ‘How do I get my Symbian OS application signed’, whichmay be downloaded from the ‘Process’ section of the portal (http://www.symbiansigned.com/app/page/process). The link can be found in ‘Section 2: Signing your SIS file with your ACS Publisher ID’.

Download the tool and unzip the contents (vs_pkcs.exe and readme.txt) into a new folder on your PC. You can now use the tool to extract the certificate and key files. Note that these will not be password protected and should, therefore, once again be secured using PGP or similar.

Run vs_pkcs using the command line prompt and provide the names you wish to use for the final certificate files. For example:

C:\> vs_pkcs -p12 ExampleACSPublisherId.pfx -passwd frederick -key ExampleACSKey.key -cer ExampleACSCert.cer

In this example we have used the ExampleACSPublisherId.pfx file defined above. The output file names are ExampleACSkey for the key file and ExampleACSCert for the certificate file. The -p12 argument recognizes the PKCS#12 format used, and the password used is ‘frederick’.

Figure 9.7 Exporting the ACS Publisher ID Keys

Congratulations! You have your certificate and key file ready to be used with SignSIS (see Figure 9.8).

Figure 9.8 Certificate and Key Files for SignSIS

Signing and Submitting the Application

You will now be able to sign the SIS file containing your completed application using the SignSIS tool as described in Chapter 3. Make sure you specify the correct key and certificate files (ExampleACSkey.key and ExampleACSCert.cer in our example above) – if you use another certificate, for example a developer certificate, your application will not be accepted by Symbian Signed. In most circumstances, you should also make sure the SIS file does not have any previous signatures on it; in particular a SIS file with a developer certificate signature would still be subject to the constraints of only installing on the specifically identified mobile phones (see Chapter 8, Section 8.2.12). Having used SignSIS, your SIS file will now be signed with your own ACS Publisher ID. Once again, remember this does not mean your file is Symbian Signed. The mobile phone does not trust the application at this point – it is trusted by the test house and the CA and is tamper-proofed, but it will not be installable on a mobile phone as it is.

Now you must submit your application on the Symbian Signed portal (http://www.symbiansigned.com).

Revocation

The Need for Revocation

Revocation provides a final sanction to handle applications that may compromise user, device or network security. There are a number of reasons why an applicationmight be revoked, ranging from security vulnerabilities (either intentional, that is malware, or unintentional) to accidental or unintentional user or network impacts (bugs in the design or implementation). Although stability and conformance are verified by application testing against the test criteria as part of the Symbian Signed process (or any similar process), testing can never offer a 100% guarantee that all malware, security vulnerabilities or other bugs will be dealt with. With increasingly more expensive processes, such as in-depth source code analysis, higher levels of assurance can certainly be achieved – however, even then there are no guarantees.

A ‘fallback’ method is, therefore, required to mitigate the effects of any problems and to limit the impact of such attacks or bugs, should they fail to be found during the test process. This is where revocation of the application (through revocation of the Content ID certificate with which the application is signed) can offer a final line of defense and prevent the spread of such applications once they have been identified.

For a developer whose clear intent is to be malicious the option also exists to revoke their ACS Publisher ID, thus preventing them from submitting any further applications for certification.

In order for revocation to work there must be some reference or unique identity for the application, which may be used to identify it and hold its status. This unique identifier is the digital certificate or Content ID certificate in the case of Symbian Signed. Unsigned applications can not be revoked, as they do not have a unique identifier.

Revocation Mechanisms

Should a significant security threat or problem be found, a certificate can be revoked by the Certificate Authority (CA) changing its status on a revocation database. When a status query is made for that certificate in future, the signed application can be prevented from being installed or the user warned that the application’s status has changed and appropriate action suggested.

As we described earlier, the developer signs their application with their ACS Publisher ID prior to submission for testing on the Symbian Signed portal. Once the application has been shown to meet the Symbian Signed criteria, the developer’s ACS Publisher ID signature is removed and replaced with a unique Content ID signature, using a certificate that has a chain of trust to the root certificate stored on the mobile phone. The Content ID reference is added to the CA’s master database and provides the control point for revocation. The database maintains a status history for Symbian Signed applications, which may be queried to confirm whether an application has been revoked, or not.

Two major forms of revocation checking exist; these are Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP). CRLs rely on a database being available that contains a list of all applications that have been revoked – this is not the optimal method for the mobile environment. Firstly, the CRL can consume significant amounts of memory, and secondly, it is likely to be cached for efficiency, which can lead to latency in updates and thus applications installing even though they may have been revoked on the master database.

Symbian OS implements OCSP, as being the best fit for the requirements of a constrained mobile device. The device queries the CA’s revocation database directly to seek confirmation of the application status. This is generally initiated at installation (to prevent the application from gaining access to the device) or it may be initiated manually at any time (to validate that an application has not been revoked since installation). Symbian is also implementing a ‘push’ mechanism that allows notifications to be automatically sent to a mobile phone as soon as an application’s status changes. Figure 9.9 illustrates the various uses of OCSP for revocation checks.

Figure 9.9 OCSP Revocation Checking

Summary

In this chapter we have discussed the background to granting capabilities in third-party applications, ROM code and libraries. We have considered the elements involved in working with and signing for platform security. In addition, we have examined in some detail the process of applying for and using your developer certificate and considered the application submission process to the Symbian Signed portal, including related tools. Finally, we have looked at how the signing process enables revocation of signatures. You are now ready to sign your applications!

Symbian OS Platform Security/09. Enabling Platform Security

Contents