Journal of Mobile, Embedded and Distributed Systems, vol. I, no.

1, 2009 ISSN 2067 4074

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 marius.popa@ase.ro, mihai.doinea@ie.ase.ro
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.

Page 50

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074 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.

Page 51

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074

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. Page 52

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074 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)

Page 53

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074 o Defines advanced classes hierarchy and API for various features such as input/output, user interface, permanent storage, games, Crypto-PKI programming. Defines a security model for applications Defines the life cycle of an application for the specific profile.

o o

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]

Page 54

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074 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. Page 55

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074

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 Page 56

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074 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 Page 57

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074 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.

Page 58

Journal of Mobile, Embedded and Distributed Systems, vol. I, no. 1, 2009 ISSN 2067 4074 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] [2] [3] [4] [5] [6] [7] [8] Larry Berkin, An insight into ACCESS Linux Platform Presentation, Orange Mobile Conference, Cadiz, Spain 2006 Rmy CRICCO & Cdric HUET, A smarter approach to secure Java mobile applications Presentation, Orange Mobile Conference, Opio, France 2005 Cuihtlauac Alvarado, Orange and Open Mobile Platform Standardization Presentation, Orange Mobile Conference, Cadiz, Spain 2006 David Goon, Windows Mobile 5.0 Operating System What's New Presentation, Orange Mobile Conference, Opio, France 2005 http://developer.symbian.com/main/index.jsp Martin de Jode, Symbian OS v9 and Platform Security: an overview Presentation, Orange Mobile Conference, Opio, France 2005 Sun Microsystems, Java Platform Overview Presentation, Orange Mobile Conference, Cadiz, Spain 2006 http://ava.sun.com tutorials section

Page 59