Protect your J2ME/MIDP Application

XML Digital Signature technology can help you implement lightweight and flexible security solutions for wireless WEB service applications. In this article, Michael Yuan discusses the importance of XML digital signatures and their applications. He also provides a digital signature API for the bouncy Castle cryptography package, and provides examples of a secure XML messaging environment between the J2ME/MIDP wireless front-end and the JSP page back end.

Java technology in Wireless WEB services

Java-based WEB services and wireless Java development are the two most prominent themes of JavaOne 2002. They represent future backend and front-end Java technologies in the pervasive computing landscape.

Web services are loosely coupled interoperable software components based on standard XML communication protocols. The use of WEB Services enables vendors to provide services in a specific market where their core competencies are located. Customers can then select Procurement services from multiple vendors according to their different needs. This convenience means that WEB services are perfectly suited for providing services to the wireless front-end. The convenience and dynamic nature of wireless information devices allows mobile users to leverage modular, dynamically configurable backend services.

The Java platform can play several important roles in the development of wireless WEB services applications. On the wireless side, Java 2 Micro Edition (J2ME) provides cross device compatibility, advanced language features, and a large number of libraries for all wireless devices (from cellular phones to complex home wireless information appliances). A key component of J2ME is the Mobile Information device framework (Information Device profile), which defines the Java API and runtime environment on cellular phones and low-end PDAs. With a large number of low-end devices, MIDP is expected to be widely deployed in the future.

From the Web server side, Java 2 Enterprise Edition (EE) already has all the necessary APIs and libraries to process Web service XML messages. With Web service interfaces or gateways, it is easy to use the core Java EE features, JDBC APIs, and RMI APIs implemented with EJB technology for the outside world. To bring these features together and enable the wireless Web Service application, the J2ME Web Service specification is also presented, which is currently in the Java Community process (JSR 172).

Security in a wireless Web service

Although Java-based Wireless Web services have a bright future in the popular mobile business world, the current technology is still immature. Security remains one of the remaining issues to be resolved. Wireless communication is an easy target for radio wave interception, while wireless devices have almost no computing power to support strong encryption of all communication data. In addition, at the back end, Web services run outside the enterprise firewall and use open messaging protocols to interact with each other. Wireless Web services are also a target for easy access to various cracking attacks. Well-developed point-to-point security technologies (such as SSL/TLS and HTTPS) are not suitable for multi-vendor, multi-intermediary Web service network topologies--the focus must be on the protection of content itself rather than on connections that deliver content. Despite new challenges, Web services themselves can be used to enhance mobile business security. The emergence of a new Web Services security specification enables you to use Web services as security utilities.

In the following paragraphs, I'll discuss a common security technique: digital signatures. I'll show you how to use digital signatures in XML messages to guarantee end-to-end data integrity. I'll apply some examples to illustrate how to implement an XML digital signature by using the popular J2ME/MIDP platform on the wireless side and using JavaServer Pages (JSP) technology on the back end. Finally, I will discuss performance issues and the feasibility of using digital signatures on current MIDP devices. MIDP programming details are not in the scope of this article, and if you need to review it, see the Resources section.

Using digital signatures to guarantee data integrity

Let's assume that you're a stock trader who uses a cellular phone to track stock price changes when you're not on the trading floor. On the way to work, your phone reminds you that the price of a stock you are watching has fallen to your lowest psychological price. Now, should you buy it based on this hint and make a profit with this low price? Before you take any action, you must be absolutely sure that the hint itself is trustworthy. If a competitor can intercept and change the message (for example, change the stock code), he may lure you into buying the wrong stock and throwing his high-priced stock to you. How do you know that the message was not tampered with from the monitoring service to your phone?

Data integrity is indeed one of the most important aspects of communication security. A physically secure network is expensive and does not cover a wide geographical area. If your business has to rely on the Internet to communicate, you must face the fact that the Internet itself provides little security. Internet packets must pass through multiple routers and hosts controlled by the non-dialogue parties before reaching their destination. Data communications are particularly vulnerable to wireless Internet access.

Timely rescue tools are public key infrastructure (PKI) and digital signatures. (As with MIDP programming, digital signatures are not in the scope of this article; Interested readers can refer to the Resources section for more information.) In general, in the PKI digital signature mode, each party has two cryptographic keys: the public key, which anyone can use, and the private key, which is confidential, and only one person can use it. Messages encrypted with the private key can only be decrypted correctly by the corresponding public key. When a sender sends a message, he can send the same private key encrypted version of the same message along with his public key to the message. The receiver uses the sender's public key to decrypt the encrypted version. If it matches a plaintext message, the receiver can know that the message is actually trusted. The private key cryptographic version of the message is used as an integrity verification token, which we call "digital signatures."

Because the original message can be quite long, and the public key algorithm for generating and validating digital signatures is resource intensive, the sender typically calculates a short version of the original message called "Digest" and only signs the version digitally. The summary has a fixed length, which is a one-way hash of any length of input message, and its calculation is very fast. The receiving party first verifies that the received message produces the correct digest. If the digest does not match, the message is rejected before any public key algorithm is executed. This can help prevent an attack from clogging, in which an attacker uses a forged public key request to populate the server to deplete its computing resources.

In most real-world applications, the public key itself is digitally signed by a trusted authority and becomes a "digital certificate" to authenticate the sender's identity. However, the processing of digital certificates is not covered by this article, so in the following example, I will assume that the sender is trustworthy and use the unsigned public key to illustrate the method.

XML Digital Signature for definition

As I mentioned earlier, XML is becoming a major data exchange protocol in the WEB services world. XML messages that drive WEB services often need to go through multiple intermediaries before they reach their destinations. Therefore, it is important that we protect the content from end-to-end communication. The best way to do this is to ship the XML document and its security information (such as signatures, summaries, keys, and so on) together as a single document.

An XML digital signature is the same-name code that adds a digital signature to an XML document. The sender can choose to digitally sign the entire document or only part of it. Digital signatures, summaries, and public keys are formatted as XML elements. Additional elements of those security information can encapsulate the entire original XML message, or they can be embedded in the original message. For the sake of convenience, I will use the encapsulation format in this article.

For clarity, the XML digital signature Example I use in this article is not exactly the same as that of the consortium. For example, I omitted the standard (XML markup standardization) section because it only ensures consistency in XML documents and is not related to security itself. In addition, I divide the key into several parameters and pass those parameters to a separate XML element under the KeyInfo of the public key element instead of using the encoded public key certificate. This establishes a more visible connection between the key and the Java code that handles it.