Programming mobile handheld devices
written by Jon Berg <jon.berg|a|turtlemeat.com>

Security
Security in mobile computing
Security is an important issue in mobile computing. On handheld mobile computer devices you have less control over the network environment you are using than on a stationary computer at home. A more loosened security policy on your home network or inside a wired private corporate network can be acceptable since you will have more control over the infrastructure. Network and system security are important in stationary systems, but the environment is more static and more controllable. The complete setup of the system can be analyzed and security can be evaluated to give system that is relatively secure. This evaluation will hold as long as the system or network is not changed.

There are several security issues with mobile applications. When it comes to applications on mobile devices, you loose the control over the network you are communicating over. You do not know if there are other peers on the network that may be potential hackers. You will often change to new networks as you are moving around. Much of the communication in such a scenario is done wireless and that increases the potential for sniffing the information being sent.

We do not want the fact that it is a mobile device limit the possibilities of applications we can create. Security is an important issue if we want to create e-banking applications or e-commerce. Such applications need tight security since it involves sensitive information and are tempting targets for fraud and theft.

Securing the communication channel
A lot of the security problems caused by communication over insecure networks can be avoided by securing the communication channel. This is done by using HTTPS. HTTPS offers encryption, source authentication, and data integrity. Support for HTTPS has become standard in MIDP v2.0.

The great thing about using HTTPS is that it can be used as a carrier for any type of data. It is also simple to use for the application developer to use both on the client side and the server side. On the client side you must use the HttpsConnection class to open
a connection instead of the HttpConnection wich is used for regular HTTP. On the server side you must configure the server for https. It is very convenient that the server applications do not have to be programmed in any special way to use HTTPS. Once the web server is configured the old web applications on that server is communicating using HTTPS. That is a big plus since the cost of securing a application is very low when you do not have to do any extra programming or modification to the server application when developing for or moving to HTTPS.

Better security model for mobile commerce application
The channel based security model seems sufficient for most mobile applications today. Although the channel based security model have some problems that could make them unsuited in future mobile commerce applications. The problems are: 1) Direct connection must be established. This is a problem in systems where you want the connection to be modified through intermediate services. 2) All content is encrypted. It could be that some of the things that are transmitted is not sensitive and is not crucial to encrypt. Encrypting everything takes more processing resources. 3) HTTPS is inflexible. You can not define the level of security you want. It lacks methods for handshake and key exchange.

Single Sign On
In a distributed environment a nice feature is to have single sign on. You authenticate at one place and you get a token you can use to authenticate yourself at multiple services. It is useful for the user when browsing information, because it hard to remember a lot of username and passwords and it is annoying to type them in all the time. This is also useful in scenarios where you want the application to aggregate information from multiple places and then generate some report to the user. The application will not need multiple login and usernames to access these servers. Without Single Sign On the device must store the login and password for all the services to application will contact. Or the user must be involved and type the username and password for each logon, which will seem very annoying in the long run. The most adapted technologies for Single Sign On is Microsoft .Net Passport and Sun Microsystems' Liberty Alliance Project.

Encryption of sensitive data
When storing sensitive data such as passwords on the device it is important to store this safely. Example of applications where data encryptions is useful is a user is downloading sensitive data and storing them on the device. The data could be your bank statement, and encrypting it will keep it safe in case of theft. Since the storage on the device is limited, a service on the internet could be used as an online storage service. All the data stored through this service would be rational to encrypt since the data could be sensitive and one would not want the people that provided the service to read your files. The passwords used to access other services as discussed above would be rational to encrypt when stored on the device. A master password could be used when you started the application to decrypt all the passwords stored on the device.

Data encryption on mobile devices is a challenge since the device offers limited memory and processing power when data encryption often requires a lot of memory and processing power. Currently data encryption in MIDP devices is done through
3rd. party optional modules. Two such modules are Phoas and The Bouncy Castle Crypto APIs. Phaos is a commercial implementation and The Bouncy Castle Crypto APIs is an open source implementation. In the future there will most certain be larger generic support for cryptography in the J2ME.

Java Sandbox Model
The Java Sandbox Model has proven to be a good security model to protect the integrity of the device, and separate programs from each others. This model has been adapted to MIDP. It runs very much like Java Applets does in web browsers. One MIDlet can not affect other running MIDlets directly. This separation also applies to the record store (RMS) and to network connections. The restriction of network connections makes sure that connections can only be setup to the server where the MIDlet originated from, similar as in Java Applets [14]. Several MIDlet can share the same RMS data if they are in the same suite. A suite is a set of MIDlets packed together in one jar-file. [15].

Linux
Setup Software Raid 1 with LVM

Turtlmeat.com 2004-2010 ©