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.
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].
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 |
The general term used in the context that does not specifically address Protection Domain Authorization |
|
Root Certificate associated with a protection domain that the device implicitly trusts to verify and authorize downloaded application suites |
|
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.
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.
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.
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.
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.
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.
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.
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 |
MIDlet-Jar-RSA-SHA1-<n>
attribute from the application descriptor.
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.
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. |
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.
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.
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.
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.
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.
The application suite is signed once, and the developer owns the signing certificate :
The application suite is signed once, but the developer does not own the signing certificate :
The application suite is signed multiple times, and the developer may or may not own all of the signing certificates :
The application suite is signed one or more times, and the application suite is dependent on one or more LIBlets :