Chapter 3 - Security both CLDC and MIDP
MIDP 1.0 Security:
Application security in MIDP 1.0 is based on a Java sandbox model.MIDlet are allowed to save data in persistent storage files called record stores.
sharing of record stores between MIDlet is not allowed. With respect to end-to-end security, MIDP 1.0 specification does not include any cryptographic functionality. The only network protocol provided in MIDP 1.0 is the HTTP protocol.
MIDP 2.0 Security:
MIDP 2.0 controls access to APIs by granting permissions to protection domains and binding each MIDlet on the device to one protection domain.
A MIDlet will be granted all permissions provided to the protection domain that has been bound to it.
A MIDlet is bound to one protection domain according to procedure that allows the AMS to authenticate the origin of a MIDlet-
If one MIDlet can be authenticated, then it is qualified as trusted, otherwise, it will be qualified as untrusted.
It share record stores between MIDlet.MIDP 2.0 provides end-to-end security by allowing secure networking using HTTPS protocol.
A set of APIs that are identified as sensitive and protected Midlets. The sensitive APIs in MIDP 2.0 are the ones related to connectivity and the PushRegistry class.
Permissions and Protection Domains
Access to sensitive APIs is protected by permissions. A protection domain defines a set of permissions, and each permission protect domain level of access to the API protected by the permission.
The level of permission is granted without involving the user.It access to the protected API requires explicit authorization from the user. This authorization can be in one the following modes
1. Blanket: The permission is valid for every invocation of the protected API.
2. Session: The permission is valid during one execution of the MIDlet.
3. Oneshot: The user must be prompted for each invocation of the protected API.
Four protection domains are provided by MIDP 2.0:
• Minimum: This domain contains no permissions. Access is denied for all sensitive APIs.
• Untrusted: Requires that sensitive APIs can only be accessed through user permissions.
• Trusted: All permissions are granted.
• Maximum: Same as trusted.
Signing a MIDlet
In order to sign a MIDlet suite, the signer needs to have a private and public key pair, and a certificate for his public key.
If this certificate is not a certificate authority then it should be another certificate that vouches that the first one is valid.
If this second certificate is still not a certificate authority, it requires a third certificate vouching for it, and so on until a root certificate is reached.
The procedure of signing the MIDlet:
• The signer of a digital fingerprint of the JAR file by applying a hash function.
• They sign the digital fingerprint by encrypting it with the private Key.
• The signed fingerprint is placed in the JAD file.
Persistent Storage Security
In MIDP 2.0 a MIDlet can save the data in a persistent storage area. The storage unit in CLDC is the record store.
Each MIDlet suite can have one or more record stores, these are stored on the persistent storage of the device.
Record stores are identified by a unique full name, which is a concatenation of the vendor name, the MIDlet suite name, and the record store name.
Within the same MIDlet, two record stores cannot have the same name.If they belong to two different MIDlet suites, they can have the same name since their full names
MIDP 2.0 specification that HTTPS be implemented to allow secure connection with remote sites.
HTTPS implementations must provide server authentication. The Certificate authorities present in the device are used to authenticate sites by verifying certificate chain provided by a server.
Mobile Information Device Profile security