Security and MIDP applications

An important part of MIDP security is Java^TM's inherent programming model. Badly written or malicious code can only halt the Java environment and is unable to render the mobile device inoperable. Some MIDlets might need to use additional APIs to access network resources or the file system of the mobile device. As a security precaution for this kind of usage, more sophisticated MIDlets are usually signed by a reliable authority.

For more information on security, see the Introduction to MIDP Security, MIDP 2.0 specification, and Forum Nokia security documents.

Java security levels

Java MIDlets can be divided in two security categories: trusted and untrusted. To make an application trusted, it has to be signed. This allows the MIDlet to be installed under a trusted domain. As opposed to signed MIDlets that can give more access rights, untrusted MIDlets cannot access sensitive APIs without end-user conformation.

The MIDP security model defines four security domains:

Untrusted, not signed or MIDP 1.0 MIDlets
Trusted 3rd party, signed with a third party certificate
Operator, signed with an operator certificate
Manufacturer, signed with a manufacturer's own certificate

More information on security domains can be found in Signing MIDlets.

Permissions

The user can grant permissions to enable sensitive functions, in which the Java application would not have rights to access otherwise or which would be confirmed from the user before execution. These permissions are divided in four groups: denied, one-shot, session and blanket.

**Table 2:** Permissions and their descriptions
Permission	Description
Denied (not allowed)	No permission granted
One-shot (ask every time)	Asked every time the resource is needed
Session (ask first time)	Valid for the session
Blanket (always allowed)	Valid for every invocation of an API by a MIDlet suite

Figure 3: An unsigned MIDlet asks for network permissions

Signing

To sign a MIDlet, developers need a code-signing certificate conforming to the X.509 Public-Key Infrastructure (PKI) specification. It is also recommended to use the Java Verified Program - an industry-wide initiative for testing Java ME applications - for testing and signing applications for the trusted third party domain. The benefit of getting the application Java Verified is to gain better access to various delivery channels, as many of those accept only applications that are Java Verified.

Unsigned MIDlets display a warning before installation and when using sensitive APIs, such as FileConnection API or Personal Information Management API.

For more information on signing, see Signing MIDlets, which offers general information on signed MIDlets and describes the signing process. See also Forum Nokia, Security.

Cryptography

Security and Trust Services API (SATSA, JSR-177) offers an interface to Public Key certificates and other private data storage, cryptographic operations and secure environment services to enable authentication, authorization and identification for banking and other solutions.

For more information on SATSA, see JSR-177 specification. In addition, Encrypted messages introduces the usage of Crypto API for Java development.

DRM

From S60 3rd Edition onwards the S60 platform supports Digital Rights Management for MIDlets as specified in the OMA DRM specification version 2.0. The earlier OMA DRM specification version 1.0 has been supported in S60 platforms fully since S60 2nd Edition FP 2.

From Series 40 3rd Edition FP 1 onwards, Series 40 platform provides an implementation of OMA DRM version 1.0.

**Table 3:** Delivery mechanism support in Series 40 and S60 platforms
Delivery mechanism	Description	Platform
Forward-lock	A simple mechanism that prevents content from leaving the phone it was delivered to. This provides a basic copy protection to protect the rights of content owners.	S60 1st Edition Series 40 3rd Edition FP 1
Combined delivery	An extension to forward-lock, combined delivery allows additional usage rights to be added to the content. For example, content sent to allow the user to preview it would have the usage right “may be used only once” assigned to it. Combined delivery will also create opportunities for various new business models; for example, content may not be permanently sold to the consumer, in which case a content usage right such as “view for a week” will be used.	S60 2nd Edition FP 2 Series 40 3rd Edition FP 1
Separate delivery	Similar to combined delivery but with added security. In separate delivery, content is delivered as encrypted files and separately from the usage rights, which are delivered via a different channel.	S60 2nd Edition FP 2 Series 40 3rd Edition FP 1
Superdistribution	A subset of separate delivery, in which the content can be further distributed to another users by the mobile device user.	S60 2nd Edition FP 2 Not supported in Series 40

Note that DRM protected content can be accessed from S60 3rd Edition onwards by using the FileConnection API (JSR-75). In addition MMAPI (JSR-135) can be used for playing DRM-protected sound files, for example.

For more information on DRM in Java development, see Open Mobile Alliance web site and Implementation Best Practices For OMA DRM v1.0 Protected MIDlets.

End-to-end security: HTTPS

As well as the encrypted networking via HTTPS, MIDP 2.0 provides added security at the MIDlet level, aimed at giving greater protection to the end user. HTTPS is “secure HTTP” used, for example, in Internet banking services. Securing is made by tunneling HTTP connection. Technology used for this is Transport Layer Security (TLS)/Secure Sockets Layer (SSL) over HTTP.