×
Namespaces

Variants
Actions
(Difference between revisions)

Java Security Domains

From Nokia Developer Wiki
Jump to: navigation, search
hartti (Talk | contribs)
m (added Level-Intermediate category)
hamishwillee (Talk | contribs)
m (Hamishwillee - Bot update - Fix metadata)
(40 intermediate revisions by 14 users not shown)
Line 1: Line 1:
[[Category:Java]][[Category:Java ME]][[Category:Security]][[Category:Signing and Certification]][[Category:Level-Intermediate]]
+
{{ArticleMetaData <!-- v1.2 -->
 
+
|sourcecode= <!-- Link to example source code e.g. [[Media:The Code Example ZIP.zip]] -->
 +
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 +
|devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Nokia Qt SDK 1.1]) -->
 +
|platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 +
|devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 +
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing= <!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20070330
 +
|author= [[User:Hartti]]
 +
}}[[Category:Java ME]][[Category:Security]][[Category:Signing and Certification]]
 +
{{FeaturedArticle|timestamp=20100215}}
 
==Introduction==
 
==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.
+
There are some restrictions for accessing certain method calls and APIs from MIDlets. In those cases it is possible that the user will either be prompted for confirmation to allow a certain method call or the access is blocked altogether, resulting a 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.
+
Making these prompts appear less frequently requires the developer to sign the MIDlet and the user to manually change the API access settings. Signing to the operator or manufacturer domain will remove the prompts completely, but this requires close collaboration with those parties.
  
 
==Security domains==
 
==Security domains==
  
MIDP 2.0 specification defines 4 security domains in which the MIDlet can be installed:
+
Mobile information device profile (MIDP) 2.0 specification defines four security domains to which the MIDlet can be installed:
* third party protection domain (untrusted 3rd party)
+
* Third party protection domain (untrusted 3rd party)
* identified third party protection domain (trusted 3rd party)
+
* Identified third party protection domain (trusted 3rd party)
* operator protection domain
+
* Operator protection domain
* manufacturer protection domain
+
* Manufacturer protection domain
  
 
==API protection groups==
 
==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:
 
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)
+
* Net access (MIDP specification 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)
+
* Messaging (MIDP specification also defines restricted messaging)
 
* Application auto-start
 
* Application auto-start
 
* Local connectivity
 
* Local connectivity
Line 31: Line 52:
 
* (Phone call)
 
* (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:
+
The MIDlet will have access settings defined to each of the function groups above that 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
 
* Always allow / Blanket access
 
* Ask first time / Ask once per session
 
* Ask first time / Ask once per session
Line 38: Line 59:
  
 
==API access definitions in Java ME standards==
 
==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!)
+
Java specifications include a number of versions for the available API access rights (Note that it is possible that there might not be a 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 API access rights]]
 
* [[MIDP 2.0.1 API access rights]]
 
* [[MIDP 2.0.1 API access rights]]
 
* [[MIDP 2.1 API access rights]] (same as in MSA)
 
* [[MIDP 2.1 API access rights]] (same as in MSA)
* [[JTWI API access rights]] (only defines API access rights for untrusted 3rd party domain)
+
* [[JTWI API access rights]] (only defines API access rights for the untrusted 3rd party domain)
  
NOTE: The MIDP specification defines that even trusted 3rd party MIDlet cannot have networking and auto-start permissions simultaneously as Always Allowed!
+
NOTE: The MIDP specification defines that even a trusted 3rd party MIDlet cannot have networking and auto-start permissions simultaneously as Always Allowed!
  
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).
+
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 ==
+
== Certificates to sign to a trusted 3rd party domain ==
  
If your application passes [http://www.javaverified.com/ql_test_providers.jsp 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:
+
If your application passes [http://javaverified.com/ Java Verified] testing, it will be signed with UTI root certificate, which will place your MIDlet to the trusted 3rd party domain. Other common certificates that place your MIDlet to the trusted 3rd party domain are available from:
  
* [https://www.thawte.com/ssl-digital-certificates/code-signing/ Thawte]
+
* [https://www.thawte.com/code-signing/index.html Thawte]
* [https://www.verisign.com/products-services/security-services/code-signing/digital-ids-code-signing/ Verisign] - installation [[Signed_HelloWorld_example_MIDlet|test MIDlet]] for this certificate
+
* [https://www.verisign.com/code-signing/index.html Verisign] - installation [[Signed HelloWorld example MIDlet|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 [http://wiki.forum.nokia.com/index.php/KIJ000555_-_Signing_certificates_for_MIDlets incorrect] implementation ([http://browndrf.blogspot.com/2006/06/build-and-install-singed-midlet.html instructions]). Also note, that some operators have implemented so called developer certificates for their devices ([[Sprint Java security domains|Sprint]] and [[China Unicom Java security domains|China Unicom]]). Consequently, make sure to [[How to find the Java signing certificates on the phones|check the available code-signing CA-certificates]] (or check [http://discussion.forum.nokia.com/forum/showthread.php?p=374306#post374306 this posting]).
+
'''Note''' that there are differences between different phone models on which certificates are installed on the phones. Additionally, the same phone model may have a different set of certificates depending on which region it was sold in. Operator variants of the phones can also have additional changes in the certificate availability.
  
==Security Domain policies for a number of carriers, deviating from the standard==
+
Also note that the MIDP specification does not allow new certificates to be added on the phones to allow signing to the trusted 3rd party domain. This is, however, possible on S60 2nd Edition devices due to [[Archived:Signing certificates for MIDlets (Known Issue)]] implementation ([http://browndrf.blogspot.com/2006/06/build-and-install-singed-midlet.html instructions]). Some operators have also implemented so-called developer certificates for their devices ([[Sprint Java security domains|Sprint]] and [[China Unicom Java security domains|China Unicom]]). Consequently, make sure to [[How to find the Java signing certificates on the phones|check the available code-signing CA-certificates]] (or check [http://www.developer.nokia.com/Community/Discussion/showthread.php?123626-Certificate-Error-Contact-the-application-supplier-in-Nokia-E61&p=374306 this posting]).
  
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
+
==Security Domain policies some carriers that deviate from the standard==
* [[AT&T Java security domains]] (Cingular) ([http://blogs.forum.nokia.com/view_entry.html?id=360 entry on FN blogs])
+
 
* [[China Unicom Java security domains]] ([http://blogs.forum.nokia.com/view_entry.html?id=430 entry on FN blogs])
+
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:
* [[Hutchinson 3G security domains]]([http://blogs.forum.nokia.com/view_entry.html?id=400 entry on FN blogs]) - note, that Orange Israel follows the Hutchinson 3G guidelines too
+
* [[AT&T Java security domains]] (Cingular) ([http://www.developer.nokia.com/Community/Blogs/blog/hartti-suomelas-forum-nokia-blog/2007/01/10/cingular-and-java-security-domains-take-2 entry on FN blogs])
* [[Sprint Java security domains]] ([http://blogs.forum.nokia.com/view_entry.html?id=428 entry on FN blogs])
+
* [[China Unicom Java security domains]]
* [[T-Mobile U.S. Java security domains]] ([http://blogs.forum.nokia.com/view_entry.html?id=379 entry on FN blogs])
+
* [[Hutchinson 3G security domains]]([http://www.developer.nokia.com/Community/Blogs/blog/hartti-suomelas-forum-nokia-blog/2007/02/07/hutchinson-3g-and-java-security-domains entry on FN blogs]) - note, that Orange Israel follows the Hutchinson 3G guidelines too
 +
* [[Sprint Java security domains]] ([http://www.developer.nokia.com/Community/Blogs/blog/hartti-suomelas-forum-nokia-blog/2007/03/01/java-api-access-on-sprint-devices entry on FN blogs])
 +
* [[T-Mobile U.S. Java security domains]] ([http://www.developer.nokia.com/Community/Blogs/blog/hartti-suomelas-forum-nokia-blog/2007/01/23/t-mobile-u.s.-and-java-security-domains entry on FN blogs])
  
 
==Security domain information from other manufacturers than Nokia==
 
==Security domain information from other manufacturers than Nokia==
  
* Motorola [http://developer.motorola.com/docstools/developerguides/Motorola_OS_Devguide.pdf Java ME Developer Guide] (requires free registration) and [http://developer.motorola.com/docstools/technicalarticles/application_testing_and_signing/?WT.ac=NEWS-001-062008 Testing and Signing documentation]
+
* Motorola [http://developer.motorola.com/log-in/ Java ME Developer Guide] (requires free registration) and Testing and Signing documentation.
* Sony Ericsson [http://developer.sonyericsson.com/getDocument.do?docId=65067 Developers' Guidelines Java ME CLDC (MIDP 2)] and [developer.sonyericsson.com/getDocument.do?docId=99421 Java ME Permission settings in Sony Ericsson phones]
+
Note: Motorola handsets do not support Thawte or VeriSign Certificates, only Motorola certs and JavaVerified [https://support.developer.motorola.com/cgi-bin/motodev.cfg/php/enduser/popup_adp.php?p_sid=a256j_kj&p_lva=&p_li=&p_faqid=568&p_created=1170297506&p_sp=]
  
 
==API access settings on real phones==
 
==API access settings on real phones==
  
Also the generic phones have different versions of the API access rights implemented.
+
Generic phones also 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]], 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 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 2nd FP3]], on generic N72
* [[API access rights on phones, S60 3rd]], on generic E61i
+
* [[Archived:API access rights on S60 3rd Edition devices]], on generic E61i
* [[API access rights on phones, S60 3rd FP1]], on generic N95
+
* [[Archived:API access rights on S60 3rd FP1 devices]], on generic N95
* [[API access rights on phones, S60 3rd FP2]], on generic 6210 Navigator
+
* [[Archived:API access rights on S60 3rd Edition devices]], on generic 6210 Navigator
* [[API access rights on phones, S60 5th]], still just a placeholder
+
* [[API access rights on phones, S60 5th]], on generic N97
 
* [[API access rights on phones, Series 40 3rd FP1]], on generic 6131
 
* [[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 3rd FP2]], on generic Nokia 5300, 6300, 7373
 
* [[API access rights on phones, Series 40 5th FP1]], on generic Nokia 6500 slide
 
* [[API access rights on phones, Series 40 5th FP1]], on generic Nokia 6500 slide
 +
* [[API access rights on phones, Series 40 6th]]
 +
* [[API access rights on phones, Series 40 6th FP1]], on generic Nokia X3-02
  
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).
+
It is not possible to change the default settings available on the phone, but after MIDlet installation it is possible to change the API access settings from the default to the the available ones (not all options are available to untrusted MIDlets).
* [[How_to_change_the_Java_API_access_settings_on_S60_phones | S60 instructions]]
+
* [[How to change the Java API access settings on S60 phones | S60 instructions]]
* [[How_to_change_the_Java_API_access_settings_on_Series_40_phones | Series 40 instructions]]
+
* [[How to change the Java API access settings on Series 40 phones | Series 40 instructions]]
  
 
==References==
 
==References==
* [http://www.forum.nokia.com/info/sw.nokia.com/id/3f8c9f9e-e940-4327-8548-49ed023bfe88/MIDP_2_0_Signed_MIDlet_Developers_Guide_v2_0_en.pdf.html MIDP 2.0: Signed MIDlet Developer's Guide]
+
* [http://www.developer.nokia.com/info/sw.nokia.com/id/3f8c9f9e-e940-4327-8548-49ed023bfe88/MIDP_2_0_Signed_MIDlet_Developers_Guide_v2_0_en.pdf.html MIDP 2.0: Signed MIDlet Developer's Guide]
 +
<!-- Translation --> [[zh-hans:中文 J2ME安全域]]
 +
<!-- Translation --> [[pt:Java domínios de segurança]]

Revision as of 07:05, 28 September 2012

Article Metadata
Article
Created: hartti (30 Mar 2007)
Last edited: hamishwillee (28 Sep 2012)
Featured Article
15 Feb
2010

Contents

Introduction

There are some restrictions for accessing certain method calls and APIs from MIDlets. In those cases it is possible that the user will either be prompted for confirmation to allow a certain method call or the access is blocked altogether, resulting a SecurityException to be thrown.

Making these prompts appear less frequently requires the developer to sign the MIDlet and the user to manually change the API access settings. Signing to the operator or manufacturer domain will remove the prompts completely, but this requires close collaboration with those parties.

Security domains

Mobile information device profile (MIDP) 2.0 specification defines four security domains to 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 specification also defines low-level net access, but this has been combined on many phones to the Net access function group)
  • Messaging (MIDP specification 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 that 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

Java specifications include a number of versions for the available API access rights (Note that it is possible that there might not be a device available which would support the API access rights exactly the way they are defined in the specification!)

NOTE: The MIDP specification defines that even a trusted 3rd party MIDlet cannot have networking and auto-start permissions simultaneously as Always Allowed!

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 a 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 the trusted 3rd party domain. Other common certificates that place your MIDlet to the trusted 3rd party domain are available from:

Note that there are differences between different phone models on which certificates are installed on the phones. Additionally, the same phone model may have a different set of certificates depending on which region it was sold in. Operator variants of the phones can also have additional changes in the certificate availability.

Also note that the MIDP specification does not allow new certificates to be added on the phones to allow signing to the trusted 3rd party domain. This is, however, possible on S60 2nd Edition devices due to Archived:Signing certificates for MIDlets (Known Issue) implementation (instructions). Some operators have also 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 some carriers that deviate 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:

Security domain information from other manufacturers than Nokia

Note: Motorola handsets do not support Thawte or VeriSign Certificates, only Motorola certs and JavaVerified [1]

API access settings on real phones

Generic phones also have different versions of the API access rights implemented:

It is not possible to change the default settings available on the phone, but after MIDlet installation it is possible to change the API access settings from the default to the the available ones (not all options are available to untrusted MIDlets).

References

570 page views in the last 30 days.
×