Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 22
Текст из файла (страница 22)
To verify that thecertificate was issued by the CA, the certificate is digitally signed byMessageHash function(MD5)Sender'sMessage digestRSAcryptographicprocessDigitalsignatureFigure 3.1 Creating a digital signature: create a message digest using the hash functionand encrypt the digest using the sender’s private key.98MIDP 2.0 AND THE JTWIthe CA using its private key. The format of certificates used in X509.PKIis known as the X509 format.Of course, this raises the question of how the recipient of the certificateverifies the digital signature contained therein. This is resolved using rootcertificates or root keys.
The root certificate contains details of theidentity of the CA and the public key of the CA (the root key) and issigned by the CA itself (self-signed). For mobile phones which supportone or more trusted protection domains, one or more certificates willship with the device, placed on the phone by manufacturer or embeddedin the WIM/SIM card by the network operator. Each certificate will beassociated with a trusted protection domain, so that a signed MIDletthat is authenticated against a certificate will be bound to the protectiondomain associated with that certificate.3.3.2.4 Certification PathsIn practice, the authentication of a signed file using the root certificatemay be more involved than the simplified approach described above.The PKI allows for a hierarchy of certificate authorities (see Figure 3.2)whose validity can be traced back to a root certification authority, theuppermost CA in the hierarchy, also known as the trust anchor.In this case the root certificate on the device (the trust root) belongs tothe root certification authority in the hierarchy (the trust anchor) whichdirectly or indirectly validates all the other CAs in the certification path.The certificate supplied with the signed JAR file does not need to bevalidated (signed) by the trust anchor whose certificate is supplied withthe device, as long as a valid certification path can be established betweenthe certificate accompanying the signed JAR file and the root CA.It is not actually necessary for a device to have various self-signedtop-level certificates from CAs, manufacturers and operators installed.In practice, it only needs access to one or more certificates which areknown to be trustworthy, for example, because they are in ROM or securestorage on a WIM/SIM, or because the user has decided that they are.These certificates act as trust roots.
If the authentication of an arbitrarycertificate chains back to a trust root known to the device, and the trustroot is also identified as being suitable for authenticating certificates beingused for a given purpose, e.g., code-signing, web site identification, etc.,then the arbitrary certificate is considered to have been authenticated.3.3.2.5 Signing a MIDlet SuiteTo sign a MIDlet suite, a supplier must create a public–private key pair andsign the MIDlet JAR file with the private key.
The JAR file is signed using theRSA-SHA1 algorithm. The resulting signature is encoded in Base64 formatand inserted into the application descriptor as the following attribute:MIDlet-Jar-RSA-SHA1: <base64 encoding of Jar signature>MIDP 2.099Root CA(Trust Anchor)Operator 1CAISV 1ISV 2Operator 2CAISV 3ISV 4Manufacturer1 CAISV 5ISV 6Trust Anchor'sCertificateFigure 3.2 Applications from a variety of independent software vendors (ISVs) signed byvarious CAs and authenticated by a single trust root.The supplier must obtain a suitable MIDlet suite/code-signing certificate from an appropriate source, e.g., the developer program of a devicemanufacturer or network operator containing the identity of the supplierand the supplier’s public key. The certificate is incorporated into theMIDlet suite application descriptor (JAD) file.In the case of a certification path, we need to include all the necessarycertificates required to validate the JAR file.
Furthermore, a MIDlet suitemay include several certification paths in the application descriptor file(if, for example, the MIDlet suite supplier wishes to target several differentdevice types, each with a different root certificate).In Figure 3.3, we need to include certificates containing the publickeys belonging to CA 1, CA 2 and the Supplier.The root certification authority’s certificate (the root certificate) isavailable on the device. Using the root certification authority’s publickey, we can validate CA 1’s public key. This is then used to validate CA100MIDP 2.0 AND THE JTWICA 1's public key1683975610743CA 2's public key2092657883565Supplier's public key096365829672Signed:Root CA<793639120>Signed:CA 1<135932516>Signed:CA 2<803457622>jar file<169032678>Figure 3.3 Using a certification path to authenticate a signed JAR file.2’s public key, which is then used to validate the Supplier’s public key.The Supplier’s public key is then used to verify the origin and integrity ofthe JAR file.
The MIDP 2.0 specification defines an application descriptorattribute of the following format:MIDlet-Certificate-<n>-<m>: <base64 encoding of a certificate>Here <n> represents the certification path and has a value of 1 for thefirst certification path, with each additional certification path adding 1 tothe previous value (e.g. 1, 2, 3, . .
.). There may be several certificationpaths, each leading to a different root CA. <m> has a value of 1 forthe certificate belonging to the signer of the JAR file and a value 1greater than the previous value for each intermediate certificate in thecertification path.For the example shown in Figure 3.3, with just one certification paththe relevant descriptor attribute entries would have the following content:MIDlet-Certificate-1-1: <base64 encoding of Supplier's certificate>MIDlet-Certificate-1-2: <base64 encoding of CA 2's certificate>MIDlet-Certificate-1-3: <base64 encoding of CA 1's certificate>3.3.2.6 Authenticating a Signed MIDlet SuiteBefore a MIDlet suite is installed, the Application Management Software(AMS) will check for the presence of the MIDlet-Jar-RSA-SHA1attribute in the application descriptor and, if it is present, attempt toauthenticate the JAR file by verifying the signer certificate and the JARfile.
If it is not possible to successfully authenticate a signed MIDlet suite,it will not be installed.If the MIDlet suite descriptor file does not include the MIDlet-JarRSA-SHA1 attribute then the MIDlet can only be installed as untrusted.3.3.2.7 Authorization ModelA signed MIDlet suite containing MIDlets which access protected APIsmust explicitly request the required permissions. The MIDP 2.0 specification defines two new attributes: MIDlet-Permissions and MIDletPermissions-Opt for this purpose. Permissions that are required forMIDP 2.0101access to protected APIs that are essential to the operation of MIDlets(critical permissions) must be listed under the MIDlet-Permissionsattribute.
Permissions required to access protected APIs that are not essential to the operation of the MIDlets (in other words the MIDlets can runin a restricted mode without access to these APIs) are non-critical permissions and should be listed under the MIDlet-Permissions-Optattribute.The MIDlet-Permissions and MIDlet-Permissions-Opt attributes may appear in the JAD file or the manifest of a signed MIDlet suite,or in both, in which case their respective values in each must be identical,but only the values in the manifest are ‘protected’ by the signature of theJAR file.It is important to note that a MIDlet suite that has been installed astrusted will not be granted any permission it has not explicitly requestedin either the MIDlet-Permissions or MIDlet-Permissions-Optattributes, irrespective of whether it would be granted were it to berequested.The naming scheme for permissions is similar to that for Java packagenames.
The exact name of a permission to access an API or function isdefined in the specification for that API. For instance, the entry requesting permission to open HTTP and secure HTTP connections would beas follows:MIDlet-Permissions: javax.microedition.io.Connector.http,javax.microedition.io.Connector.httpsThe successful authorization of a trusted MIDlet suite requires that therequested critical permissions are recognized by the device (for instance,in the case of optional APIs) and are granted, or potentially granted, inthe protection domain to which the MIDlet suite would be bound, wereit to be installed. If either of these requirements cannot be satisfied, theMIDlet suite will not be installed.3.3.2.8 Protection DomainsA protection domain is a set of permissions determining access to protected APIs or functions.
A permission is either Allowed, in which caseMIDlets in MIDlet suites bound to this protection domain have automaticaccess to this API, or User, in which case permission to access the protected API or function is requested from the user, who can then eithergrant or deny access.
In the case of User permissions there are threeinteraction modes:• Blanket – as long as the MIDlet suite is installed, it has this permissionunless the user explicitly revokes it102MIDP 2.0 AND THE JTWI• Session – user authorization is requested the first time the API isinvoked and it is in force while the MIDlet is running• Oneshot – user authorization is requested each time the API isinvoked.The protection domains for a given device are defined in a securitypolicy file.
A sample security policy file is shown below:alias: net_accessjavax.microedition.io.Connector.http,javax.microedition.io.Connector.https,javax.microedition.io.Connector.datagram,javax.microedition.io.Connector.datagramreceiver,javax.microedition.io.Connector.socket,javax.microedition.io.Connector.serversocket,javax.microedition.io.Connector.ssldomain: Untrustedsession (oneshot): net_accessoneshot (oneshot): javax.microedition.io.Connector.sms.sendoneshot (oneshot): javax.microedition.io.Connector.sms.receivesession (oneshot): javax.microedition.io.PushRegistrydomain: Symbianallow: net_accessallow: javax.microedition.io.Connector.sms.sendallow: javax.microedition.io.Connector.sms.receiveallow: javax.microedition.io.PushRegistryUser permissions may offer several interaction modes, the user beingable to select the level of access.
For instance, the following line indicatesthat the API or functions defined under the net_access alias have Userpermission with either session or oneshot interaction modes, the latterbeing the default.session (oneshot): net_access3.3.2.9 The Security Model in PracticeIn this section we go through the steps involved in producing a signedMIDlet suite. We shall illustrate this process using the tools provided bythe Nokia Developer’s Suite (NDS) for J2ME 2.0 – a set of tools aimedat developers developing for Nokia’s MIDP phones, including Series 60devices. The Sun J2ME Wireless Toolkit 2.0 offers similar capabilities.The basic steps in producing a signed MIDlet suite are listed below:1.Obtain (or generate) a public–private key pair.2.Associate the key pair with a code signing certificate from a recommended CA.MIDP 2.01033.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
