Default Security Policy Provider (certificate based)

Introduction

This chapter describes one possibility to implement a Security Policy Provider as it is generally described in the Security Policy Provider chapter. It is the mechanism as defined in MIDP 3.0, where an application suite or LIBlet is bound to security protection domains based on its signature (and therefore on the Client) and then the appropriate permission set for an application is determined. For MEEP 8, this is the default Security Policy Provider implementation, and it MUST be supported, if the implementation does not provide an individual one. This mechanism expects the default Authentication Provider of MEEP 8 as is defined here or another certificate based authentication provider.

The general rules for Security Policy Providers as defined here apply as well.

This chapter defines extensions to the base application suite security framework in the following areas:

The mechanism of reading root keys from sources external to the device
Certificate related aspects of application behavior in the roaming network
Certificate related aspects of application behavior when a SIM/USIM is changed

Security Protection Domains and Certificates

If the authentication of an application suite or LIBlet takes place Certificate based, the assignment is based on the application suite's signature. Application suites that are unsigned as per the ME 8 Security Framework MUST be assigned to a predefined "Untrusted" Client. If a signed application suite or LIBlet cannot be identified, it MUST NOT be installed. This applies if none of its associated certificate chains verify against a Client Root Certificate. If LIBlets can be identified via more than one way, they will get assigned to several Clients. If application suites can be identified via more than one way, they will get assigned to a single Client. How it is decided to which Client they will get assigned is implementation-dependent. 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 Client Root Certificate.

The assignment of an application suite to a Client has to be handled as follows:

Application suites signed "under the authority ^[1]" of a certain Client, as per the security framework, MUST be assigned to this Client.
Application suites not signed "under the authority ^[1]" of any Client MUST be assigned to the "Untrusted" Client.

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 Client Root Certificate.

A device implementing a certificate-based security policy provider MUST support the mechanism [SCPROV] to read Root Certificates stored in the smart card (for example, SIM, USIM or WIM).

Potential consequences of a change of the smart card are described in Application Download and Execution While Roaming and After Changing the Smart Card.

For a PKI based authentication mechanism, before invoking an application the device MUST check whether or not the Client Root Certificate is still valid. If the Client Certificate that verified the application is no longer valid then the application MUST NOT be invoked.

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 cannot update this directory) and not from any other directory of the smart card.

Application Download and Execution While Roaming and After Changing the Smart Card

Newly downloaded application suites and LIBlets are authenticated to a Client (to a Client 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 an application suite 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 Client Root Certificate is missing), a SecurityException MUST be thrown.

Revocation Checking

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.

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