There are four methods for authorizing code to run on a device:
- Digitally signing fully dynamic modules
- Including the static hash of dynamic modules in the boot image
- Including static (const) modules in the boot image
- Hard linking modules into the boot image
The last three methods (described more fully in the appendix) are applicable only to code that is finalized and available at the time of manufacture. Each of these three methods binds the code to the boot image of the device. For each of these methods, the device manufacture is responsible to determine the suitability and trustworthiness of the code through their own methods and criteria.
The first method, digital signing, enables loading dynamic code onto a device that is already deployed commercially. Using digital signing, a device manufacturer may also empower third parties, called signing authorities, to determine whether code is trusted to run on a device. This paper focuses exclusively on the capabilities, requirements, and specifications for implementing code authorization on Brew MP.
A signing authority is a legal entity that determines whether code can be trusted to run on a mobile device and assumes responsibility for the security of the code. Device manufacturers, mobile network operators, and other mobile services providers may be signing authorities, and each signing authority is responsible for setting their own criteria and methods for determining what code may be run on a device. A signing authority uses digital signatures to authorize code they deem trusted. A given device may be configured by the manufacturer to support multiple signing authorities.
Mobile network operators, device manufacturers, mobile service providers, and consumers depend upon signing authorities to practice or enforce a signing policy - the criteria under which they will authorize code to run on the device. A signing authority's policy can include standards such as:
- The type and degree of code testing they require
- The extent to which they authenticate application developers or publishers
- How they determine which services and data are allowed access to a given application
Some signing authorities authorize only code that their own organization produces, while others authorize code from a wide range of external sources. Those that sign only their own code (perhaps a device manufacturer) may rely on their internal development and testing processes for a signing policy. Signing authorities that authorize code from many external parties typically have a more conservative signing policy.
A certificate authority (CA) is a legal entity that determines which signing authorities are trusted by a given device. Certificate authorities are expert in the deployment of a Public Key Infrastructure (PKI) and the secure procedures to store and access private keys. Certificate authority enables signing authorities through the issuance of signing certificates, which give them the authority and the means to generate digital signatures for code according to the signing authority's signing policy.
Device manufacturers determine what certificate authorities (and therefore which signing authorities) are enabled on a device by installing and configuring a root certificate for one or more certificate authorities on a device at the time of manufacture. Multiple certificate authorities may be enabled on a device by including and configuring multiple root certificates.
Figure 1. Digital Signing Ecosystem -
- The certificate authority provides the device manufacturer with a root certificate.
- The device manufacturer immutably configures the root certificate into the device image.
- The certificate authority issues signing certificate(s) to the signing authority.
- Developers submit unsigned code to the signing authorities.
- The signing authority issues digital signatures for code that meets the criteria set forth in their signing policy.
The relationship between a device manufacturer and a signing or certificate authority is most often contractual in nature. Device manufacturers delegate trust to certificate authorities, who in turn delegate trust to signing authorities. The criteria for what parties and what code are trusted should be fully negotiated and understood before a root certificate is embedded in a commercial device.
As mentioned previously, a device manufacturer or mobile network operator may act in the role of a signing authority. For some code authorization business models, the signing authority and the certificate authority may be a single legal entity. As an example, a device manufacturer (or mobile network operator) may deploy and manage both a certificate management and a code signing operation. In such a scenario, the distinct activities of each function remain:
- Securely manage private root keys
- Provision device manufacturers with root certificates
- Issue signing certificates to signing authorities
- Determine whether code is trustworthy for execution on a device in accordance with their signing policy
- Authorize the code through digital signing