Java Smart Card Basics
The Java smart card is a means to authenticate, store keys, or to even operate cipher algorithms. DES and Triple-DES are normally used in smart cards and can be used to wrap keys. Wrapping is a way to encrypt a key. Applications can use the card to check for keys. In addition, applications can run off of the card. In the Blowfish example, an OFB mode could be used; however, the IV and key would be needed to encrypt and decrypt data. The Java smart card could be used to provide the IV and key to an application on a laptop to encrypt and decrypt all the sensitive data on that laptop. The key benefit is that if the laptop were stolen, the thief would need the smart card to get the sensitive data from the laptop. Figure 14-6 shows a smart card. The smart card consists of a smart card chip, which is the heart of the card.  Figure 14-6: The smart card
In order for a card to operate, there are several characteristics that have to be taken into account. For instance, a card is not going to have a hard disk or full operating system. Instead, a smart card will have an Electrically Erasable Programmable Read Only Memory (EEPROM) for burning in programs. A computer in your walletTo put it simply, a smart card is a miniature computer that can be kept in a wallet. A full instance of hardware, operating system, or the Java language is not going to be supported. A subset for basic use that is deemed important is the target for support. It follows that smart cards are used for securing a larger computer or applications, and the smart card is the key for doing it. The smart card will have only a little memory to work with, such as 1K of RAM (a typical smart card doesn't have more than 512 bytes of RAM) so the application must be optimized for memory. Therefore, the Java smart card will not support the normal JVM, JRE, or Java API, but will support a subset of each with features for the smart card. This is called the Java Card Virtual Machine (JCVM), the Java Card Runtime Environment (JCRE), and the Java Card Application Programming Interface (JCAPI), respectively. Each one of these packages must take into account the memory and processing limitations of the smart card. Because the Java language supports the Java smart card, many features of Java must still be implemented, such as the use of classes, encapsulation, and data hiding. The garbage cleanup will also have to be supported. Many larger features of Java that use a large overhead in memory will not be supported. Some of these features are Strings, Threads, Serialization, Cloning, and many more. Previous chapters have demonstrated what is needed for keys and ciphers, and many of the primitives such as integers, bytes, and many of the calculations are supported. In other words, an EJB cannot be supported in a Java smart card, but an RSA encryption can be supported. The supported JCAPI provides classes such as javacard.security.RSAPrivateKey , javacard.security.RSAPublicKey , and javacard.security.ECKey (Elliptic Curve), and uses the Remote Method Invocation (RMI), javacardx.rmi.RMIService class, and services for communications to clients and servers. Any communication done to chip and card itself is done through serial communications on the serial bus. An encapsulation is done to the serial communication to provide the I/O to applications through the Application Protocol Data Unit (APDU). The JCRE will pass the APDU to the application to process any I/O request to the card itself from the card reader or writer. These limitations do not affect the API itself but do affect the development environment. Since the smart card is limited by processing power and memory, the source code is not compiled and debugged on the smart card itself. The Java code is developed on a desktop in a JCVM interpreter. The code can be compiled, debugged , and simulated to some degree. A constraint would be an application that could be simulated on a desktop machine with 512 KB of memory and may work fine; however, it may not work on a card with 1 KB of memory. When the program is ready to be transported to the smart card, it must be converted into a Converted Applet (CAP). The CAP file is equivalent to a Java class file, except it is specific for Java smart cards. The CAP is processed in a Java Archive (JAR), just like normal Java class files. After the CAP files are created from the converter, they must be written to the smart card for execution. A smart card device kit is used with a card reader that will also provide the development kit for simulation and debugging on the development desktop. The application that is used to verify the structure of the Java code for smart card support and export the code into a CAP file is called an Off-Card Verifier . The Off-Card VerifierThe Off-Card Verifier will provide the debugging capabilities on the development desktop. The Off-Card Verifier is a special instance of the JCVM to debug and build the CAP of the development desktop. A thinner JCVM will be used by the Java smart card for executing the virtual machine for running the CAP. The Java smart card development environmentSee Figure 14-7 for an example of the Java smart card development environment. The Java card installer will work with the card writer to install the application files, or CAP files. The CAP files are generated from the capgen utility from the Java smart card development kit. To dump the CAP file into a readable form for understanding, a capdump utility can be used. The Java card installer will be used to write the CAP files into the smart card.  Figure 14-7: The Java smart card development environment Besides the class files, export files are used to define the scope of which packages to use when generating the CAP files. The export files are used during generation but are not loaded on the Java smart card. The export file lists the methods and fields that are available for applications to use. It works very much like a header file in the C programming language. The export file is used during the link time of the CAP application. The export file will list the available methods and fields that can be used by public packages. The available methods from the javacard.framework package are listed in the framework.exp file. The export files are used to specify which methods and fields should be used in generating the CAP and to limit the scope. Application and Resource IdentifiersThe identification of the package in the CAP file is called an Application Identifier (AID) and must follow the ISO 7816-5 specification. When the Java files are converted to CAP files, an AID must be used to identify the file. Instead of parsing out names through an environment, a JCRE will use AID-based Naming. The AID uses two fields: a Resource Identifier (RI) and a Proprietary Identifier Extension (PIX). The RI is a 5-byte identification that is assigned by the ISO organization to identify the company of the package. A package that is identified as com.richware will require an ISO identifier assigned to the richware.com company. The PIX is a 0- to 11-byte field that uniquely identifies the package itself. If the package were named com.richware.mytest , the mytest package would require a unique identification. The PIX is assigned by the organization that is doing the development. The JCRE will use the AID to identify the Java application. In order for a Java application to be implemented on the smart card, the application will extend the javacard.framework.Applet package. The Java application in a smart card will process the requests from the JCRE. The application will not start the requests . The Java application that will be loaded in a Java smart card will need to extend the javacard.framework.Applet interface and implement the install , select , deselect , and process methods. The install method will be the first method that the JCRE calls to initialize the Java application. The install method is called to initialize any variables and register the application into the JCRE. The install method will create the instance of the application. In order for the application to register itself into the JCRE, it must call one of the Applet.register methods. When the register method is implemented, the application will be fully associated with the AID. The applications in the smart card are single threaded. There might be many applications that need processing power at the same time. The JCRE will select which application to use by calling the application's select method. When the application is being deselected from the active channel, the JCRE will call the application's deselect method. When the application is being deselected, it needs to perform any cleanup work because the application will be removed from the active channel. Any APDU data will be processed from the JCRE into the application's process method. It is up to the application to process the data. The data will be passed to the application to be processed. See Figure 14-8 for an example of the interface.  Figure 14-8: The Java smart card interface
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
