Security Authentication Providers

Introduction

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

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

A Root Client ("root" for short) is a trusted client with a protection domain that includes full rights to all system operations, including installation and removal of applications, access to all connected hardware and responsibility for all security operations. It is up to the Authentication Provider how a Root Client is defined and identified.

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. 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 (MIDlet suite), which contains one or more applications (MIDlets).

For an application package to be trusted, it must be ensured that the application package has not been tampered with. This is achieved either by provisioning the application package in an encrypted and signed manner, or by provisioning the application 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 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 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.

Authenticating an Application Suite

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 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 Source Verification

Initial state

Verification result

JAD not present, JAR downloaded Authentication cannot be performed, may install JAR. Application suite is treated as untrusted
JAD present but JAR is not authenticated Authentication cannot be performed, may install JAR. Application suite is treated as untrusted
JAD present and JAR is authenticated JAR installation is allowed, application suite is identified as trusted (if it can be assigned to a trusted client as a result of the authentication, otherwise it is treated as untrusted).

Caching of Authentication and Authorization Results

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

Security of Alternative Application Representation Formats

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.