|
Archived from Sun's Dot-Com Builder Web Site
This content is archived from Sun's Dot-Com Builder Web Site.
These are the Best Practices > How To's archives.
Some of these pages may contain links that are no longer available.
If you see these, you can report it through the Suggestions link
and we will remove the link and leave the name (for reference).
|
|
Back to Dot-Com Builder How-Tos Archive
Securing the Wireless Internet Using "Kilobyte" SSL
July 16, 2001
by Carla King
"Kilobyte" SSL (KSSL) is a small-footprint, client-side-only implementation of SSL v3.0 for handheld and wireless devices. The process of developing connectivity applications for these devices requires consideration of the unique characteristics of a wireless environment, such as weaker CPUs, network latency, low bandwidth, and intermittent connectivity.
This article provides an overview of these design considerations while using the KSSL APIs. But first, a brief description and history of KSSL, as well as a description of the KSSL feature set, are provided.
A Brief History
Popular thinking dictated that the widely used Secure Sockets Layer (SSL) protocol was too heavyweight and memory-intensive for securing wireless devices. To fill the need for wireless security, the WAP (Wireless Application Protocol) Forum developed the WTLS (Wireless Transport Layer Security) protocol. Unfortunately, WTLS requires a proxy in order to work with the large installed base of Web servers secured with the SSL protocol. Since the proxy has to decrypt and reencrypt the packets to translate between SSL and WTLS, the proxy can see all the messages, which compromises privacy.
Given the unlikelihood that millions of SSL-secured Web servers would use WTLS, Vipul Gupta and Sumit Gupta, working for a Sun Laboratories project exploring security for small devices, developed an implementation of SSL for wireless devices. (The WAP Security Group has also decided to embrace the industry-wide standard by using TLS -- the next iteration of SSL -- for the next generation of WAP.)
KSSL Feature Set
The J2ME MIDP package, enhanced with KSSL, provides an easily programmable, mobile device platform consisting of a set of APIs that can be used to write an application requiring secure network transactions using SSL. To develop SSL-secured applications, you need this enhanced MIDP package and a hardware platform that offers an underlying reliable, bidirectional, byte-stream-oriented network connection.
The J2ME package's KSSL feature set:
- Implements client-side SSL version 3.0.
- Supports RSA_RC4_128_MD5 and RSA_RC4_40_MD5 cipher suites (most commonly used and fast).
- Provides server authentication via RSA signatures as well as arbitrary certificate chain lengths. The KSSL feature set (or simply "KSSL") does not support client-side authentication, which is rarely used.
- Supports caching of server certificates and SSL session reuse.
- Includes a ksecurity package that uses the Java Card API to add functions not included in the base J2ME platform, such as basic cryptographic functions -- random number generation, encryption, and hashing.
KSSL Design Considerations
Developers of wireless applications must consider the unique characteristics of a wireless environment, such as weaker CPUs, network latency, low bandwidth, and intermittent connectivity. Here are some design considerations that should be kept in mind when using KSSL APIs to write applications for wireless devices:
- Reuse as much possible.
- Avoid premature optimizations.
- Identify the "right" bottlenecks.
- Program for timely user feedback.
- Anticipate intermittent wireless connectivity.
- Ensure consistency between developer and user environments.
Reuse as Much as Possible
Reuse is perhaps the most important concept to remember when you are creating KSSL APIs. You can reuse certificate parsing results, SSL sessions (abbreviated handshake), TCP connections (persistent HTTP), and other operations. Public key operations required by SSL can be slow. Try to amortize the cost of these operations across multiple user transactions. In particular, reuse:
- The effort of parsing and verifying a certificate by caching that certificate (and marking it as already verified).
- The effort of creating master keys by implementing SSL's "session reuse" option.
- The same TCP connection for multiple HTTP request/response transactions by implementing "persistent HTTP." Enabling this feature can have a significant, positive impact on user experience because it reduces the number of times SSL handshakes must be performed.
Avoid Premature Optimizations
In designing for wireless, conventional thinking may not lead you to the best solution, and the consequences of premature optimization are serious. It is imperative that you identify exactly what is slowing down your implementation so you can solve the problem instead of, for instance, increasing CPU power by buying more equipment or increasing bandwidth. These solutions may not help performance because the problem may lie elsewhere.
Identify the "Right" Bottlenecks
Explore every avenue available for performance improvements before implementation. For example, when researchers were working with CLDC (with KJava widgets) on the Palm OS, careful instrumentation of the code enhanced performance opportunities in unexpected places. The impact of making these code changes, as detailed in the example in the next paragraph, was far greater than the potential benefit of reimplementing SSL (the commonly perceived bottleneck) in C.
When designing KSSL, a performance boost was obtained via a simple string conversion trick rather than by a reimplementation of the entire protocol in C.
Creating a new string from a byte array could be speeded up by a factor of nearly seven by first converting the byte array to a char array (by simply casting each byte to a char in a loop) and using the char array-based String constructor. However, this mechanism is safe only when dealing with ASCII strings; do not use this for UTF-encoded strings. Note that it is also unclear if string-related enhancements in newer KVMs nullify the benefits of this "trick." This point may not be valid on other MIDP implementations, but it is an example of looking for performance enhancements in unexpected places.
Program for Timely User Feedback
Periodic, timely feedback alleviates perceived delay. It is better to display a message-by-message progress of the SSL handshake to the user, rather than a static "Connecting..." message.
There are two ways to significantly speed up the display of text in a ScrollTextBox. These techniques make a difference of about 6 to 8 seconds in a user's perceived response time:
- Use a less accurate, but faster, algorithm for computing line breaks.
- Display text as soon as enough line breaks have been computed to cover the first page of the scroll box's display area. The original widget computes all the line breaks before displaying anything, which can add a good amount of "dead" time even when the displayed text has as few as one or two thousand characters.
Anticipate Intermittent Wireless Connectivity
While using the OmniSky CDPD network, the developers of KSSL discovered that wireless network connectivity was intermittent and that an application may receive transient IOExceptions at unexpected moments. Therefore, applications should be written to anticipate such exceptions and to handle them gracefully whenever an attempt is made to use the network. This "graceful handling" may be as simple as displaying a message such as "Network error, please retry."
Due to the intermittent behavior of wireless networks, an application that runs flawlessly on an emulator with a LAN connection is very likely to fail in mysterious ways on a device with a wireless connection. Therefore, it is important that you develop your application concurrently using a real wireless device before optimization and implementation.
Ensure Consistency Between Developer and User Environments
You cannot expect to develop good wireless applications if your environment is different from the users' environment. (It is surprising how often something so obvious gets overlooked.) Writing an application that performs well on a real mobile device with a real wireless network requires a different mindset than writing an application for an emulator. This is especially true if the emulator runs much faster and/or does not accurately model real constraints, as is often the case. For example, the emulator may offer a much larger heap, or may run on an operating system with more liberal resource constraints. (The Palm OS restricts the number of open sockets to four whereas the J2ME emulators running on Solaris and Windows operating environments have a much higher limit.)
Acknowledgments
Many thanks to Sumit Gupta and Vipul Gupta for their contributions to this article. Both are members of Sun Microsystems Laboratories. Sumit's areas of interest are networking, security, and wireless. Vipul has expertise in network security and mobile computing.
Resources
| 
