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.
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, Security Protection Domain and Client 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 Client Authorization. |
|
Root Certificate associated with a Client that the device implicitly trusts to verify and authorize downloaded application suites. |
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.
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.
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-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.
Table 7-4 : Summary of PKI-based Application Suite Source Verification |
|
---|---|
Initial state |
Verification result |
JAD not present, JAR downloaded | Authentication cannot be performed. Installation of the JAR MUST fail in this case. For installation of a LIBlet as part of the installation of an application suite, if the application suite is trusted, the provisioning algorithm MUST NOT install the LIBlet in this case and the installation of the application suite MUST fail as well. |
JAD present but JAR is unsigned | Authentication cannot be performed. Installation of the JAR MUST fail in this case. For installation of a LIBlet as part of the installation of an application suite, if the application suite is trusted, the provisioning algorithm MUST NOT install the LIBlet in this case and the installation of the application suite MUST fail as well. |
One or more signature attributes appear in the JAD, but no Root Certificate present in the keystore to validate the certificate chain | Authentication cannot be performed. Installation of the JAR MUST fail in this case. For installation of a LIBlet as part of the installation of an application suite, if the application suite is trusted, the provisioning algorithm MUST NOT install the LIBlet in this case and the installation of the application suite MUST fail as well. |
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 Client Root certificate | Authentication can be performed, authorization cannot be performed. Installation of the JAR MUST fail in this case. For installation of a LIBlet as part of the installation of an application suite, if the application suite is trusted, the provisioning algorithm MUST NOT install the LIBlet in this case and the installation of the application suite MUST fail as well. |
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 Client Root Certificate, signature for this certificate chain is verified | JAR installation is allowed, can proceed with authorization. |
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.
An 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:
Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.