Default Security Authentication Provider: Application Suites Trust Model Using X.509 PKI

Introduction

This chapter describes one possible implementation of the Authentication Provider concept that MEEP 8 implementations MAY use to 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. This chapter provides information and rules valid for this MIDP 3.0 like authentication provider only. General rules for Authentication Providers as defined in the Authentication Provider chapter apply as well.

An 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.

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 assigned to a Client that will authorize the application suite to perform protected functions by granting permissions allowed in the policy defined in the Security Protection Domain associated with this Client.

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 of this kind of authentication provider 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, Security Protection Domain and Client are defined by Security for Applications. Table 7-1 below defines additional terms.

Clients have to decide which of the root certificates used for verifying the signing certificate can be used for their authorization. Client 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 an 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.

It should be noted that the Client of the application suite is responsible to its Root Certificate owner for protecting his 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 this rule is violated, for the application suite itself, or for one of the LIBlets the application suite depends upon, 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.

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-4 below summarizes the states to which the signature verification led and which are further used for authorization at install time. General states not being specific to this particular kind of an Authorization Provider, being defined in this table apply as well.

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

An 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 Client 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 Client 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 Client 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 Client's policy 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 Client Root Certificate.

Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.