securitypolicy_rp.html

J2ME MIDP2.0 final specification

			<p style="border: medium none ; padding: 0cm;">
			 Messaging</p>
		</td>
	</tr>
	<tr>
		<td width="30%" valign="top">
			<p style="border: medium none ; padding: 0cm;"> javax.microedition.io.Connector.sms</p>
		</td>
		<td width="49%" valign="top">
			<p style="border: medium none ; padding: 0cm;"> 
			  Connector.open("sms://&#8230;")<br>
			  Connector.open("sms://&#8230;", READ)<br>
			Connector.open("sms://&#8230;", READ, Bool)<br>
			Connector.open("sms://&#8230;", WRITE)<br>
			Connector.open("sms://&#8230;", WRITE, Bool)<br>
			Connector.open("sms://&#8230;", READ_WRITE)<br>
			Connector.open("sms://&#8230;", READ_WRITE,  Bool)</p>
		</td>
		<td colspan="1" width="19%">
			<p style="border: medium none ; padding: 0cm;">
			 Messaging</p>
		</td>
	</tr>
	<tr>
		<td width="30%" valign="top">
			<p style="border: medium none ; padding: 0cm;"> javax.microedition.io.Connector.cbs.receive</p>
		</td>
		<td width="49%" valign="top">
			<p style="border: medium none ; padding: 0cm;"> 
			  Connector.open("cbs://&#8230;")<br>
			  Connector.open("cbs://&#8230;", READ)<br>
			  Connector.open("cbs://&#8230;", READ, Bool)</p>
		</td>
		<td colspan="1" width="19%">
			<p style="border: medium none ; padding: 0cm;">
			 Messaging<!--[if !supportMisalignedColumns]--></p>
		</td>
	</tr>
	
</tbody></table>

<p class="Paragraph">Note: The
permissions for Wireless Messaging API are yet to be defined in
JSR120.</p>
<p align="center">
Table 6: Assigning proposed permissions and API calls specified in
the Mobile Media API to function groups</p>
<table border="1" cellpadding="0" cellspacing="3">
	<tbody><tr>
		<td colspan="3" width="99%">
			<p align="center" style="border: medium none ; padding: 0cm;">
			<b>Mobile Media API</b>&#8211;<b>JSR 135</b></p>
		</td>
	</tr>
	<tr>
		<td width="42%">
			<p style="border: medium none ; padding: 0cm;">
			<b>Policy File Identifiers (Proposed Permissions)</b></p>
		</td>
		<td width="42%">
			<p style="border: medium none ; padding: 0cm;">
			<b>Permitted API calls</b></p>
		</td>
		<td width="13%">
			<p style="border: medium none ; padding: 0cm;">
			<b>Function group</b></p>
		</td>
	</tr>
	<tr>
		<td width="42%">
			<p style="border: medium none ; padding: 0cm;"> javax.microedition.media.RecordControl.startRecord</p>
		</td>
		<td width="42%" valign="top">
			<p style="border: medium none ; padding: 0cm;"> RecordControl.startRecord
			( )</p>
		</td>
		<td width="13%">
			<p style="border: medium none ; padding: 0cm;">
			 Multimedia recording</p>
		</td>
	</tr>
	<tr>
		<td width="42%">
			<p style="border: medium none ; padding: 0cm;"> javax.microedition.media.VideoControl.getSnapshot</p>
		</td>
		<td width="42%" valign="top">
			<p style="border: medium none ; padding: 0cm;"> VideoControl.getSnapshot
			(&#8230;)</p>
		</td>
		<td width="13%">
			<p style="border: medium none ; padding: 0cm;">
			 Multimedia recording</p>
		</td>
	</tr>
</tbody></table>

<p class="Paragraph">
Note: The permissions for Mobile Media API are
yet to be defined in JSR135.</p>
<p class="Paragraph">Implementations MUST ensure that I/O access from the Mobile Media
API follows the same security requirements as the Generic Connection
Framework, as specified in the package documentation for
javax.microedition.io.  Example methods include
javax.microedition.media.Player.start,
javax.microedition.media.Player.prefetch, etc.  When these
methods are used to fetch the content for the player via an HTTP
connection, the implementation MUST enforce the security requirements
specified for HTTP.</p>
<p class="Paragraph">When the user grants permission to a function group, this action
effectively grants access to all individual permissions under this
function group to which a MIDlet was authorized. This MUST not
include all the individual permissions from the group.  For
example, if a MIDlet was authorized to make an HTTP connection and
was not authorized to access any other protected functions from the
Net Access group, Blanket permission to a Net Access means permission
to make HTTP connections only. Individual permissions that were not
granted to the MIDlet by the MIDP authorization framework will not be
granted by a user allowing Net Access, as function groups are
served for the user representation only. 
</p>
<p class="Paragraph">Implementation notes:</p>
<ol>
	<li class="Bullet1">
    <p class="Paragraph">An implementation MUST guarantee that a Security exception is
	thrown when the caller does not have the appropriate security
	permissions.</p>
  </li>
  <li class="Bullet1">
    <p class="Paragraph">If a messaging group is granted a Oneshot
	permission, it translates into a Blanket permission for
	javax.microedition.io.Connector.sms and
	javax.microedition.io.Connector.cbs, as well as to permissions that
	enable receiving the messages.  Permission for sending the
	messages is still Oneshot, however; that is, the user grants
	permission to each message sent out by the MIDlet within an open
	connection. The
	same applies to the Session permission: functions related to sending
	the messages get Session permission, but other functions get Blanket
	permission."
	Blanket permission and No permission granted to the Messaging group
	apply to all individual permissions under this group.<br>
    </p>

  </li>
</ol>

<p class="Paragraph">If a MIDlet uses the capabilities defined in MIDP and other APIs,
the following rules MUST apply: 
</p>
<ul type="disc">
	<li class="Bullet1">All the external API functions
	  that need to be protected by MIDP 2.0 security framework MUST have
	  permissions defined in the subsequent JSRs, and follow the naming
	  rules identified in the MIDP 2.0 Specification, 
	  titled "Security for MIDP Applications."
	</li>
	<li class="Bullet1">The functions that are not deemed
	  security-protected by specification can be accessed explicitly by
	  trusted and untrusted MIDlets, as per general MIDP security rules. 
	</li>
	<li class="Bullet1">If an external API does not define
	  permissions for security-protected functions because the API
	  specification is released earlier than MIDP 2.0, any functions that
	  relate to network access MUST still have the user prompt implemented
	  by the device.
	</li>
	<li class="Bullet1">A device cannot access the network
	  without appropriate user notification. 
	</li>
	<li class="Bullet1">All licensee open classes MUST adhere to the permission
	  framework as defined in this document. 
	</li>
</ul>
<h2 class="ChapterTitle">6  Permissions Granted to a
MIDlet Suite by the Authorization Mechanism</h2>
<p class="Paragraph">As defined in the "Security for MIDP Applications" section of the MIDP 2.0
specification, MIDlet suite permissions are effectively the
intersection of the domain permissions Midlet-Permission and
Midlet-Permission-Opt found in the JAR manifest. The way in which a
MIDlet's granted permissions are presented to the user is
implementation-specific, but the following rules must apply:
</p>
<ul type="disc">
	<li class="Bullet1">The user must
	be able to change the default permission setting to any setting
	available for a given MIDlet permission, with default and available
	sets of user permission types provided as guides in the tables in
	Section 5. This latitude will allow the user to upgrade or downgrade
	the default permissions as required.
	</li>
	<li class="Bullet1">If MIDlet
	permissions are grouped according to capabilities they represent,
	permissions granted to a MIDlet suite will be rendered into the
	function groups to be presented to the user. If function grouping
	is used, default permission applies to the whole group of
	permissions under the group. So does the available set of types of
	user permissions. If the default permission is changed, the change
	is effective for the entire group at once rather than to the
	individual permissions under this group. 
	</li>
	<li class="Bullet1">A function group cannot be a union of
	permissions with different default settings and other settings. 
	Therefore the tables in Section 5 follow the convention of having
	the same default and available settings for all permissions in a
	single function group. This rule must be taken into account when
	designing new permissions and policies.
	
</li></ul>

<p class="Paragraph">A device MUST maintain security-related data for
each installed MIDlet, in addition to generic MIDlet information such
as MIDlet name and version number. The data MUST include at least the
following: 
</p>
<ul type="disc">
	<li class="Bullet1">The MIDlet's source, if the
	application was signed. At least MIDlet-Vendor MUST be stored along
	with the installed MIDlet. 
	</li>
	<li class="Bullet1">Data related to the root
	    certificate a signed MIDlet was authenticated to; at minimum the
	    Subject field of the root certificate. 
	</li>
	<li class="Bullet1">Data related to a signer
	    certificate that signed the MIDlet; at minimum the certificate's
	    Subject, Issuer, and Serial Number<i> </i>fields.  (As an
	    alternative, a device may store the entire certificate chain that
	    came with the MIDlet descriptor file.)
	</li>
	<li class="Bullet1">A list of permissions granted to the MIDlet. 
	</li>
</ul>


<p class="Paragraph">A device MUST be able to present information
related to the application signer in a user-friendly manner. 
</p>
<h2 class="ChapterTitle">7  User Prompts and Notifications</h2>
<p class="Paragraph">The following rules MUST be followed in order to
ensure informed user consent to MIDlet actions: 
</p>
<ul type="disc">
	<li class="Bullet1">Any chargeable event generated by
	the MIDlet MUST be preceded by user notification, for example,
	showing the phone number the MIDlet is dialing, the URL being
	connected to, or the recipient of an SMS.
	</li>
	<li class="Bullet1">Any chargeable event in progress
	(for example, peer-to-peer connection the user is charged for) MUST
	be indicated to the user. 

	</li>
	<li class="Bullet1">A MIDlet MUST get user approval to
	connect to the network, in accordance with user permission settings
	of the policy. 
	
	</li>
	<li class="Bullet1">Any MIDlet permissions must be
	presented to the user in an intuitive, user-friendly manner. 
	
	</li>
	<li class="Bullet1">A MIDlet MUST not be able to
	override security prompts and notifications to the user generated by
	the system or virtual machine. 
	
	</li>
	<li class="Bullet1">A MIDlet MUST not be able to
	simulate security warnings to mislead the user. 
	
	</li>
	<li class="Bullet1">A MIDlet MUST not be able to simulate key-press events to
	mislead the user. 
	</li>
</ul>
<h2 class="ChapterTitle">8  MIDlet Download and Execution While Roaming
and After Changing the Smart Card</h2>
<p class="Paragraph">All previously authorized and installed MIDlets
MUST act in accordance with the device policy when the device is
roaming, or when the device smart card is changed. Newly downloaded
MIDlets are authenticated to the root certificates currently
available in the certificate store and are authorized in accordance
with the device policy. 
</p>
<p class="Paragraph">If device roaming or a smart-card change causes failure to access
network resources that the MIDlet was previously authorized to
access, then the implementation MUST NOT throw a SecurityException.
This failure is not related to MIDlet authorization, so the
implementation MUST throw an IOException instead.</p>
<p class="Paragraph">The permissions assigned to MIDlets installed in
the Manufacturer, Trusted Third-Party, and Untrusted domains are not
affected by changes of the (U)ICC [(U)ICC], but MIDlets
installed in the Operator domain MUST NOT execute if, after a
smart-card change, the SIM no longer holds the certificate containing
the operator root public key that was used to authenticate the MIDlet
to the Operator domain (the "authenticating root";
see Section 3.2, "Operator Domain").
</p>

<p Detection of whether a MIDlet in the Operator
domain can be executed  SHOULD follow the following mechanism:</p>

<ul type="disc">
	<li class="Bullet1">When a MIDlet is installed in the Operator domain,
it is 	signed by a certificate whose certification chain ends with the 	authenticating
root certificate, stored in the smart card with the Operator-domain key-usage
field.  The 20-byte SHA-1 hash of the 	value of the BIT STRING subjectPublicKey
(excluding the tag, length, 	and number of unused bits) from that root certificate,
termed  	the "authenticating root key hash" of the MIDlet, is 	stored
in the device along with the MIDlet (as specified in Section 	3.2).  	
	</li><li class="Bullet1">Whenever the smart card is changed, the 20-byte SHA-1
hash of 	the value of the BIT STRING subjectPublicKey (excluding the tag, 
	length, and number of unused bits) of each certificate stored in the 	new
smart card with the Operator-domain key-usage field (Operator-domain root
key hashes) is computed and stored before any MIDlet in 	the Operator domain
is executed.  	
	</li><li class="Bullet1">A MIDlet in the Operator domain is disabled if
its 	authenticating root key hash does not correspond to one of the new Operator-domain
root key hashes generated after the smart card was 	changed.  	
</li></ul>


<p class="Paragraph">Whether a MIDlet in the Operator domain can
  be executed depends on a comparison of "root key hash"
  values, computed as the 20-byte SHA-1 hash of the value of the BIT
  STRING subjectPublicKey (excluding the tag, length, and number of
  unused bits) of a root certificate.  The decision process SHOULD
  follow the following mechanism:</p>
      <ul type="disc">

	<li class="Bullet1">When a MIDlet is installed in the Operator domain, it
	      is signed by a certificate whose certification chain
	      ends with the authenticating root certificate, stored in
	      the smart card with the Operator-domain key-usage
	      field.  The hash value of that certificate's
	      subjectPublicKey, termed the "authenticating root key
	      hash" of the MIDlet, is stored in the device along with
	      the MIDlet (as specified in Section 3.2).
	</li>
	<li class="Bullet1">Whenever the smart card is changed, the "Operator-domain
	      root key hash" of each certificate stored in the new
	      smart card is computed and stored before any MIDlet in
	      the Operator domain is executed.
	
	</li>
	<li class="Bullet1">A MIDlet in the Operator