This chapter sketches the cornerstones of a Security Policy architecture for implementations of utilizing wireless data technologies such as GSM, UMTS, CDMA, WiMAX etc.
While all implementations of the Security Policy MUST follow the security framework specified in Security for Applications, the details described in this chapter are mainly targeting a PKI-based scheme as defined in Application Suites Trust Model Using X.509 PKI. This is only one possibility though (and the one of choice if backward compatibility to IMP-NG is required). A MEEP-1.0 implementation can also decide not to require any authentication at all (in this case all application suites are always trusted and gain full access to any available functionality; a security policy is not needed in this case). Implementations are also free to implement an alternative scheme like authentication via a back-end mechanism or via a mutually trusted network connection. The definition of such schemes is outside the scope of this specification.
Security for Applications defines the framework for authenticating the source of an application suite and authorizing an application suite to perform protected functions by granting permissions it may have requested, based on the security policy on the device. It also identifies functions that are deemed security vulnerable and defines permissions for those protected functions. Additionally, it specifies the common rules for APIs that can be used together with this specification but are defined in other specifications. This chapter defines extensions to the base application suite security framework in the following areas :
A protection domain is a set of permissions that can be granted to
an application. The representation of a protection domain and its
security policy is implementation specific. An application suite MUST
belong to one and only one protection domain. An application suite is
bound to a Protection Domain based on its signature. Application suites
that are unsigned as per the
ME 8 Security Framework MUST be bound to the Unidentified Third Party
Protection Domain. If a signed application suite cannot be identified,
that application suite is bound to the Unidentified Third Party Protection
Domain. If the PKI based mechanism is used, this applies if none of its
associated certificate chains verify against a
Protection Domain
Root Certificate.
If application suites can be identified via more than one way, it depends
on the definition of the authentication mechanism, to which domain the
application suite is bound. If for example the PKI based authentication
mechanism is implemented, for application suites that have more than one
certificate chain found in the JAD, it may be possible that more than one
certificate chain verifies against a
Protection Domain Root Certificate.
In such a case, the certificate chain with the smallest value <n>
in the MIDlet-Certificate-<n>-<m>
attribute
determines the domain to which the application suite is bound.
Each LIBlet that is a dependency of an application is associated with the protection domain of the application and is also authenticated by the authentication mechanism of the application. If the PKI based mechanism as defined in Application Suites Trust Model Using X.509 PKI section is used, then the set of certificates that authenticate a LIBlet is the union of the certificates that authenticate the applications that depend on the LIBlet. The set of domains and certificates are used during provisioning (if supported) to determine which LIBlets may be bound as a Service then. See the provisioning step for resolving service dependencies.
This chapter defines the following protection domains:
Definition of additional protection domains, beyond Manufacturer, Operator, Identified Third Party and Unidentified Third Party Protection Domains, is allowed by this specification. The policy for additional protection domains is outside the scope of this specification. Additional protection domains intended to meet Network Operator requirements are referred to as Operator Supplementary Protection Domains.
The assignment of an application suite to a protection domain has to be handled as follows:
For a PKI based authentication mechanism this means, that for any X.509 Certificate under which an application is signed, the device MUST decide whether the certificate is issued under the certification hierarchy that leads to a Protection Domain Root Certificate.
Applications bound to the Unidentified Third Party Protection Domain and the Identified Third Party Protection Domain run in an unprivileged environment wherein the policy decides on the permissions given to the application. In contrast to this, applications in the Operator Protection Domain and the Manufacturer Protection Domain run in a privileged environment. However, the privileges given to an application might still depend on the specific Protection Domain to which the application is bound.
The following sections describe how Manufacturer and Operator Protection Domains have to be handled if the PKI based authentication mechanism as defined in the Application Suites Trust Model Using X.509 PKI section is used. Other mechanisms have to define the handling of those domains outside of this specification.
The Manufacturer Protection Domain Root Certificate is used to verify manufacturer application suites and MUST be mapped onto the security policy for the Manufacturer Protection Domain on the device. A device MUST support the security policy for the Manufacturer Protection Domain.
If the Manufacturer Protection Domain Root Certificate is NOT available on the device, the Manufacturer Protection Domain MUST be disabled.
The Manufacturer Protection Domain Root Certificate can be added, deleted or modified only by the manufacturer, who may use an update mechanism whose details are outside the scope of this specification. Any new or updated Manufacturer Protection Domain Root Certificate MUST be associated with the security policy for the Manufacturer Protection Domain on the device. Application suites verified by a previous Manufacturer Protection Domain Root Certificate MUST be disabled.
The Manufacturer Protection Domain imposes no restriction on the capabilities of this specification and other JSRs.
The following OID identifies Manufacturer Protection Domain Root Certificate:
ASN.1 : {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42) products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)manufacturer(2)} URN : urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.2 |
An Operator Protection Domain Root Certificate is used to verify operator application suites and MUST be mapped onto the security policy for the Operator Protection Domain on the device. Operator Supplementary Protection Domain Root Certificates MUST be mapped onto the designated policy, or in its absence they MUST be mapped onto the Operator Protection Domain. The following rules apply equally to the Supplementary Protection Domains as well.
A device MUST support the security policy for the Operator Protection Domain.
A device MUST support the mechanism [SCPROV] to read Root Certificates stored in the smart card (for example, SIM, USIM or WIM).
Additionally, the device MUST support Operator Protection Domain Root Certificates stored on the device.
There is at a maximum one Operator Protection Domain Root Certificates available at either of two specified locations: the smart card or on the device. For example there may be up to one enabled Operator Protection Domain Root Certificate per smart card and up to one enabled device resident Operator Protection Domain Root Certificate. There is more than one Operator Protection Domain Root Certificate if Operator Supplementary Protection Domain Root Certificates are mapped onto the Operator Protection Domain.
However, if Operator Protection Domain Root Certificates are found on the device and on the smart card (e.g. SIM, USIM or WIM) at the same time, the root certificate found on the smart card will have a higher priority than a device resident root certificate. Therefore, it is recommended for an operator to put the same root certificate on its smart cards as root certificates which were previously put on its devices (if that's the case for a progressive introduction of root certificates on the SIM card for example). In this way the operator ensures that existing applications will continue to be able to execute when introducing the smart card which contains the root certificate.
If an Operator Protection Domain Root Certificate is NOT available at the specified location in either the smart card or on the device the Operator Protection Domain MUST be disabled.
Potential consequences of a change of the smart card are described in Application Download and Execution While Roaming and After Changing the Smart Card.
Application suite execution in the Operator Protection Domain may be limited by the MIDlet-Operator-Allowed attribute. If this Application Attribute is present, the implementation MUST search for a tuple that matches the MCC-MNC portion of IMSI fetched from the currently inserted SIM against those listed in the attribute. If no match is found, applications from the application suite MUST NOT be launched. The check MUST be performed before execution of any application in the suite. If this attribute is not present, the implementation MUST NOT limit Operator Protection Domain application execution based on network.
The Operator Protection Domain Root Certificate MUST only be deleted or modified by the operator, who may use an update mechanism whose details are outside the scope of this specification.
Any new or updated Operator Protection Domain Root Certificate MUST be associated with the security policy for the Operator Protection Domain on the device.
Application suites verified by a non valid (for example, disabled) Operator Protection Domain Root Certificate MUST be disabled.
Before invoking an application the device MUST check whether or not the Protection Domain Root Certificate is still valid. If the Protection Domain Root Certificate that verified the application is no longer valid then the application MUST NOT be invoked.
Only if the Operator Protection Domain Root Certificate is valid during the installation process the device MUST continue the installation process. If this condition is not met, the device MUST NOT install the application and MUST respond as described in Provisioning, by sending the appropriate error code.
Root Certificates may be placed in the trustedCertificates Certificate Directory File (CDF) of a WIM, SIM, or USIM or on the device. If Root Certificates are stored directly on a SIM or USIM, that is, not under the WIM application, then they shall be stored in the EF trustedCertificates CDF located under DF ( [PKCS#15]), as defined by [SCPROV]. Root Certificates can be obtained only from the trusted CDF (the card holder can not update this directory) and not from any other directory of the smart card. Root Certificates found in the trustedCertificates file are considered to be Operator Protection Domain, Supplementary Operator Protection Domain 1 to 3 or Identified Third Party Protection Domain Root Certificates, depending on the trustedUsage field in the CommonCertificateAttributes associated with the certificate [PKCS#15] :
If the trustedUsage field is present and contains the following OID for key usage, then the certificate is to be considered an Operator Protection Domain Root Certificate:
ASN.1 : {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42) products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operator(1)} URN : urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.1 |
If the trustedUsage field is present and contains the following OID for key usage, then the certificate is to be considered Protection Domain Root Certificate of a Supplementary Operator Protection Domain 1:
ASN.1 : {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42) products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operatorSupplementary(4)} URN : urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.4 |
If the trustedUsage field is present and contains the following OID for key usage, then the certificate is to be considered Protection Domain Root Certificate of a Supplementary Operator Protection Domain 2:
ASN.1 : {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42) products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operatorSupplementary(5)} URN : urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.5 |
If the trustedUsage field is present and contains the following OID for key usage, then the certificate is to be considered Protection Domain Root Certificate of a Supplementary Operator Protection Domain 3.
ASN.1 : {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42) products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)operatorSupplementary(6)} URN : urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.6 |
If the trustedUsage field contains the following OID, then the certificate is to be considered an Identified Third Party Protection Domain Root Certificate. See Identified Third Party Protection Domain
ASN.1 : {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42) products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)identifiedParty(3)} URN : urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.3 |
Figure 8-1 below summarizes the process of assigning Root Certificates obtained through [SCPROV] to Protection Domains.
Application suites installed in the Operator Protection Domain MUST store, along with the application itself, a hash of the Protection Domain Root Certificate under which the certificate used to sign the application was issued. The hash algorithm to be used is the following: starting with the Protection Domain Root Certificate, compute the 20-byte SHA-1 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits) of that certificate. This method is commonly used to compute key identifiers, especially to accelerate trust chain building ([RFC3280] §4.2.1.2). The implementation MUST NOT assume for optimization purposes that X.509 key identifiers or [PKCS#15] labels have the correct value and MUST compute the hash themselves. In the event of a smart card change this hash MUST be used by the device to decide when a given application suite should be disabled.
Figure 8-1 : Assigning Root Certificates to Operator & Identified Third Party Protection Domains |
---|
![]() |
Differences between the two Third Party Protection Domains are :
The following section describes how Third Party Protection Domains can be identified if the PKI based authentication mechanism as defined in the Application Suites Trust Model Using X.509 PKI section is used. Other mechanisms have to define the identification of those domains outside of this specification.
Applications that are authenticated using an Identified Third Party Protection Domain Root Certificate are mapped to the Identified Third Party Protection Domain. There is no explicit limitation on the number of Identified Third Party Protection Domain Root Certificates available either on the device or at the specified location in the smart card.
All Identified Third Party Protection Domain Root Certificates MUST be mapped onto the security policy for the Identified Third Party Protection Domain on the device. A device MUST implement the Identified Third Party Protection Domain. However, if there are no Identified Third Party Protection Domain Root Certificates available either on the device or at the specified location in the smart card, then the Identified Third Party Protection Domain MUST be disabled.
A device SHOULD support the mechanism [SCPROV] to read Identified Third Party Protection Domain Root Certificates stored in the smart card (for example, SIM, USIM or WIM). Additionally, Protection Domain Root Certificates for the Identified Third Party Domain MAY be stored on the device. A device MUST support at least one certificate storage mechanism. If both mechanisms are supported, the device MUST use Root Certificates from both mechanisms.
Root Certificates may be placed in the trustedCertificates Certificate Directory File (CDF) of a WIM, SIM, or USIM or on the device. If Root Certificates are stored directly on a SIM or USIM, that is, not under the WIM application, then they shall be stored in the EF trustedCertificates CDF located under DF ([PKCS#15]), as defined by [SCPROV]. Root Certificates can be obtained only from the trusted CDF (the card holder can not update this directory) and not from any other directory of the smart card.
If the trustedUsage field contains the following OID, then the certificate is to be considered an Identified Third Party Protection Domain Root Certificate. See Figure 8-1 for the details.
ASN.1 : {iso(1)org(3)dod(6)internet(1)private(4)enterprises(1)sun(42) products(2)javaXMLsoftware(110)midp(2)spec(2)gsm-policy(2)identifiedParty(3)} URN : urn:oid:1.3.6.1.4.1.42.2.110.2.2.2.3 |
Any Root Certificates obtained after device manufacture MUST NOT have any effect on previously provisioned application suites. For subsequently provisioned application suites, such certificates MUST NOT be used as Protection Domain Root Certificates. This MUST NOT prevent obtaining Operator or Identified Third Party Authority Certificates from the specified location in a SIM, USIM or WIM.
If an Identified Third Party Protection Domain Root Certificate is to be deleted, the implementation MAY adequately warn the user of the consequence of the deletion. A disabled Identified Third Party Protection Domain Root Certificate MUST NOT be used to verify downloaded application suites.
Application suites that are unsigned will belong to the Unidentified Third Party Protection Domain. A device MUST support the security policy for the Unidentified Third Party Protection Domain.
The Unidentified Third Party Protection Domain for Unidentified Third Party application suites MUST allow access to :
Table 8-1 : Packages Allowed to Unidentified Third Party Protection Domain |
|
---|---|
API |
Description |
|
RMS APIs |
|
Application Lifecycle APIs |
|
Multi-media APIs |
The Unidentified Third Party Domain for Unidentified Third Party application suites MUST allow, access to protected APIs or functions:
Table 8-2 : Packages Allowed to Unidentified Third Party Protection Domain |
|
---|---|
API |
Protocol |
|
|
|
|
It should be noted that versions of IMP referred to the Unidentified Third Party Protection Domain as "Untrusted".
The security policy and permissions applied to all application suites that are installed on a device MUST conform to the requirements listed in this section, whether those application suites were preloaded or preinstalled or subsequently provisioned after device manufacture.
The high level functions essentially capture and reflect the actions and consequences of the underlying individual permissions. These so-called function groups are as follows:
Whenever new features are added they should be assigned to the appropriate function group. In addition, APIs that are specified elsewhere (that is, in other JSRs) but rely on the security framework should also be assigned to an appropriate function group. If none of the function groups defined in this section is able to capture the new feature and reflect it adequately a new function group MUST be defined in this document by requesting an update to this document from MSA or this specification as appropriate.
If a new function group is to be added, the following should be taken into consideration: the group to be added MUST NOT introduce any redundancy to the existing groups, the new group MUST be capable of protecting a wide range of similar features. The latter requirement is to prevent introducing narrowly scoped groups. The new function group SHOULD be sufficiently future-proof to contain new features added by future APIs and should not only concern the features being initially included in it.
Table 8-4 presents individual permissions and maps them to the function groups specified in this section. An individual permission MUST occur in only one function group.
Table 8-4 : Mapping Permissions to Function Groups |
||
---|---|---|
Permission |
Protocol |
Function group |
javax.microedition.io. |
http |
Net Access |
javax.microedition.io. |
https |
Net Access |
javax.microedition.io. |
datagram |
Low Level Net Access |
javax.microedition.io. |
datagram server (without host) |
Low Level Net Access |
javax.microedition.io. |
socket |
Low Level Net Access |
javax.microedition.io. |
server socket (without host) |
Low Level Net Access |
javax.microedition.io. |
ssl |
Low Level Net Access |
javax.microedition.io. |
comm |
Local Connectivity |
javax.microedition.io.PushRegistryPermission("*", "static,dynamic,alarm"). |
All |
Application Auto Invocation |
http |
Inter IMlet Communication via IMC |
Table 8-5 collects permissions that are not mapped to any function group and sets access level for Third Party Protection Domains. Permissions indicated as Permitted are granted to application suites as shown in the Table. Permissions indicated as Not Permitted are those that MUST NOT be mapped to any function group, and MUST NOT be available in either the Identified or Unidentified Third Party Protection Domain.
Table 8-5 : Permissions Not Mapped To Function Groups |
||
---|---|---|
Permission |
Identified Third Party Protection Domain |
Unidentified Third Party Protection Domain |
java.util.PropertyPermission |
Permitted |
Not Permitted |
java.util.PropertyPermission |
Permitted |
Not Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
javax.microedition.event.EventPermission |
Permitted | Permitted |
javax.microedition.event.EventPermission |
Permitted | Permitted |
javax.microedition.event.EventPermission |
Permitted | Permitted |
javax.microedition.event.EventPermission |
Permitted | Not Permitted |
javax.microedition.io.HttpProtocolPermission("http://localhost"); |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.cellular.CellularPermission |
Permitted | Not Permitted |
javax.microedition.cellular.CellularPermission |
Permitted | Not Permitted |
Permitted | Not Permitted | |
javax.microedition.power.PowerStatePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission("*"). See java.lang.Thread.checkAccess(). Defined in [CLDC]. |
Not Permitted | Not Permitted |
Not Permitted | Not Permitted |
The PushRegistry is the primary Auto Invocation mechanism subject to the security policy.
The PushRegistry
is protected using the security framework
and permissions. The application suite must have the
javax.microedition.io.PushRegistryPermission
to register
an alarm based launch, to register dynamically using the
PushRegistry
, or to make a static registration in the
application descriptor.
The push mechanism uses protocols in which the device is acting as the server and connections can be accepted from other elements of the network. To use the push mechanisms the application suite will need the permission to use the server connection in addition to the {@code PushRegistryPermission}. For example, to register a program that can be started via push might use the following attributes in the manifest:
MIDlet-Push-1: socket://:79, com.oracle.example.Sample, * MIDlet-Permissions-1: javax.microedition.io.PushRegistryPermission "socket:" "static,dynamic" MIDlet-Permissions-2: javax.microedition.io.SocketProtocolPermission "socket://"
When permission is granted to a function group, this action
effectively grants access to all individual permissions that have
been requested under this function group. An implementation MUST
guarantee that a SecurityException
is thrown when
the caller has not been granted the appropriate security permissions.
If an application uses the capabilities defined in this and other APIs,
the following rules MUST apply :
All the external API functions that need to be protected by the security framework MUST have permissions defined in those JSRs, and follow the naming rules identified in this specification.
The functions that are not deemed security-protected by specification can be accessed explicitly by untrusted application suites, as per general security rules.
If an external API does not define permissions for security-protected functions because the API specification is released earlier than IMP-NG, access is granted even to any functions that relate to network access.
All Licensee Open Classes (aka LOC, aka OEM Specific Classes, proprietary packages that do not logically fall into the category of a Java ME configuration, profile, or optional package) MUST adhere to the permission framework as defined in this document.
The named permissions compatible with IMP-NG in the Messaging Function Group are defined in JSR 205 Wireless Messaging API 1.0.2, Appendix E (Deploying JSR 205 Interfaces on a MIDP 2.0 Platform [JSR205]. The corresponding permissions needed to deploy JSR 205 must be defined by a future revision of [JSR205].
The permissions needed to deploy the [JSR 135] APIs are defined in the Multimedia Security Addendum to JSR 135 Mobile Media API, version 1.2 of [JSR 135].
Implementations MUST ensure that I/O access from the Mobile Media API
follows the same security requirements as the Generic Connection Framework,
as specified in the package documentation for javax.microedition.io
.
Example methods include
javax.microedition.media.Player.start
,
javax.microedition.media.Player.prefetch
, etc. When these
methods are used to fetch the content for the player via an HTTP connection,
the implementation MUST enforce the security requirements
specified for HTTP and HTTPS.
All previously authorized and installed application suites MUST act in accordance with the domain security policy when the device is roaming, or when the device smart card is changed.
Newly downloaded application suites are authenticated to a Protection Domain (to a Protection Domain Root Certificate if the PKI based authentication mechanism is used) currently available either on the device or at the specified location on the smart card (for example, SIM, USIM or WIM) and are authorized in accordance with the security policy.
If device roaming or a smart card change causes a failure to access network resources that the application was previously authorized to access, then the implementation MUST NOT throw a SecurityException. This failure is not related to application suite authorization, so the implementation MUST throw an IOException instead.
The permissions assigned to application suites installed in the Manufacturer and Unidentified Third Party Protection Domain MUST NOT be affected by changes of the smart card but application suites installed in the Operator or Identified Third Party Protection Domain MUST NOT execute if, after a smart card change, the authentication cannot be performed any more (for the PKI based authentication mechanism, this means that the Protection Domain Root Certificate that was used to authenticate the application suite to the Identified Third Party or Operator Protection Domain is no longer available) and until the authentification can be performed again (for a PKI based authentication mechanism this means: until the corresponding Protection Domain Root Certificate becomes available again).
If an application suite (either related to Operator or Identified Third
Party Protection Domain) cannot be executed due to a smart card
change, the implementation MUST NOT delete the application suite. In case
of a trial to execute the application suite without a successful authentication
(for PKI based authentication mechanism: if the authorizing
Protection Domain Root Certificate is missing), a
SecurityException
MUST be thrown.
For all signed applications, a compliant implementation SHOULD check revocation status. For the PKI based authentication mechanism one possibility is the usage of the Online Certificate Status Protocol Mobile Profile as specified in [OSCP-MP]. Alternatively, an implementation of the PKI mechanism MAY implement OCSP according to [RFC2560]. If other certificate revocation protocols are supported, support for these other protocols may indicate that a certificate has been revoked; in this case, it is permissible to consider the certificate as revoked regardless of the result returned by the OCSP protocol.
Whatever mechanism is used, MEEP-1.0 implementations MUST support black-listing of principals and/or applications at any time.
Black-listing a principal includes the following steps:
Black-listing an application includes the following steps:
CRL ([RFC4523]) or OCSP ([RFC2560]) MAY be used for that, but implementation-defined mechanisms (such as a simple "push" blacklisting) are also allowed.
[1] Meaning for the PKI based authorization mechanism: signed by a certificate issued under the certification hierarchy of this certificate. Meaning for other authorization mechanisms has to be defined there.