Important Concepts of midp2 Security System

J2-based tutorials (8_2) -- From the j2-based Development Network

8.3 important concepts of the midp2 Security System 8.3.1 license License is used to protect access to sensitive APIs, which is not difficult to understand. The application tries to obtain the corresponding permissions by applying for a license on the sensitive API. 8.3.2 protected domain A concept associated with a license is the protection domain. A protected domain is a set of licenses and the Interaction modes that apply to these licenses. A device has multiple protection domains, and the MIDlet runs in different protection domains. Different devices may provide different protection domains. Fortunately, the MIDP Specification defines recommendation behavior for untrusted domains. In principle, the non-trusted domain provides less licenses, and the confirmation of the license must be performed explicitly by the user. The Regulations provide at least HTTP and HTTPS requests. That is to say, the following situation may occur: Your device has Bluetooth capabilities, but this API is not open to untrusted domains. The specification also specifies the user interaction mode (also known as the authorization mode) for non-trusted domains: blanket (always allowed), Session (First Inquiry), and oneshot (each inquiry ). However, not every device opens these three interaction modes to each sensitive API in the untrusted domain. For example, the interaction mode of the fo API on Nokia mobile phone in a non-trusted domain is only oneshot (each query), which means that the user is required to confirm each call to this api by the MIDlet running in this domain. The behavior of other protection domains is determined by the device. The following describes several protection domains in the simulator that comes with wtk. Again, it is likely that this will be different from what you see on the actual device. Wtk provides four types of protection domains: untrusted, trusted, minimum, and maximum. Generally, our MIDlet runs in the untrusted protection domain, which is why when we perform sensitive operations, the system will always pop up a dialog box asking us if we want to perform the next operation. We can change the protection domain of the MIDlet, select edit-> preferences-> security from the ktoolbar, and then select trusted In this way, when we run httpmidlet again, you will find that the system did not ask the user for permission, but directly performed online operations. This indicates that the "trusted" of the wtk simulator protects the domain's default authorization for HTTP operations by allowed, that is, user participation is not required. In order to give you a clearer understanding of the concept of protected domain, rather than just staying on the wtk simulator, we will briefly introduce the protected domain on Nokia mobile phones. There are four types of protection and protection for Nokia: 1) device manufacturer domain 2) operator domain 3) trusted third-party domain (corresponding to trusted domain in wtk) 4) untrusted domain. Nokia also stipulates that as long as the program does not run on a untrusted domain, the API defined in midp2 can be accessed without user request prompts. To tell readers this, we hope that the reader can refer to the documents of various vendors for the protection domain behavior of the target device and the wtk simulator at different times. 8.3.3 Application for Permission If you use sensitive APIs, you will be concerned about how to apply for a license. The license must be written to the Jad property file. The attributes used are MIDlet-permissions and MIDlet-permissions-OPT. The former is used to apply for a license required for running the program, and the latter is used to apply for an optional additional license. The distinction between the two principles is that, without the permission defined by the former, the application should not be able to run; without the permission defined by the latter, the application should reduce unnecessary functions, ensure that the program runs in a shrinking way. So what are the benefits of writing a license to a JAD file? In fact, when you write the license to the JAD file, you tell the Application Management System (AMS) What operations are required to successfully run the MIDlet suite and what permissions are obtained. If AMS does not allow this operation, it will reject the installation of this application. Instead of waiting for the installation to find that the operation was not successful. You may think that writing these two fields is too cumbersome. Fortunately, we can directly set them using the features provided by wtk and choose Settings> permissions. 8.3.4 two types of MIDlet After understanding the concept of protected domain, it is not difficult to understand the two MIDlet defined by midp2.0 security architecture-untrusted MIDlet and trusted MIDlet. The MIDP 2.0 specification defines the JAR file as untrusted for the MIDlet suite that the device cannot verify the JAR file source and integrity. The untrusted MIDlet runs on the untrusted protection domain. Based on our previous discussions on untrusted protection domains, we learned that this does not mean that the MIDlet cannot be installed or executed. Instead, the protection domain is implemented based on the device, or the API cannot be accessed, either access to restricted operations requires explicit user permission. By default, all MIDP 1.0 midlets are untrusted. If the device can verify the authenticity and integrity of the MIDlet suite and allocate it to a protected domain, the MIDlet suite is called the trusted MIDlet suite. Trust the MIDlet suite to obtain the requested permission based on its protected domain behavior. For example, if you request the javax. microedition. Io. connector. Http license and the protection domain has set the license to trusted, you can open the HTTP connection without confirmation. Do not think that the trust MIDlet suite must run on the trust protection domain. The trusted MIDlet suite can be assigned to any protected domain. The trusted protected domain is only one of them, or it is simply called another name on the device. In addition, the recommended security policy only recommends that you trust the MIDlet to call the midp2 API without user participation. So don't be surprised if your trusted MIDlet prompts explicit confirmation when using a non-midp2 sensitive API. However, in this case, there will be the "blancet" (always allowed) mode for the user to choose. 8.3.5 how to become a trusted MIDlet After learning the above information, I believe that every developer who calls sensitive APIs wants their applications to become a trusted MIDlet, so that the applications can run smoothly. However, how to verify a MIDlet suite as a trusted suite and assign it all the protection domains on the implementation of the device. Generally, devices use digital signature technology to achieve this. Obtaining a digital signature is a process of test and authentication. Testing requires a professional company and certification requires a trusted organization, and this process requires a certain amount of time and a fee. Authentication is performed before the program is released. without authentication, the application is tested as a trusted suite in the simulator. This detailed process is beyond the scope of attention in this chapter, so the section about digital signature is not described here. Www.j2medev.com will write an article to introduce this process. Interested readers can go to www.javaverified.com to learn about this process, or consult the target device developer. The main purpose of this chapter is to understand the midp2.0 security system and its main concepts, and hope to help you.