Previous | Table of Contents | Next |
This program is available on Schlumbergers Cyberflex Web site (http://www.cyberflex.austin.et.slb.com).
The Java program in Listing 8.1 shows how the Cyberflex 1.0 card can emulate a modest ISO card. It implements the following 13 ISO commands:
Select File Verify Key Create File Delete File Directory Update Binary Read Binary Update Record Read Record Verify CHV Change CHV Unblock CHV Verify Key
and the following three Cyberflex-specific commands:
Execute Application Get File Information Set File Access Control
The program is just a FOREVER loop that gets an ISO APDU command packet from the terminal, executes it, and returns the status to the terminal.
In October 1997, coincident with the announcement of Java Card version 2.0, Schlumberger introduced an update of the Cyberflex smart card called Cyberflex 2.0 Core. The idea was to provide a smart card with a Java virtual machine on top of which the Java Card 2.0 API could be built, but one that could also support nonfinancial vertical industry APIs.
Here is a complete list of the 46 functions on the Cyberflex 2.0 Core API:
GetMessage SendMessage SetSpeed SendStatus SelectFile SelectRoot SelectCD SelectParent CreateFile DeleteFile ResetFile ReadByte GetFileInfo ReadBinary WriteBinary SelectRecord PreviousRecord NextRecord ReadRecord WriteRecord LastUpdatedRecord InitFileStatus BackupFileStatus RestoreFileStatus VerifyCHV ModifyCHV VerifyKey GrantSupervisorMode RevokeSupervisorMode GetFileStatus SetFileStatus SetFileACL GetFileACL CheckAccess GetFileSize GetRecordLength GetRecordNb GetFileType GetApplicationId GetIdentity SetDefaultATR SendATR CompareBuffer AvailableMemory Execute ResetCard
The following sections describe some of these 46 functions.
Communication
GetMessage(byte buffer[], byte expected_length, byte ack_code)
This function retrieves a message from the terminal of the expected length and puts it into the buffer. The ack_code parameter is used only for T=0 transmissions. (In T=0 communication, the terminal sends the first 5 bytes of the message and waits for ack_code to know what to do with the remaining bytes of the message. The typical case is when ack_code is equal to 0, in which case all subsequent bytes are transferred and put into the buffer.) By using zero as ack_code, your application works the same with any ISO communication protocol.
SendMessage(byte buffer[], byte data_length)
This function sends data_length bytes from buffer to the terminal.
File Management
SelectFile(short fileId)
This function selects a file on the smart card and prepares it for access (that is, opens it). This file becomes the current directory or current file.
CreateFile(byte file_hdr[])
This function creates a new file in the current directory with the properties given in file_hdr.
DeleteFile(short fileId)
This function deletes the named file.
GetFileInfo(byte file_hdr[])
This function retrieves information describing the current file.
ReadBinaryFile(short offset, byte data_length, byte buffer[])
This function reads data_length bytes, starting at byte offset from the current file and returns them in buffer.
WriteBinaryFile(short offset, byte data_length, byte buffer[])
This function writes data_length bytes from buffer into the current file starting at byte offset.
SelectRecord(byte offset, byte mode)
This function selects a record number offset in a record file. mode determines whether the offset to the selected record is taken from the beginning or the end of the file or forward or backward from the current location.
PreviousRecord()
This function selects the previous record in the current record file.
NextRecord()
This function selects the next record in the current record file.
ReadRecord(byte buffer[], byte record_number, byte offset, byte length)
This function returns length bytes, starting at offset in record number record_number of the current record file in buffer.
WriteRecord(byte buffer[], byte record_number, byte offset, byte length)
This function writes length bytes from buffer into record record_number of the current record file, starting at byte offset.
Security
Associated with every file on the Cyberflex card there may be a file of one or more cardholder verification numbers (CHVs) and a file of one or more cryptographic keys. Cardholder numbers are also called personal identification numbers (PINs). PIN files and key files are found either in the same directory in which the file they are protecting is found or in a parent directory of the current directory. The CHV numbers and keys in these files are numbered 0, 1, 2, and so on.
Typically, PIN numbers are four ASCII digits long and let the program perform cardholder operations on the file while keys are 8 bytes long and let the program perform card-owner operations on the file. This is just a convention, however, and you can make PIN numbers and keys be whatever you like and mean whatever you like when you design the security for your cards file system.
VerifyCHV(byte CHV_number, byte CHV[], byte unblock_flag)
This function compares the 8 bytes stored in CHV with CHV number CHV_number in the CHV number file associated with the current file and returns success or failure. If unblock_flag is nonzero, the comparison is made to the unblocking CHV number rather than the CHV number indicated by CHV_number.
ModifyCHV(byte CHV_number, byte old_CHV [], byte new_CHV [], byte unblock_flag)
This function changes CHV number CHV_number from old_CHV to new_CHV. If unblock_flag is nonzero, the change is to the unblocking CHV.
VerifyKey(byte key_number, byte key[], byte key_length)
Previous | Table of Contents | Next |