View source for Symbian OS Platform Security/09. Enabling Platform Security

{| width="100%"
|-
|'''by Geoff Preston'''||align="center"|Reproduced by kind permission of John Wiley & Sons.||align="right"|'''[[Symbian OS Platform Security/08. Native Software Installer|Prev.]] &nbsp; [[Symbian OS Platform Security|Contents]] &nbsp; [[Symbian OS Platform Security/10. The Servant in Your Pocket|Next]]'''
|}

=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 <span class="plainlinks">[http://www.ghengisfireworks.co.uk/<span style="color:black;font-weight:normal; text-decoration:none!important; background:none!important; text-decoration:none;">fireworks</span>] 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
{{Icode|LocalServices}} and {{Icode|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.

[[File:Figure 9.1 platsec.jpg|frame|none|'''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
([https://www.symbiansigned.com/ '''''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 3, 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.

[[File:Figure 9.2 platsec.jpg|frame|none|'''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.

{|border="1" cellspacing="0" cellpadding="8"
|'''IMPORTANT:''' Do ''not'' 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 ([https://www.symbiansigned.com/ '''''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.

[[File:Figure 9.3 platsec.jpg|frame|none|'''Figure 9.3''' Retrieving an ACS Publisher ID]]

{|border="1" cellspacing="0" cellpadding="6"
|+'''Table 9.1''' Classes of Symbian Signed Developer Certificates
!width="110"|Authentication Process||width="90"|No. of<br />Phones||width="140"|Capabilities<br />Allowed||width="90"|Cost
|-
|Any Symbian Signed registered account
|1
|{{Icode|LocalServices<br />UserEnvironment<br />NetworkServices<br />Location<br />ReadUserData<br />WriteUserData<br />SWEvent<br />SurroundingsDD<br />ProtSrv<br />PowerMgmt}}
|Free
|-
|Symbian Signed registered account and a valid ACS Publisher ID
|1-20
|Capabilities above and<br />{{Icode|ReadDeviceData<br />WriteDeviceData<br />TrustedUI}}
|Free
|-
|Symbian Signed registered account, an ACS Publisher ID and mobile phone manufacturer approval
|As allowed by mobile phone manufacturer
|Capabilities above and additional capabilities allowed by mobile phone manufacturer from:<br />{{Icode|AllFiles<br />DiskAdmin<br />CommDD<br />Drm<br />MultimediaDD<br />NetworkControl<br />Tcb}}
|Determined by mobile phone manufacturer
|}
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.
#<li value="3">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.

[[File:Figure 9.4 platsec.jpg|frame|none|'''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).

[[File:Figure 9.5 platsec.jpg|frame|none|'''Figure 9.5''' Internet Explorer Internet Options Dialog]]

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
(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.

[[File:Figure 9.6 platsec.jpg|frame|none|'''Figure 9.6''' Exporting your ACS Publisher ID Certificate]]

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, {{Icode|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.

[[File:Figure 9.7 platsec.jpg|frame|none|'''Figure 9.7''' Exporting the ACS Publisher ID Keys]]

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 ({{Icode|vs_pkcs.exe}}) that
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 ({{Icode|vs_pkcs.exe}} and
{{Icode|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 {{Icode|vs_pkcs}} using the command line prompt and provide the names
you wish to use for the final certificate files. For example:

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

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

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

[[File:SignSisFiles.png|frame|none|'''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
({{Icode|ExampleACSKey.key}} and {{Icode|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
([https://www.symbiansigned.com/ '''''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.

[[File:Figure 9.9 platsec.jpg|frame|none|'''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!

{{SymbianOSPlatformSecurity_Copyright}}