MIDP 2.0 security mechanism and MIDlet Digital Signature

MIDP 2.0 security mechanism and MIDlet Digital Signature
This document is translated by wotrust according to the technical documentation MIDP 2.0: tutorial on signed midlets provided by Forum Nokia, please refer to this original English document: http://www.wotrust.com/support/resou...ts_v1_1_en.pdf at the same time. Please read this document before writing the MIDlet and signature MIDlet, so that you can have a deep understanding of the security mechanism of midp2.0 and help you use the MIDlet code signature certificate.

After fully understanding the security mechanism of midp2.0, you can apply to wotrust for the Java code signature certificate of thawte or VeriSign to sign the MIDlet. For more information, see Nokia MIDlet (MIDP 2.0) code signature certificate application and user guide: http://www.wotrust.com/support/Nokia...ning_guide.htm

I. Overview

Midp2.0 adopts a new security mechanism, which is used to call a sensitive (important) function and the MIDlet of the API.
Developers must understand, such as network connection APIs, message APIs, and push functions. Some optional MIDP packages also have many restricted APIs.
.

Although it is costly to purchase a code signature certificate, the signature MIDlet is not very profitable for developers, because many protected APIs
Signature is required to protect the interests of developers and users. Of course, some applications do not need signatures. For example, some applications that do not need to be connected only use some graphic APIs.
Small game software. But some important applications, such as connecting to the network, Sending Short Messages (SMS and MMS), or accessing mobile terminals (such as smart phones and PDAs)
The PIM (personal information management) data on must be signed.

Benefits of Digital Signature MIDlet include:

(1) Based on the security policy of the MIDlet, some functions can be used only after being signed, and some functions can be used even if they are not signed, however, you must confirm and modify the security policy when using the data. For example, writing user data does not allow signature-free MIDlet operations by default;

(2) Based on the system security of mobile phones and the security of mobile networks, some mobile phone manufacturers and mobile operators may refuse to install and run non-Signed midlets on mobile phones;

(3) greatly improves the user experience and makes it easy for users to use, so that users will not experience the troubles of security warnings when calling protected APIS;

(4) for the sake of security, there is a security warning when installing a signed MIDlet. On the contrary, there is no annoying warning when installing a signed MIDlet, the mobile phone automatically verifies the signature and successfully installs it;

(5) The signed MIDlet will enable users to improve their low security policy settings and improve the security of mobile phones;

(6) Ensure that the signed MIDlet is not illegally tampered with or stolen.

Ii. MIDP 2.0 Security Mechanism

MIDP is an open platform that allows anyone to develop various application software for devices that support MIDP, generally mobile terminal devices. MIDlet
The package can be downloaded anonymously over the Internet, which is very convenient. However, this will also cause many security and privacy information protection problems. The user will ask: MIDlet
Can I send my personal information to unknown servers? Will it automatically generate unauthorized calls or short messages, causing fees to users? Does malware damage mobile phones? And so on.

In addition to the security features of the Java language, the MIDP also adds many security considerations. MIDP 2.0 enhances the security policy compared with MIDP 1.0.
APIs are classified into common APIs and sensitive APIs. For example, access to mobile networks through HTTP is classified as sensitive APIs because of charges incurred by users.
MIDlet 2.0 introduces the concept of trusted MIDlet (trusted) and untrusted MIDlet (untrusted), an untrusted
The MIDlet can only access a limited number of APIs. You also need to manually confirm and modify the security policy.
The system automatically inherits the Security Policy to obtain the access permission.

Permissions is used for sensitive APIs that require identity authentication. MIDP 2.0 requires that sensitive APIs be called
The necessary licenses must be obtained before, and the names of these licenses are the same as those of j2se licenses. For example, HTTP connection licenses are also called:
Javax. microedition. Io. connector. HTTP. The license documents agree to be categorized in protected APIs.

2.1 Protection domains (protection domain)

The protected domain is MIDP 2.0.
A very important security concept. A protection domain is a license set and an interactive mode. These licenses can be inherited by the user or set by the user. The former is called allow.
(Allowed), which is called user permission ). When a MIDlet
After being installed, it is assigned to a specified protection domain to obtain its license and interaction mode.

To allow a user, the user must decide whether to accept the permission. the user can either refuse or agree to the permission. Users are allowed to have three modes of interaction: blanket (applicable in general)
Session (for short term) and oneshot (for this time)
The license obtained during installation is valid until the user cancels these licenses. The short-term applicable mode means that the user needs to allow the first time the API is called, and the validity period is up to this MIDlet
The kit is running, and this applicable mode requires the user to allow each call to the API. The protected domain defines the default interaction mode for user permission.

A MIDlet kit uses MIDlet-permissions and MIDlet-permissions-OPT
Property to clearly define its license, either in the JAD file or in the manifest file. Where: MIDlet-Permissions
Defines the required licenses in the MIDlet suite, while the MIDlet-permissions-OPT
Define the desired license. For example, the basic requirement of an application software is to have an HTTP connection before it can work normally. At the same time, you can also use an HTTPS connection (the server is deployed
SSL Certificate) to enhance security, but it is not necessary. In this way, the application description of this application software can be as follows:

MIDlet-permissions: javax. microedition. Io. connector. HTTP

MIDlet-permissions-OPT: javax. microedition. Io. connector. https

Note: The license required by a MIDlet must be a subset of the Protection domains allocated during installation. For example, Nokia s60 MIDP
Emulator prototype 2.0 (SDK) has a name called "minimum
. Therefore, if a signed MIDlet contains many licenses
If installed in this domain, the installation will fail because this domain does not support these licenses. Similarly, if a license name has a spelling error, the installation may fail because the domain does not have a permission for spelling errors.

The MIDP 2.0 defines four protection domains for GSM/utms devices: Manufacturer (device manufacturer ),
Operator (mobile operator), trusted third party (trusted third party), and untrusted (
Untrusted domain), except for untrusted, each protected domain corresponds to a set of root certificates, used to sign the MIDlet
The root certificate of the signature certificate must be included in these root certificates, using different signature certificates to sign the MIDlet
Will be automatically classified to the protected domain to which the root certificate belongs. The relationship between the root certificate and the protected domain is: a protected domain can have multiple root certificates, A root certificate can only correspond to one protected domain.

Specifically, the manufacturer domain belongs to the device manufacturer and its root certificate is the root certificate of the device manufacturer. Operator domain operators generally use
The root certificate in the SIM card, while the trusted third party domain is preset with the root certificate of the world-renowned digital certificate authority (CA), used to verify
Issued MIDlet signature certificate; while the untrusted domain does not have a root certificate, it will be used for the unsigned MIDlet and MIDP 1.0.

The Root Certificates of thawte and VeriSign have been preset in the trusted third party domain, and their Java
The code signature certificate can be used to sign the MIDlet. Of course, you can also choose to use the certificate issued by the device manufacturer and mobile operator, as long as the root certificate is already included in the 4
Protected domains. According to wotrust, most Motorola mobile phones only support device manufacturers. Therefore
You have applied for the signature service.

Note: As MIDP 2.0 is constantly being modified and supplemented, different mobile network operators may have different protection domains and licenses. Users may need to learn more from mobile operators. The simplest way is to check whether the root certificate of the MIDlet signature certificate is planned to be purchased by the target user's mobile phone.

2.2 untrusted MIDlet (untrusted MIDlet)

MIDP 2.0 defines the APIs that are untrusted.
The source and integrity of the file cannot be verified by the mobile phone. However, this does not mean that these midlets cannot be installed and run, but they run
The user must manually confirm the permission. All MIDP 1.0 midlets are defined as untrusted.

Untrusted midlets can only call one API that does not require license protection, for example:
Java. util
Java. Lang
Java. Io
Javax. microedition. RMS
Javax. microedition. MIDlet
Javax. microedition. lcdui
Javax. microedition. lcdui. Game
Javax. microedition. Media
Javax. microedition. Media. Control

If the untrusted MIDlet suite tries to call a protected API and is not manually allowed,
Securityexception is handled by the MIDlet according to the security policy. Note: Nokia's UI APIs are not protected, including:
Com. Nokia. Mid. Sound and COM. Nokia. Mid. UI.

2.3 trusted midlets (trusted midlets)

If the mobile phone can verify the identity and integrity of the MIDlet (that is, it has been digitally signed), it will automatically assign a suitable protection domain such as the MIDlet
A suite is called a trusted MIDlet. The license required by a trusted MIDlet suite will be permitted, as long as the protected domain has such permission, if permitted:
Javax. microedition. Io. connector. HTTP is already allowed in the protected domain, then the MIDlet opens an HTTP
You do not need to confirm the connection.

Do not confuse trusted MIDlet suites with trusted protection domains. Each trusted MIDlet suite is assigned to a specific protection domain based on security policies.

You must use the code signature certificate issued by the Certificate Authority of the preset root certificate on your mobile phone to sign the MIDlet. Otherwise, you cannot pass authentication. Signed
The JAD file will certainly contain a chain of certificates with the entire signature certificate. The property name is: MIDlet-Certificate-1-1 is your signature certificate, and
MIDlet-Certificate-1-2 is ca's intermediate root certificate, and MIDlet-Certificate-1-3 is ca
. There is also a MIDlet-Jar-RSA-SHA1 property that is the summary of the JAR file.

When a MIDlet is downloaded or installed, the MIDlet application manager first checks whether the JAD file contains
MIDlet-Jar-RSA-SHA1 properties, if any, start the following verification process: first read the MIDlet-Certificate-1-1,
MIDlet-Certificate-1-2 and MIDlet-Certificate-1-3
Property, and compared with the preset root certificate, if the certificate chain can be verified by the root certificate, it indicates that the developer identity has been verified. The user certificate is used for decryption.
MIDlet-Jar-RSA-SHA1 properties, calculate the summary of the downloaded JAR file, compare the two digests are equal, if equal, it indicates
The self-Signed MIDlet code is not modified. In this way, the MIDlet that verifies the identity and checks the integrity will be assigned to the protection domain corresponding to the root certificate. However, if
If one or more of the Protection domains that do not belong to a permission attribute (MIDlet-permissions) in the MIDlet, installation is still not allowed. If
Optional license attributes in the MIDlet (MIDlet-permissions-oPt)
One or more protection domains that do not belong to them are allowed to be installed. It can be seen that it is very important to correctly set the license attributes and optional license attributes.

2.4 function groups (function group)

To simplify user management operations, MIDlet groups similar functions so that you only need to set a permission for the function group. For example, permit "net access "(
Network Access) group instead of javax. microedition. Io. connector. HTTP, which is very useful for simplifying interaction operations on mobile phones.

MIDP 2.0 and jtwi define the following seven functional groups:

(1) Net Access: including all network connection licenses;

(2) Messaging: including all licenses related to sending and receiving short messages (SMS and MMS;

(3) Auto invocation: Includes permissions related to automatic start of the MIDlet, for example, push Registration

(4) local connectivity: including licenses related to local connections, such as IrDA or Bluetooth;

(5) multimedia recording: including permission to allow recording, photography, and video recording;

(6) read user data: including permission for reading user data, such as address book and calendar;

(7) write user data: includes permission for Writing user data.

Different mobile phones support different function groups. For example, multimedia recording is not included in mobile phones without video recording devices. Of course, more function groups may be added in the future.

Function groups also define different interaction methods for different domains. For example, in untrusted domains, "net access" (Network Access) is set to session (
For short-term use) or denied, while for trusted domains, it can be set to oneshot, blanket, or denied.

3. Default Security Settings for simulators and mobile phones

Let's take a look at the specific use of thawte or Verisign code to sign the certificate signature after the MIDlet in trusted third
All default licenses in the party domain, as shown in 1. Click "Config emulators" in NDS 3.0 to view the simulators in
The default security setting of the trusted third party domain is "Ask first time", that is, the following needs to be confirmed for 1st use:

Figure 1: http://www.wotrust.com/support/image...Security_1.gif

As shown in figure 2, you can drop down the permission settings of all function groups. For example, "network access" has four options to modify: Ask first time, ask every time, always allowed, and not allowed:

Figure 2: http://www.wotrust.com/support/image...Security_2.gif

As shown in figure 3, in the "real life" mode, that is, the actual mobile phone running mode, we can see that the seven function groups defined are "always ".
Allowed "(always allowed), which shows the MIDlet
The signature is so important to developers that it makes it much easier for users to use and does not need to be confirmed by the annoying series of user operations.
Figure 1: http://www.wotrust.com/support/image...Security_3.gif