Java Reference
In-Depth Information
Suggested Enhancements
A few relatively minor enhancements would make this a serious application. The first area to
tackle is key handling. StealthMIDlet should load its keys from resource files in the MIDlet
suite JAR rather than using hard-coded values. This is possible using the getResourceAsStream()
method in Class . The keys would probably be placed there at deployment time, which means
the MIDlet would need to be deployed carefully, probably using HTTPS.
Likewise, StealthServlet should locate and load keys from a database or some kind of file
repository. Something as simple as a standard naming scheme based on user names might
be sufficient.
The keys themselves should be larger than the hard-coded samples here—how large is up
to you. As long ago as 1996, the U.S. government was fairly sanguine about allowing the export
of 40-bit RC4 technology, so you can rest assured that 40 bits is way too short. As the key length
increases, of course, you may start to have memory or performance problems, particularly in a
constrained environment like MIDP. Try to find a good balance between performance and
security.
Furthermore, you might want to consider using a different algorithm, like Blowfish
or Rijndael. The Bouncy Castle cryptography package has plenty of options in the
org.bouncycastle.crypto.engines package. As we mentioned, you can treat a block cipher
like a stream cipher using CFB mode.
Finally, the communication between the servlet and the MIDlet could be improved. It
would be nice, for example, if the servlet had some way to tell the MIDlet it couldn't find a
session. It's possible that the MIDlet will send up a cookie for a session that has expired on the
server side. In the current implementation, the servlet will create a new set of ciphers, ones that
are not synchronized with the MIDlet's ciphers. One way to solve this problem would be to
have the servlet pass a response code to the MIDlet. One response code might mean, “I lost
your session. Please reinitialize your ciphers and try again.”
Deployment Issues
Suppose you dressed up this example and incorporated it into a product. What are the issues
with distribution? For each copy of your software, you need to generate a pair of keys. These
keys are stored as resource files inside the MIDlet suite JAR, which means that for each copy of
your software, you'll need to generate a unique MIDlet suite JAR. At the same time, you need to
save the keys on the server side somewhere. When the client MIDlet makes a connection, you
need to be able to find the corresponding keys. None of this is particularly difficult, and it can
be automated.
The MIDlet suite JAR contains keys that should be secret. Therefore, it is a security risk to
transmit the JAR to a customer over the Internet. You might transfer it via HTTPS to a customer's
browser, and then rely on that customer to install the MIDlet suite on a mobile telephone or
other small device via a serial cable.
Trimming Bouncy Castle Down to Size
With both of the examples in this chapter, we're only using a small subset of the Bouncy Castle
cryptography package. We use an obfuscator to trim out the pieces we don't need. A good
obfuscator will find the methods, instance variables, and even entire classes that are not used
Search WWH ::




Custom Search