|
|
This chapter describes the strengths of various components of a typcial SATSA application. The remainder of the chapters in this book describe specific parts of SATSA, but this chapter bridges the gap between a low-level understanding of APIs and a high-level understanding of application design.
A typical SATSA application consists of three types of hardware:
There are many ways to structure applications, and cases where one or more components are unnecessary. This simple architecture indicates components that are most often present in SATSA applications.
Usually, a server is a relatively powerful computer with a fast processor and lots of memory. Do the bulk of work in your application on the server, if at all possible.
Aside from the available power, the other reason it’s nice to have application code running on a server is that it’s easy to change. You can optimize, fix bugs, or make updates in server code without changing the client code.
The power of a MIDP device is that it’s a highly portable networked computer. Many mobile phones fit easily in a pocket. Network connectivity means that a MIDP device can perform serious work using a server without having heavy processing power on the device itself.
MIDP applications can present a sophisticated user interface but defer the heavy lifting to the server.
A smart card is a tiny computer, complete with a processor and memory. It is capable of storing information and performing cryptography. That by itself doesn’t distinguish a smart card. After all, a MIDP device could perform the same tasks easily.
Smart card hardware is tamper-resistant, which means that if someone steals your smart card, it will be harder to extract information than from a more traditional device like a MIDP mobile phone.
Smart cards are most valuable as a physical representation of a private information. If you store secret information on a smart card, it’s very easy to understand that the card itself must be kept physically secure. A smart card closely resembles a credit card, which means it’s easy for users to comprehend that the smart card needs to be treated similarly.
In the case of private cryptographic keys, smart cards are especially useful. A smart card can cryptographically sign information, proving possession of a private key, without the key itself ever leaving the smart card.
You’ve already read about the four APIs defined by the SATSA specification. How do these APIs relate to the architectural elements described previously?
SATSA-APDU and SATSA-JCRMI both provide a way for MIDP applications to communicate with a smart card. Using either API, the basic function is the same: the MIDP application asks the smart card to do something and the smart card provides a response.
SATSA-PKI allows a MIDP application to request cryptographic signature or authentication from a smart card.
SATSA-CRYPTO provides MIDP applications with the ability to compute message digests, verify digital signatures, and encrypt and decrypt data. Of the four SATSA APIs, SATSA-CRYPTO is the only one that does not involve interaction with a smart card.
If you want to communicate with a smart card from a MIDP application, which API should you use, SATSA-APDU or SATSA-JCRMI?
Functionally, there is no difference between the two. Both APIs provide a way for a MIDP application to request action from the smart card and receive a response. The distinction between the two APIs is how the programmer communicates with a smart card.
SATSA-APDU uses a protocol based on the exchange of byte arrays between the MIDP application and the smart card. It is a low-level protocol. By contrast, SATSA-JCRMI exposes a more object-oriented protocol to the developer. Using SATSA-JCRMI, the developer can request work from the smart card using a remote object protocol, a high-level protocol.
Generally speaking, programmers are less likely to make mistakes using SATSA-JCRMI than using SATSA-APDU. Because of this, SATSA-JCRMI is the preferred method of communication. The only situations where you might choose SATSA-APDU are to port legacy applications or to use card hardware that doesn’t support JCRMI.
How are SATSA applications distributed? How do users get MIDP devices and smart cards? Obviously, the answer varies from application to application. Here are two possibilities:
If your application is going to do anything that takes longer than a few hundred milliseconds, you need to put that work in a separate thread. Remember, most of the code you write in a MIDlet is in threads that belong to the system, not to your application. If you perform lengthy work in a system thread, you’ll lock up the user interface on the device, which is a very unpleasant experience for your user.
Some operations in SATSA are potentially time-consuming. Whenever you communicate with a smart card via SATSA-APDU or SATSA-JCRMI, consider both the communication time as well as the time it will take the card to process the request and generate a response. Also bear in mind that the system might need to display prompts to ask for permission or access codes.
Cryptographic operations are typically slow, especially when they are performed on small hardware like MIDP devices or tiny hardware like smart cards. You can expect some methods in SATSA-PKI and SATSA-CRYPTO to take a significant amount of time. Make sure your application handles threading correctly and provides a useful, lively interface even while slow operations are taking place.
For a detailed look at threading in MIDlets related to network access, try this article:
Networking, User Experience, and Threads
http://developers.sun.com/techtopics/mobility/midp/articles/threading/
|
|
SATSA Developer's Guide SATSA Reference Implementation 1.0 |
Copyright © 2004 Sun Microsystems, Inc. All rights reserved.