All code that runs under MEEP 8 must be verified to originate from an authenticated source and have not been tampered with. Any code which does not meet these requirements must be treated as "untrusted", with severely limited capabilities.
Any application and LIBlet is bound to a Security Protection Domain, which represents the largest set of permissions an application can successfully request. A Security Protection Domain is associated with a Client. While an application is always bound to a single Client, a LIBlet can also be bound to more than one Client.
A Client is a security entity, authenticated by the authentication provider, with a specific associated security protection domain which includes limited permissions as granted by the owner of the security policy for the device. Every Client may have its own security policy. The purpose of the concept of a Client is to identify the protection domain to which all applications and LIBlets of that Client are bound. As a consequence the security protection domain of a Client cannot change.
A Client has only permissions relative to his own applications and resources, unless explicitly allowed otherwise.
The Root Client ("root" for short) is a special trusted Client with a protection domain that includes full rights to all system operations, including installation and removal of application suites, access to all connected hardware and responsibility for all security operations. It is part of the MEEP implementation and cannot be defined or changed.
An Audit Client is a trusted principal Client with a protection domain that includes the rights to monitor and block the flow of data relevant to auditing and privacy. Note: This does not include the right to view or modify data. It is up to the Authentication Provider how a Audit Client is defined and identified.
Authentication of Clients is performed by a configurable Authentication Provider, which identifies and verifies Clients and associated applications and LIBlets. The mechanism by which the authentication provider authenticates a Client or an application must be configurable at the time of system-level configuration/installation.
In MEEP 8, an application is provisioned via an application package (Application Suite), which contains one or more applications (MIDlets). LIBlets are provisioned in packages as well.
For an application or LIBlet package to be trusted, it must be ensured that the application or LIBlet package has not been tampered with. This is achieved either by provisioning the application or LIBlet package in an encrypted and signed manner, or by provisioning the application or LIBlet package via trusted mechanism from a trusted source (such as by means of access-controlled local medium or a mutually authenticated secure connection).
The authentication of the Client and the application or LIBlet package is done by the authentication provider. Authentication typically involves the identification and verification of the Client credentials as well as verification of the application or LIBlet package.
This chapter only defines the general rules the implementation of an Authentication Provider MUST follow. Configuration of a provider is up to the implementation of that specific provider. The specification must allow for an authentication provider as defined in MIDP 3.0 (and as is described in particular here), as well as for alternate authentication mechanisms, for example, authentication via a back-end mechanism, local medium, or via a mutually trusted network connection. A compliant implementation may choose the MIDP 3.0 like authentication provider or an alternate provider. The MIDP 3.0 like authentication provider MUST be used as the default authentication provider unless an implementation-specific authentication provider is used.
There must be only one authentication provider at any given time though and the implementation of this provider must remain unchanged throughout the runtime of the system. A string describing the current authentication provider can be retrieved as the value of the microedition.security.authentication system property as defined in the system properties chapter.
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 or LIBlet originator. The results of the verification have a direct impact on authorization. Table 7-3 below summarizes the states to which the authentication verification led and which are further used for authorization at install time.
|
Table 7-3 : Summary of Application Suite or LIBlet Source Verification |
|
|---|---|
Initial state |
Verification result |
| JAD not present, JAR downloaded | Behavior depends on the Authentication Provider of the MEEP implementation: If the Authentication Provider requires a JAD file for authentication (e.g. the PKI based one as described here), then authentication cannot be performed without JAD. For installation of an application suite or explicitly provisioned LIBlet the 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. If the Authentication Provider allows authentication without a JAD though, then the application suite or LIBlet may be installed as a trusted one even without a JAD file if the the authentication of the JAR has been successful. |
| JAD present but JAR is not authenticated | Authentication cannot be performed. Installation of the JAR of an application suite or explicitly installed LIBlet 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 and JAR is authenticated | JAR installation is allowed, application suite or LIBlet is identified as trusted if it can be assigned to a trusted Client as a result of the authentication. Otherwise an application suite or explicitly installed LIBlet MUST NOT be installed, a LIBlet being provisioned as part of an application suite installation, if the application suite is trusted, MUST NOT be installed in this case, the installation of the application suite MUST fail as well. |
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 cannot 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 or LIBlet and security information used to authenticate and authorize an application suite or LIBlet 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 and LIBlet 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 or LIBlet are implementation specific and thus not covered by this specification.
Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.