Technical documents: 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 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 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. 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 (protection 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.

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 (applicable in short term), and oneshot (applicable in this time). The general mode is that the license obtained during the MIDlet installation is always valid, unless the user cancels these licenses, and the short-term applicable mode means that the user needs to allow the first call of the API, And the validity period ends until the execution of the MIDlet suite ends; this applicable mode requires the user to allow each API call. The protected domain defines the default interaction mode for user permission.

A MIDlet suite uses the MIDlet-permissions and MIDlet-permissions-opt attributes to clearly define its license, either in the JAD file or in the manifest file. MIDlet-permissions defines the licenses that must be available in the MIDlet suite, while MIDlet-permissions-opt defines the desired licenses. 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.

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 domains), except for untrusted, each protected domain corresponds to a set of root certificates, and the root certificate used to sign the signature certificate of the MIDlet 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, the manufacturer domain belongs to the device manufacturer, and its root certificate is the root certificate of the device manufacturer. The operator domain operator generally uses the root certificate in its SIM card; while the trusted third party domain has preset the root certificate of the world-renowned digital certificate authority (CA), used to verify the MIDlet signature certificate issued by the CA; while the untrusted domain does not have the root certificate, it will be used for the unsigned MIDlet and MIDP 1.0.

The Root Certificates of thawte and VeriSign are already preset in the trusted third party domain. The 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 the device manufacturer domain, so they can only apply for the 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 those APIs that are untrusted. The 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 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, a securityexception is generated and processed 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, 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, you cannot pass authentication. 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. 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 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 user certificate is used to decrypt the digest of the MIDlet-Jar-RSA-SHA1 attribute, and then calculate the digest of the downloaded JAR file, compare whether the two digests are equal, if 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, installation is still not allowed if one or more protection domains do not belong to the license attributes (MIDlet-permissions) in the MIDlet. If one or more protection domains in the optional MIDlet-permissions-opt attributes do not belong to, 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 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) 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 all the default licenses of the MIDlet signed by the certificate in the trusted third party domain, as shown in 1, click "Config emulators" in NDS 3.0 to see that the default security setting of the simulator in the trusted third party domain is "Ask first time", that is, the 1st usage requires confirmation:

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 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.
Figure 1: http://www.wotrust.com/support/image...Security_3.gif