📄 securitypolicy_rp.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><html><head> <meta http-equiv="CONTENT-TYPE" content="text/html; charset=iso-8859-1"><title>The Recommended Security Policy for GSM/UMTS Compliant Devices</title> <!-- Changed by: Roger Riggs - Sun Microsystems Inc, 25-Jul-2002 --> <!-- Changed by: Gary Adams - SMI Software Development, 30-Jul-2002 --> <meta name="GENERATOR" content="StarOffice 6.0 (Solaris Sparc)"> <meta name="CREATED" content="20020719;16144600"> <meta name="CHANGED" content="20020719;17014700"> <meta name="ProgId" content="Word.Document"> <meta name="Originator" content="Microsoft Word 9"> <link REL="STYLESHEET" href="stylesheet.css" charset="ISO-8859-1" type="text/css"> <!--[if gte mso 9]><xml> <o:DocumentProperties> <o:Author>CHANDRASIRIP</o:Author> <o:Template>Normal</o:Template> <o:LastAuthor>CHANDRASIRIP</o:LastAuthor> <o:Revision>10</o:Revision> <o:TotalTime>2663</o:TotalTime> <o:LastPrinted>2002-07-09T08:30:00Z</o:LastPrinted> <o:Created>2002-07-09T08:36:00Z</o:Created> <o:LastSaved>2002-07-09T08:50:00Z</o:LastSaved> <o:Pages>50</o:Pages> <o:Words>6111</o:Words> <o:Characters>34838</o:Characters> <o:Company>Vodafone Group </o:Company> <o:Lines>290</o:Lines> <o:Paragraphs>69</o:Paragraphs> <o:CharactersWithSpaces>42783</o:CharactersWithSpaces> <o:Version>9.3821</o:Version> </o:DocumentProperties></xml><![endif]--> <!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>130</w:Zoom> <w:HyphenationZone>21</w:HyphenationZone> <w:DrawingGridVerticalSpacing>0 pt</w:DrawingGridVerticalSpacing> <w:Compatibility> <w:UseFELayout/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> <w:SpellingState>Clean</w:SpellingState> <w:GrammarState>Clean</w:GrammarState> </w:WordDocument></xml><![endif]--> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext="edit" spidmax="1027"/></xml><![endif]--> <!--[if gte mso 9]><xml> <o:shapelayout v:ext="edit"> <o:idmap v:ext="edit" data="1"/> </o:shapelayout></xml><![endif]--> <style> <!-- TD P { color: #000000 } H2 { color: #000000 } P { color: #000000 } H3 { color: #000000 } H4 { color: #000000 } A:link { color: #0000ff } A:visited { color: #0000ff } --> </style></head><body lang="en-GB" text="#000000" link="#0000ff" vlink="#0000ff"><h2 class="DocumentTitle">The Recommended Security Policy for GSM/UMTS Compliant Devices</h2><h4 class="TitleContinuation">Addendum to the Mobile Information Device Profile version 2.0</h4> <hr><h5 class="TitleContinuation"><i>Copyright 2002, Sun Microsystems, Inc. ALL RIGHTS RESERVED.</i></h5> <hr><h2 class="ChapterTitle">Preface</h2><p class="Paragraph">This document, <i>The Recommended Security Policy for GSM/UMTS Compliant Devices</i> is an addendum tothe <a href="http://jcp.org/jsr/detail/118.jsp">Mobile Information Device Profile (MIDP) version 2.0</a> for theJava<sup>TM</sup> 2 Platform, Micro Edition (J2ME<sup>TM</sup>).</p><p class="Paragraph">The terminology used herein is defined bythat specification except where noted. </p><h2 class="ChapterTitle">Who Should Use This Document</h2><p class="Paragraph">The audience for this document is the JavaCommunity Process (JCP) Expert Group that defined the MIDP,implementers of the MIDP, application developers using the MIDP,service providers deploying MIDP applications, and wireless operatorsdeploying the infrastructure to support MIDP devices. This documentspecifically targets network operators, manufacturers, andservice and application providers operating in GSM and UMTS networks.</p><h2 class="ChapterTitle">Scope of This Document</h2><p class="Paragraph">This addendum is informative.However, all implementations of MIDP 2.0 on GSM/UMTS-compliantdevices are expected to comply with this addendum.</p><p class="Paragraph"> MIDP 2.0 defines the framework forauthenticating the source of a MIDlet suite and authorizing theMIDlet suite to perform protected functions by granting permissionsit may have requested based on the security policy on the device. Italso identifies functions that are deemed security-vulnerable anddefines permissions for those protected functions. Additionally, MIDP2.0 specifies the common rules for APIs that can be usedtogether with the MIDP but are specified outside the MIDP. MIDP 2.0specification does not mandate a single trust model but rather allowsthe model to accord with the device trust policy. </p><p class="Paragraph">The purpose of this addendum is to extend the base MIDlet suitesecurity framework defined in MIDP 2.0 and to define the followingareas: </p><ul type="disc"> <li class="Bullet1">The required trust model for GSM/UMTS-compliant devices </li> <li class="Bullet1">The domain number and structure, as reflected in the policy file </li> <li class="Bullet1">The mechanism of reading root keys from sources external to the device </li> <li class="Bullet1">Capabilities allowed the applications within permissions defined by MIDP 2.0 and other JSRs </li> <li class="Bullet1">Application behaviour in the roaming network </li> <li class="Bullet1">Application behaviour when SIM/USIM is changed </li> <li class="Bullet1">The use of user permission types </li> <li class="Bullet1">Guidelines on user prompts and notifications </li></ul><h2 class="ChapterTitle">How This Specification Is Organized</h2><p class="Paragraph">This specification is organized as follows:</p><p class="Paragraph"> Sections 2 to 4 establish the relationshipbetween the policy file, different security domains, and requirementsconcerning certificate storage on smart cards. Section 5 specifiesthe function groups and identifies the permissions and the APIs thatneed to be protected using the MIDP 2.0 security framework. Sections6 and 7 specify rules that must be followed when permissions aregranted, and also requirements of user notifications. Finally Section8 specifies the MIDlet behaviour during roaming and after changingthe smart card.</p><h2 class="ChapterTitle">References</h2> <ol> <li class="List1"> Connected Limited Device Configuration (CLDC)<br> <a href="http://jcp.org/jsr/detail/30.jsp">http://jcp.org/jsr/detail/30.jsp</a> </li> <li class="List1"> Mobile Information Device Profile (MIDP) 2.0<br> <a href="http://jcp.org/jsr/detail/118.jsp"> http://jcp.org/jsr/detail/118.jsp</a> </li> <li class="List1"> HTTP 1.1 Specification<br> <a href="http://www.ietf.org/rfc/rfc2616.txt"> http://www.ietf.org/rfc/rfc2616.txt</a> </li> <li class="List1"> WAP Wireless Identity Module Specification (WIM) WAP-260-WIM-20010712-a<br> <a href="http://www.wapforum.org/what/technical.htm"> http://www.wapforum.org/what/technical.htm</a> </li> <li class="List1"> WAP Smart Card Provisioning (SCPROV) WAP-186-ProvSC-20010710-a<br> <a href="http://www.wapforum.org/what/technical.htm"> http://www.wapforum.org/what/technical.htm</a> </li> <li class="List1"> PKCS#15 v.1.1 <br> <a href="http://www.rsasecurity.com/rsalabs/pkcs/pkcs-15/"> http://www.rsasecurity.com/rsalabs/pkcs/pkcs-15/</a> </li> <li class="List1"> USIM, 3GPP TS 31.102: "Characteristics of the USIM applications" <br> <a href="http://www.3gpp.org/">http://www.3gpp.org</a> </li> <li class="List1"> RFC3280<br> <a href="http://www.ietf.org/rfc"> http://www.ietf.org/rfc</a> </li> </ol><p class="Paragraph"><h2 class="ChapterTitle">1 General</h2></p><p class="Paragraph">GSM/UMTS-compliant devices MUST follow thesecurity framework specified in the MIDP 2.0. Additionally, devicesthat support trusted applications MUST follow the PKI-basedauthentication scheme as defined in MIDP 2.0 specification. </p><h2 class="ChapterTitle">2 Domains in the Policy File</h2><p class="Paragraph">A domain is a way to differentiate betweendownloaded MIDlets based on their origin, and to grant or makeavailable to a MIDlet suite a set of permissions. A domain binds aroot certificate to a set of permissions. The permissions arespecified in the domain policy. A policy file or policy has as manyentries as there are domains available on the device. A domaincan exist only for root certificates that contain the<code>id-kp-codeSigning</code> extended key usage extension.</p><p class="Paragraph">Applications that authenticate to a trusted root key are treatedas trusted, and assigned to the corresponding protectiondomain. An application MUST be assigned to only one protectiondomain. A MIDlet suite cannot belong to more than one protectiondomain. </p><p class="Paragraph">The representation of domains in the device isimplementation-specific.</p><h2 class="ChapterTitle">3 Security Domains and the PermissionsFramework</h2><p class="Paragraph">This document specifies two differentrequirements as to how the MIDP permissions framework should be used,depending on the security domain an application executes.</p><p class="Paragraph"> </p><p class="Paragraph"><b>Manufacturer and Operator Domains</b> –Applications are responsible for prompting the user, using the MIDP2.0 permissions framework when accessing functions for which securitypolicies are specified in Tables 2 through 6 in this document.</p><p class="Paragraph"> </p><p class="Paragraph"><b>Third-Party and Untrusted Domains</b> –The device implementation is responsible for prompting the useraccording to the security policies specified in Tables 1 through 5 inthis document.</p><h4>3.1 Manufacturer Domain</h4><p class="Paragraph">The trusted root certificate of the device manufacturer is relatedto manufacturer applications and MUST have a domainidentified in the policy file. If a given device has no Manufacturerdomain but is capable of authenticating manufacturer-signedapplications (that is, it has a manufacturer root certificateinstalled) they will be authorized only as untrusted and will belongto the Untrusted domain.</p><p class="Paragraph">The Manufacturer domain cannot be deleted or modified by the useror any other party, except by a device-provisioned capability. If the manufacturer root certificate is updated, it MUST be mappedonto the same Manufacturer-domain policy file. If the manufacturerroot certificate is no longer present on the device, the Manufacturerdomain may be removed by a device-provisioned capability. </p><p class="Paragraph">Permissions in the Manufacturer domain are all marked as<i>Allowed</i> (see MIDP 2.0 for the definition). Permissions granted bythe Manufacturer domain as <i>Allowed</i> imply that downloaded andauthenticated manufacturer applications perform consistently withapplications pre-installed by the manufacturer in terms of securityand prompts to the user whenever events that require useracknowledgment occur. Manufacturer applications SHOULD seekpermission from the user when accessing security-vulnerable APIs andfunctions. Permissions defined by MIDP 2.0 and other APIs give theguidelines of which functions are seen as security-vulnerable andneed protection. It is expected that manufacturer applications willgive prompts and notifications to the user consistently regardingthese security-protected functions. The implementation MUST presentthe user with the <i>Subject</i> field of the root certificatecontaining the manufacturer root public key whenever a newapplication is installed in the Manufacturer domain. This usernotification MUST take place at application installation.</p><p class="Paragraph">The Manufacturer domain imposes no restriction on the capabilitiesspecified in the MIDP 2.0 and other JSRs. </p><h4>3.2 Operator Domain</h4><p class="Paragraph">The trusted operator root certificate MUST bemapped onto the policy file describing the Operator domain on thedevice. A device MUST support the policy file describing the Operatordomain.</p><p class="Paragraph">If a given device has no Operator domain but iscapable of authenticating operator-signed applications (that is, itis able to obtain an operator root certificate from a smart card)they will be authorized only as untrusted and will belong to the Untrusted domain. </p><p class="Paragraph">Trusted root certificates are read from the Certificate DirectoryFile (CDF) for trusted certificates [WIM]. Root certificates found inthe trustedCertificates file on the WIM are mapped onto the Operatordomain or onto the Trusted Third-Party domain,depending on the trustedUsage field in theCommonCertificateAttributes associated with the certificate[PKCS15]:</p><blockquote><p class="Paragraph">If the trustedUsage field is present and contains the OID for key usage“Operator Domain” (to be defined), then the certificateis to be mapped onto the Operator domain.</p><p class="Paragraph">If the trustedUsagefield is not present, or does not contain the OID for key usage“Operator Domain,” then the certificate is to be mappedonto the Trusted Third-Party domain.</p></blockquote><p class="Paragraph">Operator-trusted root certificates may be placedin the trustedCertificates Certificate Directory File (CDF) of a WIM,SIM, or USIM. If operator root certificates are stored directly on aSIM or USIM, that is, not under the WIM application, then they shallbe stored in the EF trustedCertificates CDF located underDF(PKCS#15), as defined by [SCPROV]. Operator root certificates canbe obtained only from the trusted CDF or equivalent directory (thecard holder can not update this directory) and not from anyother directory of the smart card. </p><p class="Paragraph">As operator root certificates are external to the device itself,and it is not known in advance which root certificates are availablefor authenticating downloaded operator applications at the time thesmart card can be changed, mapping of the operator root certificatesonto the Operator domain is implementation-specific. Any operatorroot certificate MUST, however, be mapped onto the same set of<i>Allowed </i>permissions in the Operator domain. The Operatordomain cannot be deleted or modified by the user or any other party,except by a device-provisioned capability. </p><p class="Paragraph">A signed and authenticated application MUST be authorized to the Operatordomain if the application was authenticated to the operator root public key.The operator root public key MUST be obtained from the trusted CDF of a currentlyinserted and enabled smart card and not from any other location on the smartcard or the device. The implementation MUST present the user with the <e>Subject</i>field of the root certificate containing the operator root publickey whenever a new application is installed in the Operator domain.This user notification MUST take place at applicationinstallation.</p><p class="Paragraph">Permissions in the Operator domain are all marked as<i> Allowed</i>(see MIDP 2.0 for the definition). Permissions granted by the Operator domain as <i>Allowed</i> imply that downloaded andauthenticated operator applications perform consistently with otherapplications installed by the operator in terms of security andprompts to the user whenever events that require user acknowledgmentoccur. Operator applications SHOULD seek permission from the userwhen accessing security-vulnerable APIs and functions. Permissionsdefined by MIDP 2.0 and other APIs provide guidelines as to whichfunctions are seen as security-vulnerable and need protection. It isexpected that operator-trusted applications will give prompts andnotifications to the user when accessing these security-protectedfunctions.</p><p class="Paragraph">The Operator domain imposes no restriction on the capabilitiesspecified in the MIDP 2.0 and other APIs unless stated otherwise.</p><p class="Paragraph">MIDlets installed in the Operator domain MUST store, along withthe application itself, a hash of the root certificate public keyunder which the signing certificate used to sign the application wasissued. The hash algorithm to be used is the following: starting withthe root certificate, compute the 20-byte SHA-1 hash of the value of⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -