After
developing an application, it must somehow be distributed to end-users
in a manner that they can use. After all, you can’t distribute the
source code and expect users to know how to compile the source code into
the appropriate format for their phone. Further, simply providing
compiled binaries is also not enough. Where are they supposed to be
located on storage? How do users know that the applications they have
received have not been tampered with?
Applications for the
Symbian platform are compiled into a modified version of the ELF
executable format known as E32Image that supports Symbian specific
requirements. Since access to the local file system is restricted via
capabilities; installation of applications is managed by a privileged
process on the device. Applications are provided to end-users in an
archive format that provides instructions to this installation
gatekeeper on where to place the final applications.
Executable Image Format
Applications are compiled to the
ARM Embedded Application Binary Interface (EABI). Code compiled with
GCCE can link against code that is compiled with RVCT because they use
the same EABI. Applications are initially compiled and linked into ELF
executable format executables and are then transformed into the E32Image
format. The most important difference is the addition of a Symbian
platform–specific header. This header includes several key fields that
are used to make security decisions within executing applications:
UID3 A 32-bit value that uniquely identifies an application. It must be locally unique on the device and should be globally unique.
SecureID Another application-specific identifier, generally identical to UID3.
VendorID A globally unique value that identifies the developer of the image.
Capabilities A 64-bit field that identifies the capabilities the image requires.
UID3/SecureID are allocated
from within the same 32-bit range according to their purpose. This range
is split in half into protected and unprotected chunks. The lower half
(0x00000000–0x7FFFFFFF) is protected and an allocation must be requested
from Symbian Signed. This ensures that these values are globally
unique. Table 1
lists the various protected sub-ranges and their intended purpose. The
installation process validates that UID3 and SecureID are only used with
executables whose installation scripts were signed and that validate
against a trusted root. The installation also validates whether any
nonzero VendorIDs fall within the allocated range and that the
installation script is signed.
Table 1. Protected Range UIDs
| Value Range | Purpose |
|---|
| 0x00000000–0x0FFFFFFF | For legacy development use |
| 0x10000000–0x1FFFFFFF | Legacy (pre-9.x) UID allocations |
| 0x20000000–0x2FFFFFFF | 9.x protected UID allocations |
| 0x30000000–0x6FFFFFFF | Reserved for future use |
| 0x70000000–0x7FFFFFFF | Vendor ID allocations |
The upper half
(0x80000000–0xFFFFFFFF) is unprotected. The installation process does
not enforce that installation scripts containing executables with these
UIDs be signed. Developers should still obtain an allocation from within
this range in an effort to promote global uniqueness of the application
identifier. Use UIDs in the 0xAxxxxxxx range for unsigned applications
destined for distribution and UIDs in the range 0xExxxxxx for
development purposes. Table 2 lists the unprotected sub-ranges and their intended purpose.
Table 2. Unprotected Range UIDs
| Value Range | Purpose |
|---|
| 0x80000000–0x9FFFFFFF | Reserved for future use |
| 0xA0000000–0xAFFFFFFF | 9.x unprotected UID allocations |
| 0xB0000000–0xDFFFFFFF | Reserved for future use |
| 0xE0000000–0xEFFFFFFF | For development use |
| 0xF0000000–0xFFFFFFFF | Legacy UID compatibility |
To obtain a UID/SecureID allocation, follow these steps:
Register for and/or log into an account.
Click on the My Symbian Signed tab along the top.
Click on UIDs, and then click Request in the left sidebar.
Select either Protected Range or Unprotected Range.
Enter the required information and click Submit.
Installation Packages
Symbian applications are
distributed in SIS files—an archive-like file format that includes the
files for installation as well as a manifest-like file that specifies
where they should be placed on the filesystem. These packages support a
basic level of flow control to allow developers to create a single
installer that contains the binaries for different Symbian
versions/platforms.
All SIS files consist of a header
and a sequence of word-aligned Type-Length-Value (TLV) SISFields. This
allows for a parser to efficiently skip over unnecessary parts of the
file without wasting space by loading the entirety into the limited
memory available. The basic layout can be seen in Figure 1.
The header consists of three package UID (pUID) values and a UID
checksum. However, these should not be confused with the UID values
within the header of an executable image. The first pUID identifies the
package as an SIS file and will always be set to 0x10201A7A. The second
pUID is reserved for future use and is generally set to 0x00000000. The
third pUID uniquely identifies the installation package, allowing the
installer to identify package upgrades in the future. Attempting to
install another SIS file with the same pUID will fail. The rules
regarding the selection of an appropriate pUID are identical to those
surrounding the UID3 values found within executables. It is recommended
to use the UID3 of the principal application within the installation
script as the pUID.
Directly
after the header is an SISContents field that encompasses the rest of
the file. This acts a container for SISController and SISData fields
(and corresponding checksums). The SISController field includes all of
the metadata regarding the package, including the type of installation,
the language, and required dependencies. The SISData field is an array
of SISDataUnits, each of which is an array of SISFileData fields, the
actual files to be copied onto the device. SISData fields consist of
multiple SISDataUnits to allow for embedding package dependencies within
a single installation file. This can be seen in Figure 2.
The SISController field from the child package is embedded within the
SISController field of the parent. The SISDataUnit field(s) from the
child package are added to the SISData field of the parent. A child SIS
file may itself have another SIS nested within it. The nesting of these
packages is limited to a depth of eight.
Signatures
SymbianOS
executable images do not contain signatures. Instead, SIS installation
scripts can contain a signature block. When signed, installation scripts
generally have an .sisx file extension. This means that signatures are
validated at installation time, not at runtime. Were an executable to be
modified on the device by a highly capable process after installation,
it would remain undetected. Because all executables must be loaded from
the restricted install directory, very few applications have the
capabilities required to modify installed executables.
An SIS
file can have multiple signatures, allowing for applications that
require manufacturer approval to be signed by multiple roots. The
signature field is nested within the SISController field. The signature
covers every field within the SISController field except for the
SISDataIndex field at the end. This includes previous signatures. This
can be seen in Figure 3. The SISDataIndex field is not included because it is modified whenever an SIS file is embedded within another one.
At first glance, this does
not appear to preclude modification of the SISData field. After all, the
signature only covers the SISController field. However, within the
SISController field is the SISInstallBlock field consisting of an array
of SISFileDescription fields. These SISFileDescription entries include
an SHA-1 hash of the contents of the corresponding files within the
SISData block. Attempts to manipulate the files directly will invalidate
this hash, and manipulating this hash invalidates the digital
signature.
Signatures can be
created from arbitrary certificate/private key pairs, including
self-signed. However, the capabilities available to an SIS installation
package will be limited to the extent that the signatures validate to a
set of trusted roots. Different trust roots can certify different
capabilities. In this fashion, it may be necessary to have multiple
signatures to have access to all of the capabilities requested.
Symbian Signed
Symbian Signed is an
umbrella process for properly signing application installers during
development and for release. In order to make this work, the Symbian
Signed root certificate is preinstalled onto SymbianOS-based devices by
the device manufacturer. The device manufacturer will also generally
provide its root
certificate. The use of Symbian Signed is not required of manufacturers
taking advantage of the SymbianOS platform; however, most do in order
to take advantage of the ecosystem of signed applications.
The Symbian Signed program can
be developed into four main categories: OpenSigned Online, Open Signed
Offline, Express Signed, and Certified Signed. Each of the categories
enforces different requirements to obtain a signature and impose
different limitations on their use.
Open Signed Online is the
first tier of Symbian Signed. Anyone can get their application signed by
providing an International Mobile Equipment Identity (IMEI) number, an
e-mail address, and the SIS installation package. Open Signed Online can
be used to grant any User and System capabilities. This will be signed
by a developer certificate. Upon installation, the user is informed that
the application was signed by a developer certificate and asked whether
they would like to continue. Further, the package that it is being
installed on the phone specified will be validated based on the IMEI
number provided during signing.
Open Signed Offline
provides a developer certificate that can be used to sign multiple SIS
installation files that can generally be used on up to 1,000 devices by
IMEI number. This certificate can be used to grant any User and System
capabilities, although installation will still be confirmed by the end
user due to the use of a developer certificate. Obtaining this
certificate requires one to have a Symbian Signed account as well as to
have purchased a valid Publisher ID. A special Open Signed Offline
certificate can be requested that also grants restricted and
manufacturer capabilities by sending the request to the device
manufacturer. Installers signed by this certificate can only be used on a
phone with an IMEI number that matches one of the 1,000 recorded
numbers.
Express Signed is the first
tier intended for end-user release. Installation packages signed through
the Express Signed program are valid for ten years and can be installed
onto any device. Express Signed applications can use both User- and
System-level capabilities. Applications must meet the Symbian Signed
Test Criteria, although independent testing house validation is not
required. All Express Signed applications may be audited to ensure that
they meet these criteria. In order to participate in the Express Signed
process, one needs a Symbian Signed account, a valid Publisher ID, and
the purchase of one Content ID per application submission.
Certified Signed is the final
tier intended for end-user release. Installation packages signed at
this level have full access to User, System, and Restricted
capabilities. Applications can petition for access to Manufacturer
capabilities. Certified Signed applications must meet the test criteria,
as confirmed through independent testing. At
this level, one needs a Symbian Signed account, a valid Publisher ID,
the purchase of a Content ID, as well as a paid independent validation.
Installation
Application packages can
be installed onto SymbianOS devices through several vectors—namely MMS,
Bluetooth, HTTP/S, IRdA, and USB tethering. No matter the route, all
installation is handled through the SWInstall process. SWInstall acts as
the gatekeeper for a SymbianOS device. It has sufficient capabilities
to access the necessary file system paths. It validates all installation
packages to ensure that they meet the signing requirements for the
requested capabilities, that the binaries within the package have not
been modified, and that the installer is not overwriting an existing
application.
Validation occurs in several
steps: To begin, SWInstall identifies the files to be installed
(remembering that a single installation package can include binaries for
multiple platforms). Then it enumerates the capabilities requested by
the listed executable images (DLLs and EXEs). SWInstall proceeds to
chain the signatures on the SIS file back to trusted SymbianOS
code-signing CAs—generally Symbian Signed or a device manufacturer. Each
CA may only certify particular capabilities. If the set of requested
capabilities is not a subset of the certifiable capabilities, then one
of two things occurs. If the requested capabilities are system level or
higher, the installation will fail. If the requested capabilities are
user level, the device owner will be asked whether installation should
continue. SWInstall also ensures that the SID is unique on the phone,
that installers with protected range SIDs are appropriately signed, and
that a Vendor ID is only specified with signed applications.
After validation, SWInstall
copies the contained resources to the required destinations. Binaries
are placed in \sys\bin, resources are written to \resource, and the
associated private directories are determined from an applications SID.
The installer will also write files into the import directory of another
executable (\private\<SID>\import) to allow for delivering data
to other applications. Installing into this import directory must happen
at installation; most applications will not have the necessary
capabilities to write to this directory.
When applications are
installed to removable media, the SWInstall process will record the
SHA-1 hash of the binaries to a private location on internal media. This
prevents an individual from installing an application, removing the
media, and modifying the binary to increase capabilities. Remember that
capabilities are only checked against the signature at install time.
