Date post: | 29-Nov-2014 |
Category: |
Documents |
Upload: | journal-of-mobile-embedded-and-distributed-systems-jmeds |
View: | 88 times |
Download: | 1 times |
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 50
Java and Symbian M-Application Distribution Frameworks
Marius POPA, Mihai DOINEA Faculty of Cybernetics, Statistics and Economic Informatics
Department of IT&C Technologies Academy of Economic Studies Bucharest, Romania
[email protected], [email protected]
Abstract: The paper has three sections. First section is intro in Symbian M-Applications distribution framework. The second section presents Java distribution framework and API for various IT&C solutions. The third section is reserved for conclusions and ideas for future developments. Key-Words: m-applications, distribution frameworks, secure distribution.
1. Symbian OS Distribution Model
The present version for Symbian OS is version 9. Figure 1 presents the architecture of Symbian OS version 8.
Fig. 1 Symbian OS Architecture [5]
The main modules in the symbian architecture are:
The base module – includes the kernel og Symbian OS, the file server which manages the file system of the OS and drivers written by the
various mobile components vendors.
Telephony module – includes the voice and data communication modulation/demodulation, encoding/decoding and encrypting/decrypting.
This module can implement EDGE, CDMA, HSUPA or WiMAX technologies.
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 51
Security Module – provides API for managing digital certificates,
cryptography and software installation secure framework. Application framework – provides API for graphical user interface.
Multimedia module – helps the developer to create in a reliable manner (using camera or microphone) images, sounds and graphics in various
formats.
Communication infrastructure – provides API for TCP/IP protocols and WAP radio stack.
Personal Area Networking Module – provides API for handling Bluetooth, USB or Infrared sessions.
Messaging Module – helps the developers to create, modify and delete SMSs, MMSs, MP3s and e-mail files for the Symbian OS.
Java Virtual Machine – offers configurations and profiles with API libraries in Java Micro Edition programming language for accessing the most of the
above modules (configurations and profiles will be discussed on the Java
Mobile sections).
The natural programming language for Symbian OS is C++ but very powerful Java Virtual Machine implementations have been done for Symbian OS 8.0 and 9.0. Even so
there are still functionalities and features of Symbian OS which can be accessed exclusively from C++. For the security of installation of the Java application the
framework proposed by Sun Microsystem is respected. For native Symbian applications developed in C++ the evolution of enhanced platform security was the following:
First was the original Symbian OS perimeter security model – which
checked the native applications at the install time and guides the end-user through installation dialogs if they allowed sensitive actions of the
applications such as network connections, access to contacts profiles, access to the personal folder, etc;
Second, in 2004, it was introduced the Symbian Signed – it is a framework which helps the developer to build confidence against industry-agreed test
area; Third, Symbian OS 8.0 introduced easier integration of anti-virus
solutions;
Fourth, Symbian OS 9.0 introduces enhanced runtime security at platform level including API access management.
Figure 2 shows the Symbian Signed framework used for building confidence against
industry-agreed test area.
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 52
Figure 2 Symbian Signed Framework [6]
The flow in order to produce a secure and realible Symbian native application (Figure 2)
is: 1. Developers get ACS Publisher ID Certificate from a Certification Authority such
as VeriSign. 2. Developers sign native applications (SIS files) with ACS Publisher ID.
3. Developers submit signed application for testing purposes to a Symbian Authorized Test House.
4. The Test House validates SIS signed file (native application) against a testing plan.
5. If the tests were successful, the application is passed to the Certification
Authority such as VeriSign. If the tests were not successful the developer is advised to change/debug and re-submit the application according with the
observations made by the Test House. 6. Certification Authority – VeriSign – removes ACS Publisher ID Certificate and
replaces with a digital content certificate chained ti unique Symbian Signed Root – Symbian B.
7. The signed application is returned to the developer. 8. Application can be installed on the mobile devices.
9. Optionally the signed application can be stored Symbian catalog and therefore
can display “Symbian OS” logo.
The proposed model has some features that are important for the companies which choose to do a similar model. The features are:
Applications that do not access Capabilities (almost 60% of APIs) do NOT need to be Symbian Signed to run. These applications run effectively
within an “unsigned box”. Software installer can allow Symbian Signed applications to run without
individual user permissions.
Access to some Capabilities via digital signatures and through API. Symbian Signed offers a generic, standard program for granting access
and other programs/models are possible. Symbian Signed will not sign against all Capabilities – some are controlled
directly by operator/phone manufacturer. Symbian Signed issues “Protected Range” UIDs and Developer Certificates.
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 53
Symbian OS is the most powerful, robust, scalable and reliable operating system for the
mobile devices and it is the first which provides reliable security mechanism for the native applications.
2. Java Micro Edition Distribution Model
Java Micro Edition Patform is a set of API, tools (including compilers and debuggers) and specifications which help developers to deploy Java applications on the mobile devices.
Mandatory, the mobile devices run an operating system which implements a Java Virtual Machine according with Sun Microsystem specifications.
Figure 3 presents the target of Java Micro Edition Platform. The target is defined by smart phones, PDAs, Digital TV Boxes and other “embedded systems” which implements
the Java Virtual Machine.
Fig. 3 Java Micro Edition Platform [2]
Depends on the mobile device the manufacturer chooses to implement a light version of
Java Virtual Machine – KVM – Kilo Virtual Machine or the entire JVM. The JVM is the RAM
memory occupied and the mechanisms provided by the Java interpretor when is launched by the mobile operating system (usually when launch an Java Microedition
ARchive file). For Java Micro Edition Platform the standardization process is done by JCP – Java Community Process. JCP is responsible to issue JSRs – Java Specification
Request. Each JSR defines a set of optional packages and each optional package defines a library (a java archieve file). A JSR may be for configurations, profiles or additional
Java Micro Edition Platform features.
The differences between configuration and profiles are made by the features provided
within Java Micro Edition Platform: Configuration – is materialized as Java library (a Java Archive file)
o Defines Java language features and limitations o Defines the byte code restrictions, JVM features and limitations
o Defines basic classes Profile – is materialized as Java library (a Java Archive file)
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 54
o Defines advanced classes hierarchy and API for various features
such as input/output, user interface, permanent storage, games, Crypto-PKI programming.
o Defines a security model for applications o Defines the life cycle of an application for the specific profile.
There are the following main configurations and profiles: Configurations
o CDC – Connected Device Configuration – is a kind of small size Java Standard Edition with all fundamental features but with less or
different APIs. o CLDC – Connected Limited Device Configuration – is a limited
flavour of Java, in the middle of Java Standard Edition and Java Card with no reflection, no dynamic class loading and restricted
multithreading.
Profiles o For CDC
PP – Personal Profile FP – Personal Basis and Foundation Profile
o For CLDC MIDP – Mobile Information Device Profile
IMP – Information Module Profile
The most used configuration is CLDC 1.0 with MIDP 2.0 in mobile phones environments.
Of the profiles designed for CLDC, the Mobile Information Device Profile (MIDP) is the most prevalent. MIDP 2.0 has superseded MIDP 1.0 in capability, but many devices still
support only MIDP 1.0, so most developers can't afford to ignore the older version. At the time of this writing, MIDP 3.0 is being defined in the Java Community Process (JCP).
In addition, the new Information Module Profile (IMP) promises to do for "headless devices" such as vending machines, industrial devices, and security systems what MIDP
has done for smart cell phones and low-end PDAs. There are two versions of IMP; version 1.0 is based on MIDP 1.0, and the Next Generation (NG) version is based on
MIDP 2.0. The next table summarizes the device requirements for MIDP and IMP.
The Configurations and profiles are presented in figure 4:
Fig. 4 Midlet is the name of applications for MIDP [3]
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 55
The name of an application for CLDC with MIDP is MIDlet. In addition to configurations
like CLDC and profiles like MIDP, the JCP has defined a more comprehensive specification for developing applications for mobile handsets, called Java Technology for the Wireless
Industry – TWI. Adopted by all major handset manufacturers, JTWI defines a common architecture and programming interface for wireless handsets based on these
specifications:
CLDC 1.0 (JSR 30) or CLDC 1.1 (JSR 139) MIDP 2.0 (JSR 118)
The Wireless Messaging API (WMA, JSR 120) The Mobile Media API (MMAPI, JSR 135)
The differences between profiles are in the following table:
In terms of concentric circles the JTWI is included in the following set of specifications MSA 1 and MSA 2 – Mobile Service Architecture – figure 5.
Fig. 5 Set of specifications for smart phones [3]
Figure 6 contains the complet set of specifications for JTWI 1.0, MSA 1 and MSA 2.
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 56
Fig. 6 JTWI, MSA 1 and MSA 2 set of specifications [7]
It is obvious that the most important specifications for MSA 2 are: JTWI – Java Telephony for Wireless Industry
o CLDC 1.1 (JSR 139) – Connected Device Configuration – defines
the configuration for the mobile smart phones o MIDP 2.0 (JSR 188) – Mobile Information Device Profile – defines
the profile for the mobile smart phones over the CLDC configuration o WMA 1.1 (JSR 120) – Wireless Messaging API – first designed to
allow the Java Programmers to send SMS or MMS. o MMAPI (JSR 135) – Mobile Media API – is targeted to fulfill the
needs for the control and simple manipulation of sound and multimedia for applications in mobile devices, with scalability to
other J2ME devices.
MSA 1 – Mobile Services Architecture subset o PDAOP (JSR 75) – Personal Digital Assistants Optional Packages
defines API for accessing the file system of the mobile OS and PIM – Personal Information Management (Agenda/Contacts)
o Bluetooth and OBEX (JSR 82) – This spec will include basic support for, at least, the following Bluetooth protocols: RFCOMM, OBEX,
and Service Discovery protocols. Additional protocol support may
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 57
be added in future versions. The spec is primarily targetted at
native Bluetooth protocols. (There are existing Java IP APIs which can be used to access IP networks from IP enabled Bluetooth
devices.) o 3D Graphics (JSR 184) – This proposal specifies a lightweight,
interactive 3D graphics API.
o WMA 2.0 (JSR 205) – Wireless Messaging API – the following technologies will be addressed: Short Message Service (SMS),
Multimedia Message Service (MMS), Unstructured Supplementary Service Data (USSD), Cell Broadcast Service (CBS).
o SVG (JSR 226) – Scalable 2D Vector Graphics API – This specification will define an optional package API for rendering
scalable 2D vector graphics, including image files in W3C Scalable Vector Graphics (SVG) format.
MSA 2 – Mobile Services Architecture
o Web Services (JSR 172) – offers Java API for creating web services clients and XML parsing.
o SATSA (JSR 177) – Security and Trust Services API – provides API for intercommunicates with SIM – Subscriber Identity Module and
for interacting with Crypto Public Key Infrastuctures. o Location (JSR 179) – provides API for the mobile smart phones
which have GPS devices. o SIP (JSR 180) – Session Initiation Protocol – provides API to handle
with SIP signaling for various type of services such as voice over IP
(VoIP) and multimedia sharing. o CHAPI (JSR 211) – Content Handler API – The purpose of this JSR
is to define an optional package for an API and associated model permitting the invocation of Java Micro Edition Applications to
handle actions on Uniform Resource Identifiers (URI) based on the MIME-type or scheme. For example, A MIDP MIDlet or a Personal
Profile Xlet or main can be registered to handle a MIME type and appropriately display its content. The model will allow the
application managment software of the device to control the
execution of the applications to conserve resources and to enforce the security policy of the device and the Java runtime. For instance,
a SMS could launch the HTTP browser application. o AMMS (JSR 234) – Advanced Multimedia Supplements – offers API
to: access for camera specific controls like visual settings (brightness, contrast), flashlights, lighting modes and zooming;
proper access to radio and other channel/frequency based media sources including RDS (radio data system); access to advanced
audio processing capabilities like equalizer, audio effects, artificial
reverberation and positional 3D audio. Dynamically changing audio resources are adressed as well and media output direction. For
example, the ability to choose whether the audio is played out from speaker of from headset.
o I18N (JSR 238) – Internationalization – helps the programmer to offer various multi-language user interfaces using a simple
framework. o Payment (JSR 229) – The purpose of this JSR is to define the
following: a generic optional API to initiate payment transactions
and in addition the syntax for the description of the associated provisioning data, enabling API implementers to support different
payment instruments. Both will allow 3rd party developers to build applications with control of features and services that are
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 58
chargeable. The JSR API may include methods for: Requesting
payment transaction; Requesting feature and service price management; Payment service availability. The provisioning data
definitions take care that service providers and payment service providers can select a suitable set of payment instruments
provisioned for applications during the application deployment
time. Primarily payment instruments addressed will be: operator charging; stored value accounts; 3rd party payment service
providers.
All the JSRs are organized as mandatory or optionally recommendations for the companies which implements Java Virtual machines on the mobile smart phones or
mobile devices.
In order to provide a secure and sclable environment for Java application distribution
Sun Microsystem propose a general model for developing mobile applications for Java Virtual machines from the mobile smart phones.
The Java Micro Edition Security Framework is presented in figure 7:
Fig. 7 Java Micro Edition Security Framework [7]
The development phase includes application design, Java source code writing and testing
procedures which are internal to each company. After the testing done by the
development company, it should use a embedded root certificate owner to sign its application. This thing implies to accept the root certificate contract and criterias in order
allow application to have higher permissions. There are two priviledged sets of permissions, based on the owner identity of the root certificate: device
manufacturer/operator and trusted third parties.
After the testing and signing procedures the applications goes in market and finally gets to the end-user.
4. Conclusions The paper described a framework for mobile application security. Some types of
solutions for mobile services were presented.
Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009
ISSN 2067 – 4074
Page 59
Now, some standard solutions regarding the security framework of the mobile
applications are included in mobile operating systems – OS, like Symbian OS, Linux ALP and Windows Mobile.
The mobile software development can be done using the tools included in Java Micro
Edition platform. This software is running in an OS that implements a Java Virtual
Machine – JVM, in accordance with Sun specifications.
References
[1] Larry Berkin, “An insight into ACCESS Linux Platform” Presentation, Orange Mobile Conference, Cadiz, Spain 2006
[2] Rémy CRICCO & Cédric HUET, “A smarter approach to secure Java mobile applications” Presentation, Orange Mobile Conference, Opio, France 2005
[3] Cuihtlauac Alvarado, “Orange and Open Mobile Platform Standardization” Presentation, Orange Mobile Conference, Cadiz, Spain 2006
[4] David Goon, “Windows Mobile 5.0 Operating System – What's New” Presentation, Orange Mobile Conference, Opio, France 2005
[5] http://developer.symbian.com/main/index.jsp
[6] Martin de Jode, “Symbian OS v9 and Platform Security: an overview” Presentation, Orange Mobile Conference, Opio, France 2005
[7] Sun Microsystems, “Java Platform Overview” Presentation, Orange Mobile Conference, Cadiz, Spain 2006
[8] http://ava.sun.com – tutorials section