J2ME Security: Now and in the Future
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Java 2 Micro Edition (J2ME) has gained a great deal of momentum since I first wrote on the topic for InformIT more than a year ago. Nearly every major wireless handset manufacturer has licensed the technology and J2ME handsets are currently in use throughout North America, Europe, and Asia. It is now being used for everything from business productivity applications to mobile gaming, and is successful enough that its capabilities are beginning to be actively marketed by carriers such as Sprint PCS and Nextel. "J2ME" may be hidden from their television commercials, but the color games you see being played represent the first wave of successful mobile Java applications. The next major frontier for the wireless data industry is mobile commerce, and J2ME figures to be an enabling technology to make this happen. The combination of a rich graphical user interface, local storage, and networking allow J2ME applications to deliver more "bang for the buck" than their SMS or WAP counterparts. Without security, however, mobile commerce will go nowhere and security is one area that WAP, and its browser-based relatives, currently have an advantage. In this article, we'll take a look at the need for powerful security in mobile applications, what security capabilities J2ME currently supplies, and where J2ME is headed into the future.
Security Concepts
A number of terms are commonly used to describe the attributes that any truly secure system must support. These include authorization, authentication, non-repudiation, integrity, and confidentiality. Each of them can be defined as follows:
Authorization: The preliminary setting up of permissions by a system administrator and the actual checking of the permission values that have been set up when a user is getting access (from http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci211622,00.html).
Authentication: The process of determining whether someone or something is, in fact, who or what it is declared to be (from http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci211621,00.html).
Non-Repudiation: Non-repudiation services provide unforgeable evidence that a specific action occurred (from http://csrc.nist.gov).
Confidentiality: A set of services used to protect data against unauthorized disclosure (from http://csrc.nist.gov).
Integrity: A set of security services verifying that the content of a message has not been modified; and if a sequence of messages is transferred, that the sequence has been preserved (from http://csrc.nist.gov).
As mentioned before, for any system to be deemed fully secure, all of the items listed above must be managed. Some applications may not have the need to support non-repudiation but a mobile commerce system certainly would; how else can you prove that a user actually ordered the item your system says he did?
As an example, consider a mobile J2ME application that prompts a user to enter a password. The J2ME app checks the password (either against a hard-wired value in the code, a password stored in local data storage, or via a networking call to a remote server with a user database) and allows entry into the application only if the user entered the correct password. Is this application truly secure? To the user, it may appear to be but it most definitely is not! A number of holes are evident. To begin with, the way that authorization itself is handled is insecure. Retrieving the password from the local data store or (thanks to Java bytecode) from the application itself would be trivial work to anyone seriously trying to retrieve it. If the password was sent over the air, it was probably sent as clear text via HTTP, also easily retrievable to someone very interested in snagging it.
Many mobile commerce scenarios also require the need to validate that the actual device being used belongs to the user. For instance, if you are using your mobile phone to purchase a drink from a soda machine (possible in Japan and Scandinavia and an application that IBM has used in their advertisements), the wireless carrier will place a charge on your mobile phone bill. To do this, the authentication process must verify that the phone being used is actually yours—something we failed to do in our simple example. Finally, data integrity is certainly not guaranteed because another user on a completely separate device could "spoof" your information, imitating the operation of the actual application and causing your mobile bill to balloon!