Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 23
Текст из файла (страница 23)
Sign the MIDlet suite and incorporate the certificate into the JADfile.To sign a MIDlet suite the supplier of the suite needs to obtain apublic–private key pair either by generating a new pair or importing anexisting key pair. The NDS provides tools for doing this. These can beaccessed by selecting the Sign Application Package option (Figure 3.4)from the main panel. Clicking the New Key Pair button brings up thepanel shown in Figure 3.5.To generate the key pair, enter the appropriate details and clickthe Create button.
A new key pair will be generated and added tothe NDS key store. The newly-generated public key is incorporatedinto a self-signed certificate. We use this to obtain a suitable MIDletsuite code-signing certificate from an appropriate source (such as arecommended Certification Authority) that can be authenticated by a rootcertificate that ships with the device or is contained in the WIM/SIMFigure 3.4The application signing view of the NDS.104MIDP 2.0 AND THE JTWIFigure 3.5Creating a new public–private key pair in the NDS.card. Application developers and suppliers should contact the relevantdeveloper program of the device manufacturer or network operator toascertain the appropriate CA. We can then generate a Certificate SigningRequest (CSR) using our self-signed certificate and the Generate CSRoption in the NDS (Figure 3.4).
This generates a file containing the CSRthat can be saved to a convenient location. The contents of the CSRcan then be copied into an email to the recommended CA, requesting acode-signing certificate.When we have received the certificate from the recommended CA weneed to associate this with our key pair. The Import Certificate optionof the NDS associates the certificate with our key pair, identified by itsalias, and held in the key store. If the public key that we provided in theCSR, and now contained in the certificate, matches the public key of thekey pair held in the key store we should be notified accordingly and arenow ready to sign our MIDlet suite. To sign the MIDlet suite we simplyselect the Sign option (Figure 3.4) and choose the JAD file belongingto the MIDlet suite we wish to sign.
The MIDlet suite is now ready fordeployment on the target device. For further information on using theNDS refer to the User’s Guide contained in the NDS documentation.As mentioned earlier, the Sun J2ME Wireless Toolkit 2.0 (WTK 2.0)offers tools for creating and signing MIDlet suites. It also offers additionalfunctionality to test out signed MIDlet suites under emulation within theWTK 2.0 environment.
The WTK 2.0 provides a default trusted key pair(and an associated certificate recognized by the emulator) that can beused to install and bind a signed MIDlet suite to a trusted protectiondomain within the emulator environment. This then allows MIDlets in theMIDP 2.0105signed suite to run within the WTK 2.0 environment as trusted without thecost and hassle of obtaining and importing a certificate from a CA. Thisfeature is particularly useful for ensuring that the appropriate permissionsto access protected APIs have been requested in the JAD file in order forthe MIDlets within the signed MIDlet suite to install and run successfullyas trusted MIDlets.
It is important to remember that this feature of the WTK2.0 only simulates a real signing event. It is, of course, necessary to obtainand sign your MIDlet suite with a valid certificate from a recommendedCA before deploying your signed MIDlet suite onto a real device.3.3.2.10 Untrusted MIDletsAn untrusted MIDlet suite is an unsigned MIDlet suite, i.e. one whichdoes not include the MIDlet-Jar-RSA-SHA1 attribute in its applicationdescriptor (JAD), which has successfully been installed and bound to theuntrusted protection domain. MIDlets in untrusted suites execute withina restricted environment where access to protected APIs or functions maybe prohibited or allowed only with explicit user permission, depending onthe security policy in force on the device.
Unsigned MIDlet suites shouldnot request permissions explicitly in either the application descriptor orthe manifest. To ensure compatibility with MIDlets developed accordingto the MIDP 1.0 specification, the MIDP 2.0 specification demands thatthe untrusted domain must allow unrestricted access to the following APIs:• javax.microedition.rms• javax.microedition.midlet• javax.microedition.lcdui• javax.microedition.lcdui.game• javax.microedition.media• javax.microedition.media.controlFurthermore, the specification requires that the following APIs can beaccessed with explicit permission of the user:• javax.microedition.io.HttpConnection• javax.microedition.io.HttpsConnectionThe full list of permissions for the untrusted domain is device-specifichowever the MIDP 2.0 specification does provide a RecommendedSecurity Policy Document for GSM/UMTS Compliant Devices as anaddendum (with some clarifications added in the JTWI Release 1 SecurityPolicy for Untrusted MIDlet Suites).106MIDP 2.0 AND THE JTWIFinally, note that if a signed MIDlet fails authentication or authorization, it does not run as an untrusted MIDlet, but rather is not installed bythe AMS.
For more information on the MIDP 2.0 security model, includingmechanisms for certificate revocation, see the MIDP 2.0 specification.3.3.2.11 Recommended Security PolicyThe MIDP 2.0 specification provides a framework for the MIDP 2.0security model but does not itself mandate the device security policyin terms of specifying protection domains and permissions within thoseprotection domains. The MIDP 2.0 specification does, however, supplyan addendum to the specification that provides a recommended securitypolicy (RSP) for GSM/UMTS compliant devices. It is not a mandatory partof the MIDP 2.0 specification, but GSM/UMTS compliant devices areexpected to comply with it.In addition to the untrusted domain, the RSP defines a set of threeprotection domains (Manufacturer, Operator and Trusted ThirdParty) to which trusted MIDlet suites can be bound (and that a compliantdevice may support).For a trusted domain to be enabled there must be a certificate on thedevice, or a WIM/SIM, identified as a trust root for MIDlet suites in thatdomain, i.e.
if a signed MIDlet suite can be authenticated using that trustroot it will be bound to that domain.For example, to enable the Manufacturer protection domain themanufacturer must place a certificate on the device. This is identified asthe trust root for the Manufacturer domain.A signed MIDlet suite will be bound to the Operator domain ifit can be authenticated using a certificate found on the WIM/SIM andidentified as a trust root for the Operator domain.
A signed MIDletsuite will be bound to the Trusted Third Party protection domainif it can be authenticated using a certificate found on the device or on aWIM/SIM and identified as a trust root for the Trusted Third Partyprotection domain.The RSP defines its policy in terms of function groups rather thanindividual permissions. A function group is a set of functionally relatedpermissions, e.g. the Net Access function group contains all those permissions which relate to functionality that accesses the network, i.e. HTTP,HTTPS, datagram connection, secure socket and socket connections. Thepolicy defines whether each function group is Allowed or User.
Userpermission is requested in terms of the function group to which an individual permission belongs rather than the permission itself and the user’sresponse applies to all permissions in that function group.For more information on the Recommended Security Policy forGSM/UMTS Compliant Devices refer to the addendum contained inthe MIDP 2.0 specification.MIDP 2.0107As already mentioned, the recommended security policy is not amandatory requirement for a MIDP 2.0-compliant device. An implementation does not have to support the RSP in order to install signed MIDletsuites; it simply has to implement the MIDP 2.0 security model andsupport at least one trusted protection domain.3.3.2.12 Security Model on Symbian OS PhonesAt the time of writing the current MIDP 2.0 phones based on SymbianOS are the Sony Ericsson P900/P908 and the Nokia 6600.
The Sony Ericsson P900/P908 (Organizer firmware versions R2B02 or later) providessupport for a single trusted protection domain and therefore supports theinstallation of appropriately signed MIDlet suites. At the time of writingthe available firmware (version 3.42.1) on the Nokia 6600 only supportsthe untrusted domain, although Nokia have indicated future firmwarereleases will bring in support for the Manufacturer and TrustedThird Party protection domains (see Known Issues in the Nokia 6600MIDP 2.0 Implementation Version 1.2 at www.forum.nokia.com).With regard to the Recommended Security Policy for GSM/UMTSCompliant Devices Symbian’s MIDP 2.0 implementation does not initself implement the RSP, but instead provides the necessary frameworkfor licensees to implement the security policy. To implement the RSP,the associated trusted protection domains (Manufacturer, Operatorand Trusted Third Party) need to be associated with trust rootcertificates in the ROM or WIM/SIM card of the device.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
