This page was last modified 15:59, 7 April 2008.
Java Security Domains
From Forum Nokia Wiki
Introduction
Accessing certain method calls and APIs from MIDlets has some restrictions. It is possible that in those cases the user will get prompted for confirmation to allow the certain method call or the access might be blocked altogether, which will result SecurityException to be thrown.
Making these prompts to appear less frequently requires the developer to sign the MIDlet (and the user to manually change the API access settings). Only signing to operator or manufacturer domain will remove the prompts completely, although this requires really close collaboration with those parties.
Security domains
MIDP 2.0 specification defines 4 security domains in which the MIDlet can be installed:
- third party protection domain (untrusted 3rd party)
- identified third party protection domain (trusted 3rd party)
- operator protection domain
- manufacturer protection domain
API protection groups
Each of the protection domains have certain level of access to the protected (sensitive APIs). The access rights are grouped to a function groups:
- Net access (MIDP spec also defines low-level net access, but this has been combined on many phones to the Net access function group)
- Messaging (MIDP spec also defines restricted messaging)
- Application auto-start
- Local connectivity
- Multimedia recording
- Read user data (including files and PIM)
- Write/Edit user data (including files and PIM)
- Location
- Landmark store
- Smart card communication
- Authentication
- (Call control)
- (Phone call)
The MIDlet will have access settings defined to each of the function groups above, which are supported by the phone. The setting can be one of the following defined by the security domain policy of the phone:
- Always allow / Blanket access
- Ask first time / Ask once per session
- Ask every time
- Not allowed
API access definitions in Java ME standards
The Java specifications include a number of versions for the available API access rights (note, that there might not be a single device available which would support the API access rights exactly the way they are defined in the specification!)
- MIDP 2.0 API access rights
- MIDP 2.0.1 API access rights
- MIDP 2.1 API access rights (same as in MSA)
- JTWI API access rights (only defines API access rights for untrusted 3rd party domain)
A MIDlet which has not been signed will be placed in the untrusted domain, which has most restrictions for accessing certain APIs. If the MIDlet has been signed and the corresponding certificate is stored in the certificate store of the phone, the MIDlet will be placed in the protection domain to which the certificate has been tied to. (There are some complex checks which are done at the installation time, please see the MIDP 2 specification for more info).
Certificates to sign to trusted 3rd party domain
If your application passes Java Verified testing, it will be signed with UTI root certificate, which will place your MIDlet to trusted 3rd party domain. Other common certificates placing your MIDlet to trusted 3rd party domain are available from:
- Thawte
- Verisign - installation test MIDlet for this certificate
Note, that the MIDP specification does not allow new certificates added on the phones to allow signing to trusted 3rd party domain. This is however possible on S60 2nd Edition devices due to incorrect implementation (instructions). Also note, that some operators have implemented so called developer certificates for their devices (Sprint and China Unicom). Consequently, make sure to check the available code-signing CA-certificates (or check this posting).
Security Domain policies for a number of carriers, deviating from the standard
As the MIDP spec security domain policy is just a recommendation, some operators have defined their own security domains and API access rights. These include
- AT&T Java security domains (Cingular) (entry on FN blogs)
- China Unicom Java security domains (entry on FN blogs)
- Hutchinson 3G security domains(entry on FN blogs) - note, that Orange Israel follows the Hutchinson 3G guidelines too
- Sprint Java security domains (entry on FN blogs)
- T-Mobile U.S. Java security domains (entry on FN blogs)
Security domain information from other manufacturers than Nokia
- Motorola Java ME Developer Guide (requires free registration)
- Sony Ericsson Developers' Guidelines Java ME CLDC (MIDP 2) and [developer.sonyericsson.com/getDocument.do?docId=99421 Java ME Permission settings in Sony Ericsson phones]
API access settings on real phones
Also the generic phones have different versions of the API access rights implemented.
- API access rights on phones, S60 2nd FP2, on generic 6630 (2.39.126)
- API access rights on phones, S60 2nd FP2 ver2, on generic 6680, 6630 (6.03.40)
- API access rights on phones, S60 2nd FP3, on generic N72
- API access rights on phones, S60 3rd, on generic E61i
- API access rights on phones, S60 3rd FP1, on generic N95
- API access rights on phones, Series 40 3rd FP1, on generic 6131
- API access rights on phones, Series 40 3rd FP2, on generic Nokia 5300, 6300, 7373
- API access rights on phones, Series 40 5th FP1, on generic Nokia 6500 slide
One cannot change the default settings available on the phone, but after MIDlet installation it is possible to change the API access settings from default to the available ones (not all options are available to untrusted MIDlets).
References
| Related Discussions | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| symbian security failures? | msanch92 | Symbian Networking & Messaging | 1 | 2003-10-17 14:00 |
| Mifare Connection to Secure Element | B_T | Near Field Communication | 23 | 2007-10-15 17:32 |
| KNI in J2ME for interation with C++ API | samir01m11 | Mobile Java General | 9 | 2006-11-03 00:19 |
| Autherizing Device | zanzon | Bluetooth Technology | 5 | 2006-09-10 07:25 |
| any alternative for RBTSecuritySettings?? | lal.rajan | Symbian Networking & Messaging | 8 | 2007-03-08 16:46 |
