Application Suites Trust Model Using X.509 PKI

Introduction

The application suite is protected by signing the JAR. The mechanisms defined in this chapter allow signing and authentication of application suites based on X.509 Public Key Infrastructure, so that a device can verify the signer and trust an application suite.

This is only one possible mechanism how implementations MAY recognize application suites to be trusted (and the one of choice if backward compatibility with IMP-NG is required). Other, not PKI based mechanisms can be implemented instead, but their definition is out of scope of this specification.

The signatures and certificates are added to the application descriptor as attributes. The device uses them to verify certificate chains and the signatures to determine whether the application suite is trusted and can be bound to a protection domain that will authorize the application suite to perform protected functions by granting permissions allowed in a given protection domain.

The security model involves the application suite, a signer, and certificates. As with any public key system, authentication is based on a set of Root Certificates which are used to verify other certificates. Zero or more Root Certificates will need to be on the device. Additionally, Root Certificates may be present in removable media such as a SIM(WIM) card/USIM module. Implementations MUST support X.509 Certificates and corresponding algorithms. Devices MAY support additional signing mechanisms and certificate formats.

Transport & Security Standards

Implementations are expected to operate using standard Internet and wireless protocols and techniques for transport and security. The mechanisms for securing Internet content are based on existing public key cryptography standards, including [RFC2437], [RFC3280], [RFC2560], and [WAPCert].

Definition of Terms

The terms Trusted application suite, Permission, and Protection Domain are defined by Security for Applications. Table 7-1 below defines additional terms.

Table 7-1 : Definition Of PKI Security Terms

Term

Definition

Root Certificate

The general term used in the context that does not specifically address Protection Domain Authorization

Protection Domain Root Certificate

Root Certificate associated with a protection domain that the device implicitly trusts to verify and authorize downloaded application suites

Application Access Root Certificate

Root Certificate that device implicitly trust to verify downloaded application suites. Application Access Root Certificate is often the same certificate as Protection Domain Root Certificate

The device manufacturer and operator decide which of the root certificates used for verifying the signing certificate can be used for domain authorization. Domain authorization does not impose any special requirements upon root certificates other than being able to participate in the verification procedure described in Verifying Signing Certificate.

Signing an Application Suite

The signer of the application suite may be the developer or some entity that may be responsible for distributing, supporting, or billing for its use. The signer will need to have a certificate that can be validated against one of the Root Certificates found on the device or smart card. The public key is used to verify the signature on the application suite. The public key is provided as a RSA X.509 certificate included in the application descriptor.

There can be more than one signer, but the support of multiple signers is optional in MEEP-1.0.

It should be noted that the signer of the application suite is responsible to its Root Certificate owner for protecting the protection domain or any other stake holder's assets and capabilities and, as such, must exercise due-diligence in checking the application suite before signing it. In the case where there is a trusted relationship (possibly bound by legal agreements), Root Certificate owner may delegate signing application suites to a third-party and in some circumstances, the author of the application.

Attributes defined within the manifest of the JAR are protected by the signature. Attributes defined within the application descriptor are not secured. When an attribute appears both in the manifest and in the application descriptor, the value in the application descriptor MUST be equal to the value of the corresponding attribute in the manifest. If not, the application suite MUST NOT be installed.

Creating the Signing Certificate

  1. The signer will need to be aware of the authorization policy for the device and contact the appropriate certificate authority. For example, the signer may need to send its distinguished name (DN) and public key (normally, packaged in a certificate request) to a certificate authority.
  2. The Certification Authority (CA) creates a RSA X.509 (version 3) certificate and returns it to the signer.

Inserting Certificates into the Application Descriptor

  1. The certificate chain MUST include the certificate of the signer and any additional intermediate certificate but MUST NOT include the Root Certificate. The Root Certificate is expected to be found on the device.
  2. Each certificate in the path MUST be encoded using Base64 encoding and MUST NOT include line breaks. It is inserted into the application descriptor as:

    MIDlet-Certificate-<n>-<m>: <Base64 encoding of a certificate, without line breaks>


    <n> := a number equal to 1 for the first certificate chain in the descriptor and incremented by 1 for each additional certificate chain. The lowest value of <n> MUST be 1 and consecutive ordinals MUST be used. The first missing entry terminates the list. Any additional entry MUST be ignored. These numbers defines the order in which the certificate chains are tested; see the Authenticating an Application Suite section below.
    <m> := a number equal to 1 for the signing certificate in the certificate chain and incremented by 1 for each additional intermediate certificate. For each <n>, the lowest value of <m> MUST be 1 and consecutive ordinals MUST be used. The first missing entry terminates the list. Any additional entry MUST be ignored.

Creating the RSA SHA-1 signature of the JAR

  1. The signature of the JAR MUST be created with the signer's private key using the EMSA-PKCS1-v1_5 encoding method of the PKCS#1 version 2.0 standard [RFC2437].
  2. The signature MUST be Base64 encoded, and MUST NOT include line breaks. It is inserted in the application descriptor as:

    MIDlet-Jar-RSA-SHA1-<n>: <Base64 encoding of Jar signature>

    <n> := a number equals to 1 for the first signature and incremented by 1 for each additional signature. This number corresponds to the number <n> in MIDlet-Certificate-<n>-<m> attributes. The lowest value of <n> MUST be 1 and consecutive ordinals MUST be used. The first missing entry terminates the list. Any additional entry MUST be ignored.

If the number of certificate chains is not equal to the number of signature attributes, installation MUST NOT proceed. The Status Code 906 (Invalid Descriptor) must be returned in the status report.

Authenticating an Application Suite

When an application suite is downloaded, the device MUST check if authentication is required. If the attribute MIDlet-Jar-RSA-SHA1-<n> is present in the application descriptor then the JAR MUST be authenticated by verifying the signing certificates and JAR signature as below.

Application descriptors without the MIDlet-Jar-RSA-SHA1-<n> attribute are not authenticated but are installed and invoked as untrusted application suites.

Verifying Signing Certificate

The certificate chain consists of the signing certificate from the application descriptor and other certificates as needed up to but not including the Root Certificate.

  1. Get the certificate chain for the signing certificate from the Application Attributes MIDlet-Certificate-1-<m> where <m> starts at 1 and is incremented by 1 until there is no attribute with the given name. The value of each attribute is a Base64 encoded certificate that will need to be decoded and parsed.
  2. Validate the certificate chain using the basic path validation processes described in [RFC3280] using available Root Certificates. 
  3. If attributes MIDlet-Certificate-<n>-<m> with <n> greater than 1 are present, repeatedly perform steps 1 and 2 for the value <n> greater by 1 than the previous value. The results of certificate verification are gathered into Table 7-2 below.

Table 7-2 : Actions Upon Completion of Signing Certificate Verification

Result

Action

Attempted to validate <n> certificate chains. No public keys of the issuer for the certificate can be found or none of the certificate chains can be validated Authentication fails, JAR Installation is not allowed
More than one full certificate chain established and validated Implementation proceeds with the signature verification using all successfully verified certificate chains. Certificate chains for which Root Certificate is not found are discarded
Only one full certificate chain established and validated Implementation proceeds with the signature verification

Verifying the Application Suite JAR

  1. Get the public key from the verified signing certificate (above).
  2. Get the MIDlet-Jar-RSA-SHA1-<n> attribute from the application descriptor.
  3. Decode the attribute value from Base64 yielding a PKCS #1 signature [RFC2437].
  4. Use the signer's public key, signature, and SHA-1 digest of the JAR, to verify the signature. If the signature verification fails, reject the corresponding certificate chain.
  5. Repeat the above steps for each MIDlet-Jar-RSA-SHA1-<n> attribute

Once the steps of verifying the certificate, verifying the signature and verifying the JAR all succeed then the application suite contents are known to be intact and the identity of the signer is known. This process must be performed during installation.

Summary of Application Suite Source Verification Results

It is essential that the steps performed to verify the digital signature as described above lead to the proof of the identity of the application suite signer. The results of the verification have a direct impact on authorization. Table 7-3 below summarizes the states to which the signature verification led and which are further used for authorization at install time.

Table 7-3 : Summary of Application Suite Source Verification

Initial state

Verification result

JAD not present, JAR downloaded Authentication can not be performed, may install JAR. Application suite is treated as untrusted
JAD present but JAR is unsigned Authentication can not be performed, may install JAR. Application suite is treated as untrusted
One or more signature attributes appear in the JAD, but no Root Certificate present in the keystore to validate the certificate chain Authentication can not be performed, may install JAR. Application suite is treated as untrusted
One or more signature attributes appear in the JAD and Root Certificates present in the keystore to validate the certificate chain but none of Root certificates is Protection Domain Root certificate Authentication can be performed, authorization can not be performed, may install JAR. Application suite is treated as untrusted
One or more signature attributes appear in the JAD, a certificate on one or more certificate chains is expired Certificate chain with expired certificates is discarded. If all certificate chains are discarded, JAD is rejected and JAR installation is not allowed, Status Code 909 (Application authentication failure) returned in the Status Report
One or more signature attributes in the JAD, any certificate rejected for reasons other than expiration Certificate chains with rejected certificates is discarded. If all certificate chains are discarded, JAD is rejected and JAR installation is not allowed, Status Code 909 (Application authentication failure) returned in the Status Report
One or more signature attributes in the JAD, for validated certificate chains signature verification fails Validated certificate chains for which signature verification fails is discarded. If for all validated certificate chains signature verification fails, JAD is rejected and JAR installation is not allowed, Status Code 910 (Application authorization failure returned in the Status Report
One or more signature attributes in the JAD, at least one certificate chains validated against protection Domain Root Certificate, signature for this certificate chain is verified JAR installation is allowed, can proceed with authorization.

Caching of Authentication and Authorization Results

The implementation of the authentication and authorization process may store and transfer the results for subsequent use and MUST ensure that the cached information practically can not be tampered with or otherwise compromised between the time it is computed from the JAR, application descriptor, and authentication information and the authorization information is used.

It is essential that the application suite and security information used to authenticate and authorize an application suite is not compromised, for example, by use of removable media or other access to application suite storage that might be corrupted.

Security of Alternative Application Representation Formats

In environments that make use of alternate application representation formats (see CLDC, §5.3.4), it is possible to implement the security mechanism using JARs but this relies on converting the JAR to the device format when the JAR enters the network while faithfully preserving the semantics of the application. Once the conversion has happened, the device format of the application must be secured against tampering and retain its authorized permissions. This network security is often based on similar digital signature techniques to application security and it may be the case that this network security infrastructure is already present and active. If and only if this kind of network security infrastructure already exists and it can support all forms of protection required by this specification (and any future JSRs based on this specification), a permissible implementation of application suite security can be based on authenticating and authorizing the device format of the application since these implementation formats are the actual executable content that will be used on the device. The details of authenticating and authorizing a device format version of an application suite are implementation specific and thus not covered by this specification.

MIDP X.509 Certificate Profile for Trusted Application Suites

Secured trusted application suites utilize the same base certificate profile as does HTTPS. The profile is based on the WAP Certificate Profile, WAP-211-WAPCert-20010522-a [WAPCert] which is based on [RFC3280] Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

Certificate Processing for Provisioning

If provisioning is supported, devices MUST recognize the key usage extension and when present verify that the extension has the digitalSignature bit set. Devices MUST recognize the critical extended key usage extension and when present verify that the extension contains the id-kp-codeSigning object identifier (see [RFC3280] § 4.2.1.13).

The application descriptor SHOULD NOT include Root Certificate in a descriptor certificate chain. Root Certificate found in the application descriptor MUST be discarded.

Certificate Expiration and Revocation

Expiration and revocation of certificates supplied in the application descriptor is checked during the authorization procedure, specifically during certificate chain validation. Certificate expiration is checked locally on the device as such information is retrievable from the certificate itself. Certificate expiration verification is an intrinsic and mandatory part of certificate chain validation.

Certificate revocation is a more complex check as it requires sending a request to a server and the decision is made based on the received response. Certificate revocation can be performed if the appropriate mechanism is implemented on the device.

Scenarios of Application Suite Signing

Scenario 1a

The application suite is signed once, and the developer owns the signing certificate :

  1. Developer creates an application suite and creates JAR and JAD
  2. Developer generates a private-public key pair and obtains a signing certificate from Certification Authority
  3. The developer's certificate is used to sign the application JAR and create the associated JAD entries
  4. Application suite is ready for distribution and can run on any ME 8 compliant device that can verify signing certificate used in this scenario against an appropriate Protection Domain Root Certificate

Scenario 1b

The application suite is signed once, but the developer does not own the signing certificate :

  1. Developer creates an application suite and creates JAR and JAD
  2. Developer passes his application suite to a Test House for testing and signing. Signed application suite is returned back to developer. Alternatively developer passes his application suite to a Distribution Authority that would sign and prepare application suite ready for distribution
  3. Application suite is ready for distribution and can run on any ME 8 compliant device that can verify signing certificate used in this scenario against an appropriate Protection Domain Root Certificate

Scenario 2

The application suite is signed multiple times, and the developer may or may not own all of the signing certificates :

  1. Developer creates an application suite and creates JAR and JAD
  2. Developer generates one or more private-public key pair and obtains one or more signing certificate from Certification Authorities
  3. One or more of developer's certificates are used to sign the application JAR and create the associated JAD entries
  4. Developer may pass his application suite to a Test House for testing and signing. Signed application suite is returned back to developer. This and the previous step may be performed in reverse order
  5. Application suite is ready for distribution and can run on any ME 8 compliant device that can verify signing certificates used in this scenario against appropriate Protection Domain Root Certificates
  6. In addition to or instead of the previous step, developer may pass his application suite to a Distribution Authority that would sign and prepare application suite ready for distribution
  7. With this scenario the entity that is the last one to sign the application suite and/or is responsible for application suite distribution must perform an extra step of evaluating all signing certificates that appear in application suite JAD and rendering certificate chains so that the one potentially leading to least restrictive protection domain will be verified first. E.g. if application suite was signed with signing certificates issued by independent Certification Authorities and later signed with operator signing certificate, numbering of certificate chains should be altered so that operator certificate chain is the first one to be verified

Scenario 3

The application suite is signed one or more times, and the application suite is dependent on one or more LIBlets :

  1. Developer creates an application suite that depends on one or more LIBlets
  2. Developer does due diligence in testing his application with LIBlets as well as verifies all dependency LIBlets for the presence of mandatory attributes
  3. Developer creates application suite JAR and JAD and includes all required attributes specific to his application suite
  4. Developer selects one of the procedures outlined in the previous scenarios to get his application suite signed
  5. Application suite is ready for distribution and can run on any compliant device that can verify signing certificate used in this scenario against an appropriate Protection Domain Root Certificate