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

Installation files can be signed using the installation file signer, SignSIS. The certificate and private key are specified as command line arguments. This documentation provides an overview of the signing process.

The diagram below provides an overview of how SignSIS is used.

Developers can create installation packages using MakeSIS, and sign them using SignSIS. Note that the CreateSIS tool, which is a wrapper around MakeSIS and SignSIS, is more commonly used.

MakeSIS generates a software installation (SIS) file from an input package (PKG) file. A PKG file is a text file describing the files and components delivered into the package. Package signing 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 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 entity. This process is done through the Symbian Signed programme. Full details are at http://www.symbiansigned.com/. More details about when you may or may not require software to be Symbian Signed is available in the Implementing Platform Security for ISVs white paper on the Symbian Developer Network.

In order to test applications on production phones, prior to the application being submitted to Symbian Signed, the SIS file can be signed with a special 'developer certificate', which allows the application to be installed without having been through the external testing and signing process. Developer certificates are obtained through http://www.symbiansigned.com/.

Developer certificates are subject to various constraints. These can include:

• being restricted to one or more listed phones (through the IMEI/ESN number)

• a date range, after which the certificate will expire

• an agreed set of capabilities that the certificate can grant

• the set of SIDs of executables that can be installed by the SIS file. If the SIS file's package UID is in the protected range, then it too must be included in the list of UIDs in the certificate.

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