MIDP Security is enforced at MIDlet installation and upgrade. Installation time security enforcement can be divided into:
Authentication
Authorisation
Package protection
At the authentication phase, the authenticity of the application source is checked. This means that both the origin and the integrity of the application must be verifiable.
In authentication, the signing certificate and associated certificate chain found from the attribute MIDlet-Certificate-<n>-<m> , is validated against one of the root certificates stored in device memory or SIM card. This is to verify the origin of the application.
After the origin of the application has been verified, the signature in the attribute MIDlet-Jar-RSA-SHA1 is decrypted using the verified signing certificate and the public key found from inside the certificate. The decrypted value is compared to the hash value calculated at application signing time.
If certificate attributes ( MIDlet-Certificate-<n>-<m>) are present but signature attribute (MIDlet-Jar-RSA-SHA1) is missing, the application is installed as unidentified.
Following table defines error cases that may be encountered during application authentication and respective error notes:
|
Error situation |
user note |
|---|---|
|
If signature attribute (MIDlet-Jar-RSA-SHA1) is present but certificate attributes (MIDlet-Certificate-<n>-<m>) are missing installation fails with error. |
No valid certificate |
|
Any errors in syntax of MIDlet-Jar-RSA-SHA1 and MIDlet-Certificate-<n><m> lead to installation failure. |
|
|
Validity issues related to root certificates, for example expiration lead to installation failure. |
Certificate invalid according to phone’s date |
|
If the signature found from JAD does not match with the signature computed over the JAR, the installation fails. |
Application Illegally modified |
|
Trying to update a signed version with an unsigned version of a Java application leads to installation failure. |
Invalid application for update |
At authentication phase, Nokia devices may also check the validity of the certificate online using Online Certificate Status Protocol (OCSP).
OCSP check is done at the OTA download phase, if the signing certificate has AIA extension. With no AIA extension, the OCSP check is not done. If the check fails, installation fails accordingly with error message No valid certificate.
At the authorisation phase, application is bound to the correct protection domain which is determined based on the root certificate application. The protection domain defines which permissions can be granted to the application and what is the behavior when application accesses these privileged functions. Signed applications must explicitly request the permissions using MIDlet-Permissions and MIDlet-Permissions-Opt attributes. Without requesting the permissions, access to those are not granted. The set of granted permissions represent the intersection between the requested permissions (collected from both MIDlet-Permissions and MIDlet-Permissions-Opt) and the permissions available within the protection domain to which the application is bound to. Failures encountered during the processing of MIDlet-Permissions-Opt result in ignoring the faulty permission.
Following table defines error cases that may be encountered during application authorisation and respective error notes:
|
Error situation |
User note |
|
Any failure encountered during the processing of MIDlet-Permissions will fail installation. |
Application not supported |
Certain Java packages are protected in the sense that they are reserved by the implementation of the Java Runtime. The protection rule applied means that application classes neither can refer to these packages nor can define classes inside these packages. Any security violations are checked at runtime and fail with Application Error.