Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Harden Your Wireless Apps with MIDP 2.0 Protection Domains : Page 2

Security has always been central to the MIDP specification, but the new MIDP 2.0 goes well beyond the first version's sandbox method. Find out how to use the new protection domains in 2.0.


advertisement
A Matter of Trust
Providing greater access to data and services on a device requires a level of trust to be established between the application, the device, and the user. MIDP 2.0 accomplishes this using protection domains. A protection domain defines a collection of Permissions that can be granted to a MIDlet suite. A MIDlet suite is bound to a domain by establishing trusted status. One way to establish trust uses X.509 certificates, which allow a MIDlet suite to be signed using a public key (PKI). This key is then used to authenticate the MIDlet suite with the device upon installation and bind it to an appropriate protection domain.

Figure 1. Prompting the user for permission: The first option is granting blanket permission, the second grants oneshot permission.

MIDP 2.0 identifies two basic security domains: trusted and untrusted. However, vendors may provide additional domains and permissions as needed. The untrusted domain is essentially the sandbox security model of MIDP 1.0. A MIDlet suite granted untrusted status has the least amount of freedom on the device. This is because less is known about the MIDlet suite and the suite did not attempt to establish a higher trust level at installation time.



If a MIDlet suite gains trusted status on a device, the suite is given more freedom as more is known about it, including where it came from and who wrote it. A trusted MIDlet suite is bound to a protection domain at installation time. Each protection domain is associated with a security policy that governs behavior of how permissions are granted. These behaviors are referred to as interaction modes.

Interaction Modes
Interaction modes are divided into two categories: allowed and user. Allowed permissions have established a level of trust between the device and the MIDlet suite sufficient to allow access to the requested resource. If a permission has the allowed interaction mode, the user is not prompted before granting access to the resource.

In user interaction mode the user must explicitly grant access to the MIDlet suite to a protected resource, otherwise no access is provided. Typically, the user is prompted the first time a MIDlet suite attempts to access a protected resource. The user responds to the request by providing one of the following interaction modes as a response. In the case permission is not granted, a java.lang.Security exception is thrown.

blanket

The user grants permission to access the resource for as long as the MIDlet suite remains installed. The user never sees another prompt to grant access to this permission.

session

The user grants permission to access the resource for as long as the MIDlet suite is running. The user never sees another prompt to grant access to this permission until the suite is exited and restarted.

oneshot

The user is prompted to grant permission to the resource each time the MIDlet suite attempts to use the resource.

Figure 1 shows an example of how a user may be prompted to grant access to a resource.

Note that MIDP implementations must provide a way for the user to change or reverse these decisions. This is often provided by the MIDP implementer through a menu option on the device.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date