Skip to main content

security feature in j2me

4 replies [Last post]
vijay_gopal
Offline
Joined: 2008-04-25
Points: 0

Can any tell about the security flaw in j2me? I read in few articles and came to know that j2me uses https and ssl to provide secure connection. But after going through the demerits of ssl i beleive that using ssl might balk the performance of the mobile since its heavy weight cryptography processes uses more resources.
If one has to provide security to j2me without using ssl or https can i use shttp for j2me using MIDP2.0...And can anyone tell me whether shttp is better than http?Please reply fast its urgent....

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
sfitzjava
Offline
Joined: 2003-06-15
Points: 0

I would say there are no security flaws in JavaME. There was once a PHD that took 4 months to put together a trojan attack, but it required an old version of CLDC 1.0, and some very specific requirements to hack the information on the device.

Now as for HTTPS/SSL, these protocols are fine to use, however have an issue since some devices do not support commonly available CA (certificate authorities). Typically Verisign is the only CA that is on all devices. Most notably is Motorola's lack of any other cert support.
(this may have changed since I ran into it in '04).
While using SSL will slow things down compared to no encryption, slow and secure is better than fast and hackable I would think. :)

Typically folks have used Bouncy Castle's implementation to encrypt over HTTP to avoid the issues with certificates. But this adds some size and performance hits. There is a company that announced in late 07 an encryption product call EncryptME that is small, fast, and easy to use. see Masabi.com for info.

Now for some information on secured connections with cellphones:
From the phone to the operator the connection is already secured. I think they use a 3-DES or an AES4 type, which is pretty good. However that is only to the point that it gets out of the operators network. So if you have a connection into the operators network or through a gateway on the operators network, and don't use any public internet then you really don't need heavy encryption. (provided you trust the operator, and the gateway providers.)

Hope that helps,
-Shawn

vijay_gopal
Offline
Joined: 2008-04-25
Points: 0

Thank you for your reply which was quite helpful.So you mean to say that there aren't any flaws in j2me security? I will post you a link which says that j2me has network and security flaws..Would youplease suggest something on that..
Here is the link
http://www.ericgiguere.com/j2me/security.html

sfitzjava
Offline
Joined: 2003-06-15
Points: 0

In reading this link I must be missing where Eric is saying that the protocols are flawed. I do see his concerns that there are not some automatic and simpler API's to protect the information. But these issues are there due to flaws in the MIDlet's design.
Looking at the security of JavaME we can address the concerns that Eric points out (all very valid) and see how they can be addressed.

Loss of the device: Most developers assume that because you have the device in your hand that you must be the owner. Not true, the best way to protect the data is request a pin code that the user must key in to enter your app.

RMS is wide open: You can use the above mentioned pin key to encode your data. However you must be careful that if you allow for the pin to change that you correctly re-encode all data. However is RMS hackable. In most cases no. The data should be kept in the NVRam of the device, and that chip should be secured in a form that if tampered with will destroy the contents. This is a common practice with such chips, and as I understand is common practice for mobile phone makers to do such. Use of the PIM API's is not recommended as this make the data visible to anyone with a data cable and the bitpim (or similar) desktop app.

HTTP Communications are wide open: True...kinda. Like I mentioned in the past post, the communication from the device into the network is secured and encrypted, but once it leaves that network you will encounter unsecured paths.

So I contend that security flaws in applications can exist on JavaME, but these are due to designers not understanding the features and situations the device can be in, and how to code securely.

This is in stark contrast to other languages such as Brew, Symbian, and Windows Mobile where security issues exist and where programs can be hacked to expose the data even when designs have been done to address them. One such situation I am aware of is in Windows Mobile the SMS service can be hijacked and information relayed to the outside world without the users knowledge. This is not possible in JavaME.
These other languages are C/C++ based and thus means there can be the potential for an app to set a pointer into another applications memory space thus reading secured data. Again not possible in JavaME since MIDlets are in sandboxes and can not directly hook into each others memory or storage directly.

I hope that better explained my viewpoint on your concerns.

Regards,
-Shawn

terrencebarr
Offline
Joined: 2004-03-04
Points: 0

I am not an expert on the topic but I am not aware of any dramatic performance hit on MIDP https or secure socket connections - MIDP 2.0 has been around a while and this should be pretty robust technology by now.

-- Terrence