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 ( |
|
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. |
|
If the signature found from JAD does not match with the signature computed over the JAR, the installation fails. |
|
Trying to update a signed version with an unsigned version of a Java application leads to installation failure. |
|
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:
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.