Discuss about MIDlet security.All the MIDlet suites are restricted to operate within a security model. This process is to prevent the access to sensitive APIs and functions of devices and avoiding risks to the device resources is primarily done by the MIDlets. MIDlets provide a flexible and consistent security model. The devices are enforced to access the control on a MIDlet suite which is treated as a trusted MIDlet along with the accordance with the domain defined policy. MIDlets allow cryptographically signed MIDlets suites as the authenticity.
Discuss about MIDlet security.Answer 1:
1. The Java security model used in J2SE is both powerful and flexible, but it is expensive in terms of memory resources.
2. CLDC or MIDP don’t include any of the security checking of API calls that is available in J2SE, with the exception of the Runtime and System exit() methods, which can never be used by a MIDlet.
3. The MIDP 2.0 specification defines an open-ended system of permissions.
4. To make any type of network connection, a MIDlet must have an appropriate permission.
5. The permissions defined in MIDP 2.0 correspond to network protocols, but the architecture allows optional APIs to define their own permissions.
6. MIDlets don't acquire permissions explicitly in code, but rather through something called a protection domain.
7. A protection comprises two parts:
- Permissions which are allowed (granted to contained MIDlet suites), and permissions for which the user must be consulted
- Criteria for entry into the protection domain
1. The J2ME security model is a scaled-down version of the J2SE model. It has been adapted to work within the contained resources common among J2ME devices.
2. The runtime environment cannot be modified, it cannot be modified oneself, and it cannot escape the runtime environment.
The rules are:
a. Class files are verified for interface compliance before inclusion in a JAR file.
b. There is a limited API set: The Connected Limited Device Configuration (CLDC), one or more related profiles, and licensee open classes.
c. Downloading and management of Java applications take place in native code within the Java virtual machine1. There are no user-defined class loaders.
d. There is no Java Native Interface (JNI), and no user extensions are allowed.
e. System classes cannot be overridden.