MIDP 2.0 security mechanism and MIDlet Digital Signature

This article from the http://www.sf.org.cn/j2me/base/20112.html, If You Need To reprint, please keepArticleSource ~

This document is a technical document provided by wotrust according to Forum Nokia.MIDP 2.0: tutorial on signed midletsFor more information, see the original English document. Please read this document before writing the MIDlet and the signature MIDlet, so that you can have a deep understanding of the security mechanism of midp2.0 and help you make good use of the MIDletCodeSign the certificate. 

after fully understanding the security mechanism of midp2.0, you can apply for the Java code signature certificate of thawte or Verisign from wotrust to sign the MIDlet, for more information, see

Nokia MIDlet (MIDP 2.0)

j2-midlet (MIDP 2.0)

I. Overview

Midp2.0 adopts a new security mechanism, which must be understood by the MIDlet developers who need to call a sensitive (important) function and API, such: 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 of the MIDlet is not very profitable for developers, because many protected APIs require signatures to protect the interests of developers and users. Of course, some applications do not require signatures, for example, some small game software that only uses graphic APIs without internet connection. 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 security reasons, there is a security warning when installing a signed MIDlet. On the contrary, if you install a signed MIDlet, there will be no annoying warnings, 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. The MIDlet suite 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: can MIDlet send users' 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 is more secure than MIDP 1.0. It divides APIs into common APIs and sensitive APIs. For example, if you access a mobile network through HTTP, you will be charged, therefore, it is classified as a sensitive API. MIDlet 2.0 introduces the concepts of trusted MIDlet (trusted) and untrusted MIDlet (untrusted). A untrusted MIDlet can only access limited APIs, at the same time, you also need to manually confirm and modify the security policy, and the trusted MIDlet automatically inherits the security policy in the system to obtain the access permission.

Permissions is used for sensitive APIs that require identity authentication. MIDP 2.0 requires that you obtain necessary licenses before calling sensitive APIs. These license packages are named the same as j2se licenses. For example, the HTTP connection license is also called javax. microedition. Io. connector. HTTP. The license documents agree to be categorized in protected APIs.

2.1 Protection domains (Protected domain)

Protection domain is a very important security concept in MIDP 2.0. A protection domain is a license set and an interactive mode, which can be inherited by itself, it may also be set by the user. The former is called allowed, and the latter is called user permission ). After a MIDlet is installed, it is assigned to a specified protection domain to obtain its license and interaction mode. 

A MIDlet suite uses the MIDlet-permissions and MIDlet-permissions-opt attributes to clearly define its license, it can be defined in the JAD file or in the manifest file. MIDlet-permissions defines the required licenses in the MIDlet suite, MIDlet-permissions-opt defines 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 (an SSL certificate is deployed on the server) to enhance security, but it is not necessary, in this way, the application description of this application 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 domain called "minimum", which has no permission. Therefore, if a signed MIDlet containing many licenses is installed in this domain, the installation fails because these licenses are not supported by this domain. 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 operators),Trusted Third Party (Trusted Third Party), AndUntrusted (Untrusted domain)Except for untrusted, each protection domain corresponds to a set of root certificates. The root certificate used to sign the MIDlet signature certificate must be included in these root certificates, different signature certificates are automatically assigned 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,ManufacturerThe domain belongs to the device manufacturer and its root certificate is the root certificate of the device manufacturer.OperatorThe domain carrier generally uses the root certificate in its SIM card.Trusted Third PartyThe domain is preset with the root certificate of the world-renowned digital certificate authority (CA), used to verify the MIDlet signature certificate issued by the CA; andUntrustedIf the domain does not have a root certificate, it will be used for the MIDlet and MIDP 1.0 without a signature.

The Root Certificates of thawte and VeriSign have been preset inTrusted Third PartyThe Java code signature certificate can be used to sign the MIDlet. Of course, you can also choose to use the certificates issued by the device manufacturer and mobile operator, as long as the root certificate is already included in the four protection domains of the mobile phone. According to wotrust, most Motorola mobile phones only support device manufacturers. Therefore, you can only apply for a signature service from Motorola.

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 areUntrustedThe source and integrity of these jar files cannot be verified by mobile phones. However, this does not mean that these midlets cannot be installed and run. Instead, you need to manually confirm and allow them to run these midlets. All midlets of MIDP 1.0 are definedUntrusted. 

UntrustedOnly one API that does not require license protection can be called, such:

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, a securityexception is generated and processed by the MIDlet according to the security policy. Please note: Nokia's UI APIs are not protected, including class: 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, which is called a trusted MIDlet suite. The license required by a trusted MIDlet suite will be permitted, as long as the protected domain has this license, if license: javax. microedition. io. connector. if HTTP is already allowed in the protected domain, you do not need to confirm that the MIDlet opens an HTTP 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, authentication fails. The successfully signed JAD file will certainly contain a chain of certificates with the entire signature, the property name is: MIDlet-Certificate-1-1 is your signature certificate, and the MIDlet-Certificate-1-2 is the CA's intermediate root certificate, and MIDlet-Certificate-1-3 is ca's top-level root certificate. The MIDlet-Jar-RSA-SHA1 attribute is the abstract of the JAR file.

when a MIDlet is downloaded or installed, the MIDlet application manager first checks whether the JAD file contains the MIDlet-Jar-RSA-SHA1 attribute, and if so, starts the following verification process: first, the certificate in the MIDlet-Certificate-1-1, MIDlet-Certificate-1-2, and MIDlet-Certificate-1-3 attributes is read 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. Then, the Digest of the MIDlet-Jar-RSA-SHA1 attribute is decrypted using the user certificate, and the Digest of the downloaded JAR file is calculated to compare whether the two digests are equal. If they are equal, it indicates that the MIDlet code is not modified after self-signed. 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 one or more protection domains that do not belong to the license attributes ( MIDlet-permissions ) in the MIDlet are not allowed to be installed. If one or more protection domains that do not belong to one or more of the optional MIDlet license attributes ( MIDlet-permissions-opt ) in the MIDlet, installation is allowed. 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, to allow a "net access" (Network Access) group instead of javax. microedition. Io. connector. HTTP, this is very useful for simplifying interactions 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 licenses related to automatic start of the MIDlet, such as push Registration

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

(5)Multimedia recording: Includes permits related to recording, photography, and video recording;

(6)Read user dataIncluding 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, such:Multimedia recordingIt is not included in a cell phone without a recording device. 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) or denied, and can be set to oneshot, blanket, or denied in a trusted domain.

 

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 inTrusted Third PartyAll default permissions in the domain, as shown in 1. Click "Config emulators" in NDS 3.0 to see the simulator inTrusted Third PartyThe default security setting of the domain is "Ask first time", that is, the following needs to be confirmed for 1st requests:

 

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: 

As shown in figure 3, in the "real life" mode, that is, the actual mobile phone running mode, we can see that the seven functional groups defined are "Always Allowed" (always allowed ), this shows how important the MIDlet signature is to developers, which makes it much easier for users to use and does not need to be confirmed in a series of annoying operations.