×
Namespaces

Variants
Actions

Archived:Python on Symbian/15. Platform Security and Application Signing

From Nokia Developer Wiki
Jump to: navigation, search

Archived.pngAquivado: Este artigo foi arquivado, pois o conteúdo não é mais considerado relevante para se criar soluções comerciais atuais. Se você achar que este artigo ainda é importante, inclua o template {{ForArchiveReview|escreva a sua justificativa}}.

All PySymbian articles have been archived. PySymbian is no longer maintained by Nokia and is not guaranteed to work on more recent Symbian devices. It is not possible to submit apps to Nokia Store.

Article Metadata
Article
Created: hamishwillee (30 Nov 2010)
Last edited: hamishwillee (08 May 2013)

Original Author: Hamish Willee

This chapter explains Symbian platform security and application signing from a Python developer's perspective.

Contents

Introduction

On Symbian, application signing and platform security make it very difficult for malicious or badly-written software to subvert the normal operation of a device, while still ensuring that the phone is easy for the user to operate and that honest developers can create powerful and compelling applications.

Application signing is used to determine which applications are trusted, while Platform security allows only trusted applications to call sensitive APIs and access areas of the file system.

Platform security

The two most important platform security concepts are capabilities and data caging.

What are capabilities?

Capabilities are access tokens that an executable must have in order call sensitive APIs or access protected areas of the file system. For example, in order to access the Internet, an application must have the NetworkServices capability. If an application calls an API without having the the associated capability, then it will crash (in Symbian terms it will panic with code {{{1}}} (KErrPermissionDenied)).

The most common capabilities are the following "user capabilities". These may be granted by the user at install time:

  • NetworkServices for any operation that results in a network connection
  • LocalServices for operations that access to bluetooth, USB, or infrared connections
  • Location for positioning information.
  • ReadUserData to read the device user's data including contacts and calendar information
  • WriteUserData to write the device user's data including contacts and calendar information
  • UserEnvironment to record audio, use the camera, or otherwise use services that provide data from users' physical surroundings

Other capabilities are less commonly needed by applications, and can only be granted to applications through Symbian Signed. The System, Restricted and Device manufacturer capabilities groups are discussed in the reference library

How do I add capabilities to my app?

The application packager gives your application the user capabilities by default. If your application needs different capabilities you can replace the default set using caps keyword in the "Additional options" field (capability names are separated using the "+" symbol):

--caps=LocalServices+NetworkServices+...

Note that caps replaces the existing capabilities - if you need the user capabilities, these will need to be entered again.

What capabilities should I give my application?

The application packager gives your application user capabilities by default. If you're self signing the application and you don't mind the user being presented with a prompt asking for capabilities that the application doesn't use, then there is no need to change them.

If you're signing your application through Symbian Signed, then you should give your application the minimal set of capabilities it needs to access the functionality it uses. Working out which ones you need is usually easy. Many applications won't need any capabilities at all - no capabilities are required to call standard Python functions. Of those that do, the vast majority will only need the User capabilities listed above. There are a few exceptions - for example, SwEvent is needed by the KeyCapture module; these should be documented in your module documentation.

Note that if your application uses more advanced capabilities you will also need to request a developer certificate from Symbian Signed in order to be able to install the application during development.

What capabilities should I give my Python extensions?

Advanced users can extend Python using C++, as discussed in Chapter 13.

Python extensions are DLLs and must obey the same rules as other DLLs on the Symbian platform. A DLL must have all the capabilities of the loading executable:

  • If the DLL is solely for the use of a single application then give it the same capabilities as the application.
  • If the DLL is shared (to be loaded into many processes) then give it all the capabilities of all the processes (System DLLs have all capabilities except TCB so that they can be loaded into any process).

Note also that some DLLs also require capabilities because they call protected APIs. In this case both the DLL and the loading process must be granted the capability.

What if I don't use the right capabilities?

If your application has insufficient capabilities, it will crash with {{{1}}} (KErrPermissionDenied).

First, you should check that the application has the capabilities that grant the broad functionality it uses (e.g. NetworkServices for Internet access). .

What is data caging?

Data cages are file system directories that are protected against reading or writing (or both). Attempts to access files in these directories returns an error code. Python applications are given their own "private directory" (a private data cage) to which they have sole access (where their resources and data files can be securely stored). The location is based on the name of the Python application's UID.

For example, an application with UID 0xE80B00C9 has a private directory \private\E80B00C9\.

Note that one implication of data caging is that file browser applications cannot read certain protected directories, including /sys/bin (all executable code), /resource/ (Symbian resource files) or \private (application private directories). To read these areas requires the (very hard to get) device manufacturer capability AllFiles; To write needs the capability TCB.

Application signing

Symbian uses an application testing and signing program called Symbian Signed to determine which applications may be trusted, and with what platform security capabilities. While you're developing an application, it can also be signed with a special developer certificate (also from Symbian Signed) or self signed, both of which grant lesser levels of trust to the application and hence result in certain limitations.

What are the signing options?

The signing options are:

  • Symbian Signed
    • Express Signed
    • Certified Signed
  • Developer Certificate Signed
    • Open Signed Online
    • Open Signed Offline
  • Self-Signing

Each of the options gives different warnings to the user on installation and provides different access to capabilities - for more information on the capability to signing option mapping see www.symbiansigned.com.

The options are discussed in the following sections.

Symbian Signed

Symbian Signed is an application testing and signing program. Most Python applications can be Symbian Signed using the Express Signed route discussed below; few Python applications will need the restricted or device manufacturer capabilities granted through Certified Signed .

Symbian Signed applications are encoded with a tamper-proof digital certificate that identifies the vendor, grants all the capabilities of the contained binaries, and allows the application to install without warnings on Symbian devices. Many distribution channels, including Handango and the Nokia Nokia Store require that applications be Symbian Signed.

The purpose of the Symbian Signed is to determine which applications can be trusted to run on Symbian platform devices. Much of the trust comes from the fact that the identity of the vendor is known - applications submitted to https://www.symbiansigned.com/app/page/ must be signed with a Publisher ID from Trustcenter.

Applications may be Symbian Signed using either Express Signed or Certified Signed routes. In both cases the application is expected to comply with the Symbian Signed Test Criteria. The difference is that every Certified Signed application is tested by a test house while Express Signed applications are only occasionally audited (if they fail, the developer will subsequently need to use Certified Signed for several signing runs). Express Signing is consequently much cheaper, but as because it conveys less trust, can only grant user and system capabilities. Certified Signed applications may additionally have restricted capabilities if these are needed.

Developer certificates

Applications that use only the user capabilities can be self signed, and will not need a developer certificate.

Developer Certificates (DevCerts) are limited certificates that are are locked to a particular mobile device or set of devices and always display a warning that the application is untrusted on installation. They are issued by Symbian Signed and are primarily intended for giving access to more advanced capabilities during development.

Symbian Signed makes developer certificates available to companies through Open Signed Offline on request. The certificate returned to you is locked to the IMEIs that you specify when you request the certificate (at most 1000 devices).

Open Signed Online can be used to DevCert sign an application for a single IMEI through the https://www.symbiansigned.com/app/page website. This mechanism grants more capabilities than self signing and can be used as a distribution mechanism for freeware that needs more than the user capabilities. It can also be used as a mechanism for signing your application during testing if you are not a "company" and hence can't request an offline developer certificate. Note however that using the turnaround time for signing using Open Signed Online is where an application is signed with a certificate created by the developer. As the platform has no basis for trusting the application:

  • Self-signed applications that use more than the "user capabilities" (those capabilities where the the user can make an informed decision about the risk of installing the application - NetworkServices, LocalServices, Location, ReadUserData, WriteUserData, and UserEnvironment) cannot be installed.
  • On installation the device user is informed that the application is untrusted. They are then told which user capabilities it requests and asked if they wish to continue the installation.
  • Many distribution channels will not accept self-signed applications. For example, Ovi store requires that your application is Symbian Signed.

The application packager self-signs applications by default. Provided you don't want to distribute applications through some of the application stores and the warnings do not concern you, this may be an acceptable signing approach.

What signing options should I use for distribution?

Python applications that need to be distributed through application stores or which cannot have "trust warnings" are usually Symbian Signed through the Express Signed route (or Certified Signed in the rare case where restricted capabilities are required).

Applications that need only user capabilities and where warnings are not important may be self-signed.

What signing options should I use for testing/development?

Most Python applications only require the "user capabilities", and can hence be self signed during development (a self signed certificate is used by the Application packager by default, so you don't need to do anything!)

Applications that need more capabilities can use Open Signed Offline or Open Signed Online .

What are the freeware signing options?

Self-signing can be used for applications that only request the user capabilities; if system capabilities are also required then "Open Signed Offline" can be used. Note however that in this case is case the user must sign the application through the web portal themselves, rather than you supplying them with a pre-signed signed file.

At time of writing there is no mechanism for Symbian Signing of freeware; note however that application stores will sometimes sponsor applications for signing.

How do I change the certificate used to sign my application?

The application packager automatically signs the application SIS file created for device targets with a default self-signed certificate. You can change this to specify a self signed certificate with your own company details (which you can create using makekeys from the Symbian SDK), a developer certificate, or a publisher ID (prior to submission to Symbian Signed).

Special considerations for Symbian Signing PySymbian Applications

PySymbian applications can be signed using the same mechanisms and options as any native application.

The only issue is that if you want to Symbian Sign your application then you need to supply a standard Symbian .PKG file in your submission .zip file; and unfortunately the application packager doesn't use or create one. The workaround is to use the dumpsis command line tool from the Symbian platform C++ SDK (\Epoc32\tools\dumpsis.exe):

dumpsis filename.sis

The command extracts the files from the sis into a subdirectory with the same name as the original SIS file name. You can use the package file generated in your Symbian Signed submission.

How do I get started?

After reading this article you should have a fairly good idea which signing option you need to use based on the capabilities required by your application. For most applications this will be either a Self-signed or Express Signed.

Summary

This article provided a simple introduction to platform security and application signing for Python application developers.

The "Complete Guide to Symbian Signed" provides more detailed information when you're ready to start signing an application, although the articles do make the assumption that the reader has developed a native C++ application.


Licence icon cc-by-sa 3.0-88x31.png© 2010 Symbian Foundation Limited. Portions copyright Bogdan Galiceanu, Hamish Willee, Marcelo Barros de Almeida, Mike Jipping, Pankaj Nathani and others in wiki document history list. This document is licensed under the Creative Commons Attribution-Share Alike 2.0 license. See http://creativecommons.org/licenses/by-sa/2.0/legalcode for the full terms of the license.
Note that this content was originally hosted on the Symbian Foundation developer wiki.

This page was last modified on 8 May 2013, at 08:50.
53 page views in the last 30 days.