SignSIS - the Installation File Signer

• Overview

• The process

• Package creation and signing

• SIS file installation

  • Unsigned SIS files

  • Signed SIS files

• Self-signed certificates

• Symbian Signed programme

• Developer certificates

• Mandatory certificates

• Also see

Installation files can be signed using the installation file signer, SignSIS. Any certificates and private keys are specified in the package file or as command line arguments. This documentation provides an overview of the signing process.

Note that since v9.1, to maintain platform security SIS file signing is mandatory. Installation of untrusted applications is still allowed and a means of better identifying them for later revocation is provided in the event that this becomes necessary.

The diagram below provides a brief overview of how the Installation File Signer is used.

Developers create installation packages using MakeSIS - Installation File Generator, and sign them using the SignSIS tool. These tools manipulate SIS packages only.

MakeSIS generates a software installation (SIS) file from an input package (PKG) file. A PKG file is a text file describing files and components delivered into the package, as well as any certificates and private keys to be used for package file signing, which is performed using SignSIS.

When signing a SIS file, SignSIS verifies if the supplied private key corresponds to the supplied certificate. Software Install package files can now be signed multiple-times rather than just once. Multiple signings do not have to take place at the same time - signatures may be added (and removed) from a package file at any time if the relevant keys are present. SignSIS supports the signing of SIS files with self-signed certificates or Developer certificates.

At the installation start-up, Software Install (SWI) provides the UI with the following information: name of the application about to be installed, its version, name of the vendor, and if present, signing certificate information.

Note that for the initial PlatSec release, multiple-signing-certificate-chains are managed in a nested hierarchical fashion where signers sign the SIS data plus all previous signatures. This implies that only the last signature can be removed from a SIS file.

During Software Installation (SWI) the SIS file is examined from the security perspective. A SIS file can be either signed or unsigned. If signed, it may or may not be possible to associate the package with a known trust anchor certificate on the device (achieved by validating the certificate chain). Additionally, the package may simply be self-signed as a means of better identifying the package. Note that a self-signed package, or a package chaining to an unknown trust anchor is essentially “unknown”.

In general, packages which can be associated with a trust anchor will be installed successfully. Those that are not are subject to licensee policy, which may mean that they are rejected.

Note that if the original package was signed, the update must also be signed.

If a SIS file is unsigned (or simply self-signed), it is identified as “unknown”. SWI checks policy settings to verify if installation of unknown packages is allowed at all. If the policy prohibits it, the installation ends with an error message. Note that if a target destination private import directory does not exist, the installation is aborted.

For signed SIS files, SWI performs signature validation and then validates all certificates the SIS file is signed with.

After all signatures have been verified, SWI starts certificate verification. The new SIS file format allows a SIS file to be signed using multiple certificates, while the old format allows only one signing certificate in a SIS file. For each end entity certificate in the SIS file SWI attempts to build the certificate chain to the corresponding trust-anchor certificate, which must reside in the device’s certificate store, be marked as trusted and suitable for code signing . The vendor name and package UID included in a certificate contained in a signed SIS package must be the same as the vendor name and package UID directly included in the SIS package.

If none of the SIS file certificates can be traced to a valid trust anchor certificate on the device, the package is considered as “unknown” and should be handled in the same way as unsigned SIS files).

For each certificate chain built from a SIS file’s end certificate, SWI performs an OCSP check (using OCSP support server) to verify the current status of the certificates in the chain. This can be either optional (user-configurable) or mandatory. The OCSP server URI is taken from the corresponding certificate (unless the certificate is a self-signed end-entity). If there is no OCSP server URI specified in a certificate, the default URI is used. To be able to perform the OCSP check, the OCSP Server (which sends OCSP requests and passes the response to SWI) has NetworkServices and LocalServices capabilities.

Since an OCSP check can take a significant amount of time, it may be interrupted by the user. If a go to OCSP policy is mandatory, and the user interrupts it, the installation is aborted immediately without any further messages.

Upon receiving a result of OCSP transaction, Software Install decides whether the certificate chain is valid or not. If there is only one chain built from the package file, and OCSP checking is mandatory, errors during OCSP check cause the package to be considered “unknown” and be handled in the same way as unsigned SIS files. The errors include an inability to obtain certificate information, transport failures, etc.. However, if for any certificate in all chains the OCSP status is “revoked”, the installation is aborted with a security error message.

SIS files can be signed by developers themselves, for programs that:

• do not use any APIs that are protected by capability checks, so do not need any platform security capabilities.

• only require platform security capabilities that belong to the group known as "user" or "basic" capabilities. If the software installer is asked to install a program with these capabilities, it can tell the user this, and query whether the installation should continue.

Also see Create and Self-sign a SIS file.

Some programs however require platform security capabilities that cannot be granted by the user. These programs must be tested externally, and signed with a certificate that the software installer recognises as coming from a trusted identity. This process is done through the Symbian Signed programme. Full details are at http://www.symbiansigned.com/; there is also a presentation on the Symbian developers’ web site: http://www.symbian.com/symbiansigned/. More detailed discussion of when you may or may not require a program to be Symbian Signed is available at the Implementing Platform Security for ISVs whitepaper on DevNet.

In order to test such applications on production phones, prior to the application being submitted to Symbian Signed, the SIS file must be signed with a special “development” certificate, which allows the application to be installed without having been through the external testing and signing process. These certificates are locked to the specific individual phones on which testing will take place (through the IMEI/ESN number). Development certificates are obtained through http://www.symbiansigned.com/.

If a certificate is marked as MANDATORY, then any package certificates being presented at software install time must have a certificate chain which resolves to this certificate (and any others also marked as MANDATORY). This feature allows some managing entity to install a mandatory software-install root certificate, and prevent any unauthorised applications (i.e. those not signed to this root) from being installed on the device. Unsigned or self-signed applications are no exception to this rule. If a MANDATORY certificate is present, these packages will not be installable.

• SignSIS - Installation File Signer syntax

• Package file format .pkg