Programming Java 2 Micro Edition for Symbian OS 2004 (779882), страница 21
Текст из файла (страница 21)
Future releases (and devices based upon them) will beJTWI-compliant.The following sections will cover the component APIs that are part ofJTWI Release 1.3.2 The CLDC on Symbian OSThe Connected Limited Device Configuration (CLDC) was introduced inChapter 1. In this section we will briefly describe the implementations ofCLDC available on Symbian OS.Symbian’s MIDP 1.0 offering runs on top of a port of Sun’s CLDC1.0-based Virtual Machine (VM – also known as the KVM).
Like earlydesktop Java VMs, this CLDC 1.0 VM is a pure interpreter written in theC programming language. Symbian OS supports a subset of the C STDLIB(originally written to support the implementation of Symbian’s first JDK1.1.6-based Java offering in Symbian OS Version 5), making porting CLDC1.0 a relatively straightforward task.
Conscious of the performance overhead inherent in interpreted environments, Symbian integrated ARM’sVMA Technology Kit (VTK) into the CLDC 1.0 implementation. VTKprovides a number of optimizations for the ARM architecture, includinga re-write of the bytecode interpreter loop in ARM assembler (insteadof the original C code). These optimizations provide very significantperformance enhancements compared with standard KVM implementations, giving Symbian’s CLDC 1.0/MIDP 1.0 implementation best-in-classperformance.With the release of Symbian OS Version 7.0s, Symbian enhancedits VM offering for MIDP 2.0 by providing a port of Sun’s new CLDC1.0 Hotspot Implementation VM (CLDC HI, also known by its codename of Monty). CLDC HI is a highly optimized VM incorporating many advanced technologies previously only available in desktopJava VMs, such as Dynamic Adaptive Compilation (DAC).
CLDC HIdelivers nearly an order of magnitude better performance than thestandard KVM (see The CLDC Hotspot Implementation Virtual Machineat http://java.sun.com) while still retaining the small memory footprintrequired by mobile phones. This gives Symbian’s CLDC HI/MIDP 2.0Java platform the performance to run demanding applications that takefull advantage of the additional functionality offered by MIDP 2.0 andthe additional optional APIs. The MIDP 2.0 implementation on theSony Ericsson P900/P908 and the Nokia 6600 runs on top of CLDC1.0 HI.MIDP 2.095In future releases, Symbian OS will provide an implementation of Sun’sCLDC 1.1 HI VM. As well as offering further performance enhancementscompared with CLDC 1.0 HI, this brings in floating point support (astandard part of the CLDC 1.1 specification).3.3 MIDP 2.03.3.1 New Features in MIDP 2.0MIDP 2.0 was introduced in the previous chapter.
In this section we shalllook in more detail at the features available in MIDP 2.0.Although MIDP 1.0 can be regarded as a success story, with widespreadadoption of the technology within the wireless industry, it was soonrealized that MIDP 1.0 on its own was too restrictive. MIDP 1.0 wastargeted at severely resource-constrained CLDC devices. The MIDP APIset was targeted at the lowest common denominator of functionality likelyto be available on mobile phones.
For these highly-constrained devices, alightweight security model was required. MIDP 1.0 adopted the sandboxsecurity model: an application runs in a closed environment and can onlyaccess APIs defined in the configuration and profile (or any OEM-specificlibraries that ship with the device).The influence of Moore’s Law is, however, felt in the wireless space.Once MIDP 1.0 was adopted as a standard for wireless devices, it wassoon being ported to devices with far richer native functionality than thelowest common denominator phone that the MIDP 1.0 specification wasoriginally designed for.
For instance, Symbian OS provides a very richnative API set, the majority of which are not accessible to MIDlets.The solution was the formation of the MIDP 2.0 expert group (withSymbian a member) and a proliferation of J2ME JSR expert groups definingoptional APIs, in the majority of which Symbian participates. The MIDP2.0 expert group released the final specification in November 2002,resulting in the following major additions to the profile:• a more fine-grained security model• extended networking• a push registry• user interface modifications• the Game API• the Media API.We will now look at these additions in more detail.96MIDP 2.0 AND THE JTWI3.3.2 Security Model3.3.2.1 OverviewThe MIDP 2.0 security model is built on two concepts: trusted MIDletsuites and protected APIs. Trusted MIDlet suites are those whose originand integrity can be trusted by the device on the basis of some objectivecriterion.
Protected APIs are APIs to which access is restricted, with thelevel of access being determined by the permissions (Allowed or User)allocated to the API. A protection domain defines a set of permissionswhich grant, or potentially grant, access to an associated set of protectedAPIs. An installed MIDlet suite is bound to a protection domain, therebydetermining its access to protected APIs. A MIDP 2.0 device must supportat least one protection domain, the untrusted domain, and may supportseveral protection domains, although a given MIDlet suite can only bebound to one protection domain.
The set of protection domains supportedby an implementation defines the security policy.If installed, an unsigned MIDlet suite is always bound to the untrusteddomain, in which access to protected APIs may be denied or requireexplicit user permission.
Since a requirement of the MIDP 2.0 specification is that a MIDlet suite written to the MIDP 1.0 specificationruns unaltered in a MIDP 2.0 environment, MIDP 1.0 MIDlets areautomatically treated as untrusted.3.3.2.2 Trusted MIDlet SuitesThe mechanism for identifying and verifying that a signed MIDlet suiteshould be bound to a trusted domain is not mandated by the MIDP2.0 specification but is left to the manufacturer of the device and otherstakeholders with an interest in the security of the device, for example,network operators in the case of mobile phones. The specification does,however, define how the X.509 Public Key Infrastructure (PKI) can beused to identify and verify a signed MIDlet suite.3.3.2.3 The X.509 PKIThe Public Key Infrastructure is a system for managing the creationand distribution of digital certificates.
At the heart of the PKI lies thesystem of public key cryptography. Public key cryptography involvesthe creation of a key pair consisting of a private key and a publickey. The creator of the key pair keeps the private key secret, but canfreely distribute the public key. Public and private key pairs have twoprincipal uses: they enable secure communication using cryptographyand authentication using digital signatures. In the first case, someonewishing to communicate with the holder of the private key uses thepublic key to encrypt the communication. The encrypted communicationis secure since it can only be decrypted by the holder of the private key.MIDP 2.097In the current context, however, we are more interested in the seconduse of public–private key pairs, enabling authentication using digitalsignatures.
A digital signature is an electronic analogy of a conventionalsignature. It authenticates the source of document and verifies that thedocument has not been tampered with in transit. Signing a documentis a two-stage process: a message digest is created that is a uniquerepresentation of the contents of the document; the message digest is thenencrypted using the private key of the sender (see Figure 3.1).The receiver of the document then uses the public key of the sender todecrypt the message digest, creates a digest of the received contents, andchecks that it matches the decrypted digest that accompanied the document.
Hence, a digital signature is used to verify that a document wasactually sent by the holder of the private key, not some third party masquerading as the sender, and that the contents have not been tamperedwith in transit.This raises the issue of key management and how the receiver of apublic key can verify the source of the public key. For instance, if I receivea digitally signed JAR file I will need the public key of the signer to verifythe signature, but how do I verify the source of the public key? The publickey itself is just a series of numbers, with no clue as to the identity of theowner.
I need to have confidence that a public key purporting to belongto a legitimate organization does in fact originate from that organizationand has not been distributed by an impostor, enabling the impostor tomasquerade as the legitimate organization, signing files using the privatekey of a bogus key pair. The solution is to distribute the public key in theform of a certificate from a trusted certificate authority (CA).A certificate authority distributes a certificate that contains details of aperson’s or organization’s identity, the public key belonging to that personor organization, and the identity of the issuing CA. The CA vouches thatthe public key contained in the certificate does indeed belong to theperson or organization identified on the certificate.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
