★ wanayoo — archive 1999 http://linuxnet.com/tutorial.htmlNouvelle recherche | Portail wanayoo


Home
Information
Documents
Tutorial
Software
Mailing List
The Market
Contact Me

    Smart Card Tutorial


    Help Topics


    Transport Keys

    Upon receiving your smart card and reader it is important to first find your transport key. The transport key is a string of numbers used to lock the smart card during it's travel from the manufacturing site to the customer. The actual key itself is sent via other means such as mail so that if the truck is robbed during delivery the cards are worthless unless they have the transport key. You can try to randomize keys and verify them to the card but the cards will eventually destroy themselves after so many bad verifies. This is usually under twenty tries so good luck. Like a password you can change this key once you have verified the original transport key. This key is like a super user password. Functions like creating, deleting, or updating files cannot be done without this key.

    Communication Protocol


    Smart cards follow a specific protocol when talking to the reader and/or the PC. One commonly mentioned phrase, T=0, T=1, is used to describe the protocol used to communicate to the card from the reader. T=0 is a byte oriented protocol in that every byte that is sent, an Acknowledgement must be received. With T=1, a specific length of bytes can be sent in a data block. Information is sent to the reader in hex code format. The Schlumberger Reflex 60 has the following commands:
    0x60Gets Reader Type and Activate Reader
    0x61Sets Reader with ICC communication parameters
    0x62Turns Card Power ON
    0x63Turns Card Power OFF
    0x64Sends Reset to Card
    0x65Gets Reader-Card Status
    0x66Sends one byte to Reader
    0x67Sends Data Block to Reader
    0x68Makes Reader Resend last data block
    0x69Gets Reader Capabilities
    0x6ADeactivate Reader
    0x6BActivate Reader-Dependent Features
    0x6C-0x6FReserved

    A typical command to the card would include the reader command and also the card command. A Get Challenge command from a card would look like this:
      0x67 0x00 0x05 0xC0 0x84 0x00 0x00 0x08
    The first three bytes [ 0x67 0x00 0x05 ] indicate that the following command should be sent to the card. 0x05 is the size of the command that follows. [ 0xC0 0x84 0x00 0x00 0x08 ] is the actual card command for doing the Get Challenge. ISO standards set the way the commands are handled by the following command set standard:
      CLASS, INSTRUCTION, P1, P2, P3
    0xC0 would be the class,[ 0x84 ] would be the instructions, and [ 0x00 0x00 0x08 ] would be the three Parameters. ([ 0x08 ] is the desired return size of the Get Challenge).

    ISO 7816-4 File System

    Smart cards contain a central file system which follows the ISO/IEC 7816-4 standards. The file system is arranged hierarchical like many modern day operating systems. Files are named by a 2-byte file identifier. Smart Cards contain 3 major file types:
    • Master File (MF)
    • Dedicated File (DF)
    • Elementary File (EF)
    A root or Master File (MF) is the peak of the hierarchy. It is identified by 3F 00 as it's 2-byte identifier. It contains information and locations of files contained within it. Dedicated Files (DF) contain the actual data files. Dedicated files are like directories on smart cards. They subdivide the cards to hold files called Elementary Files (EF). The elementary file is where the actual data is stored. It can be of four different types.
    • Transparent File
    • Linear, Variable Length Record File
    • Linear, Fixed Length Record File
    • Cyclic, Fixed Length Record File
    Each type is unique in how the data is stored and it's actual purpose. Transparent files are commonly just fixed byte files used for storing information. Linear Record Files contain subdivisions called records which hold a certain amount of bytes each. Cyclic Files are Smart Card specific. They contain a cycle of information where records are written and read in a ring like manner.

    ISO 7816-4 Command Set

    COMMAND CLASSINSTRUCTION P1P2P3 Data Field 1Data Field 2
    Read BinaryC0B0EF identifier Offset of 1st byte readNumber of bytes to be read N/AN/A
    Write BinaryC0D0EF identifier Offset of 1st byte writtenNumber of bytes to be written Byte stringN/A
    Update BinaryC0D6EF identifier Offset of 1st byte writtenNumber of bytes to be written Byte stringN/A
    Erase BinaryC00EEF identifier Offset of 1st byte erasedIf not zero this is length of data field 1If present, this is the offset of the first byte not erased, must be greater than P2N/A
    Read RecordC0B2Index of the record to be read (01,02 .. FF) OR 00 if the current record is to be read Selection of record to be read 00 first, 02 next, 03 previous, 04 currentNumber of bytes to be read N/AN/A
    Write RecordC0B2Index of the record to be written (01,02 .. FF) OR 00 if the current record is to be read Selection of record to be read 00 first, 02 next, 03 previous, 04 currentNumber of bytes to be written Byte stringN/A
    Append RecordC0E200 EF identifierNumber of bytes in the append Byte stringN/A
    Update RecordC0DCIndex of the record to be written (01,02 .. FF) OR 00 if the current record is to be read Selection of record to be read 00 first, 02 next, 03 previous, 04 currentNumber of bytes to be written Byte stringN/A
    Get DataC0CAData Object IdentifierSize of response Le N/AN/A
    Put DataC0DAData Object IdentifierLength of Data Field Data to be writtenN/A
    Select FileC0A400 00022-byte file identifierN/A
    VerifyC02000 Qualifier of reference dataLength of Data Field Verification dataN/A
    Internal AuthenticateC088ID of algorithm in cardID of secret keyLength of Data FieldChallenge DataMaximum number of bytes expected in response
    External AuthenticateC082ID of algorithm in cardID of secret keyLength of Data FieldEmpty or response to challenge N/A
    Get ChallengeC08400 00Challenge sizeN/AN/A
    Manage ChannelC07000 open, 80 closeChannel ID: 00 - 0300N/A N/A
    Get ResponseC0C000 00Number of bytes to retrieveN/A N/A
    EnvelopeC0C200 00Length of Data FieldEncapsulated APDU Empty of Length of Le


    Card Security / Cryptography

    One of the key benefits of smart cards is the ability for some cards to support on board cryptography. For more information on cryptography please read "Applied Cryptography" by Bruce Schneier. Cryptographic smart cards open up a whole new realm in information security because it now allows a secure place for storage of keys and keyrings. By doing the actual cryptography on the card, the keys never have to leave their storage place. This gives the card holder a secure way of storing keys especially if the key pair was generated on the card. I will briefly describe what is necessary for using smart cards with cryptography.

    Cryptography comes in two flavors: symmetric and assymetric. Symmetric cryptography is when two parties share a secret key that no one else knows. They use this key to encrypt and decrypt messages. If that key were to get loose though, anyone could do the same. Assymmetric cryptography works in key pairs. There is a public and private key. The public key is anywhere and can be used by anyone to encrypt a message that the owner of that public key decrypts with their private key which is safely stored on the smart card. Since symmetric cryptography is generally thousands of times faster than assymetric, a combination of the two are used to achieve the best level of security at the right speed. Imagine the following schema.

    A user wants to encrypt a large file to send to another user in a secure fashion so they decide to use public key cryptography. Since symmetric cryptography is much faster, the user encrypts this large file using a symmetric cryptographic algorithm such as DES. Now the user has the symmetric key which is usually small and fixed-width. This key unlocks the encrypted file so this key must be encrypted using the receivers public key. By doing this, the reciever has the private key that decrypts the symmetric key that allows the receiver to then decrypt the file using the same symmetric algorithm. For more information on different types of cryptographic algorithms please visit http://www.homeport.org/~adam/crypto/table.html . This page will also show freeware and non free software libraries in different programming languages to perform various cryptographic functionality.

    Keys are part of a larger structure called a certificate. A certificate is not only a key but ties that key to an identity. This certificate or 'cert' may have a username, age, sex, etc tied into it somehow. How these certificates is stored on the card brings another issue. How does one interoperate with different types of certificates ? How does one authenticate one certificate with the username stored in a different location than another ? This problem is posed today with the many different standards that exist. Netscape, for example, uses PKCS-11 which is a library of functions to perform various security tasks such as smart cards. Microsoft uses PC/SC and their Crypto API to integrate with Internet Explorer and their Windows products. The problem exists: the two do not work together. To try and solve this a consortium of companies including IBM, Sun, Netscape, and others have tried to standardize smart card communication with something called the Open Card Framework. This is a set of Java cross-platform API's for integrating smart card technology in an interoperable way. For now it seems to be the best but is it scalable for biometric support such as fingerprint scanners and face recognition ? Is it strong enough to eventually tie into physical security along with electronic security ? If we can answer yes to all of these then I think that we are on the right track. Unfortunately, the biggest problem I see with OpenCard is the bandwidth requirements. Smart cards and readers are very slow devices, with the Java Virtual Machine running, it is common to see up to 20% of your CPU cycles and memory being used on a relatively novice application. Once a standard paves it's way it is important to look at cryptographic smart cards for different applications.

    One application is smart card enabled secure web access. This ability exists today in raw form using the smart card to sign the document before it is sent. Smart card enabled secure web transaction today begins by opening a SSL or Secure Socket Layer to the host machines web server software. Once this encrypted pipe exists the web browser makes a hash or fixed width representation of the form. It then sign's or encrypts this hash using it's private key stored on the smart card. Since the form is hashed it will be fixed width and can be encrypted on the card quickly. The original form is then sent along with this encrypted hash, or signature to the web server. At the web server the form is received and sent through the same hash function. The signature is decrypted and the hashs are compared. If they are equal then the document has not been changed during it's travels to the web server.

    Another application would include secure email. Secure email would use an algorithm similar to the one described in the schema described above which describes the encryption of a large file. In this one would sign their mail using a hash function and their their private key. They would encrypt their mail and combined signature using a symmetric algorithm such as DES. They would then encrypt the symmetric key using the recipients public key and send the document to the recipient for encryption. Signing may or may not occur. It is useful when making sure the document is not intercepted during transmission and changed and then passed along to look like the original document.

    Another application is physical access. Physical access is the ability to open a door or gate. Most modern day physical security systems use a protocol called Wiegand to communicate with door locks and other security devices on the Wiegand strip. Wiegand is especially useful for it's ability to travel longer distances without interference. Imagine a parallel or RS232 serial line. Devices would have to be within 20 feet of one another to avoid loss of data. So it is especially important when designing a physical access door reader to interface it to the Wiegand specifications. For more information of Wiegand, please visit http://www.siaonline.org . These door readers can tie other factors into authentication including just the verification of a certificate on a smart card. They can also use biometrics.

    Biometrics are especially useful when not only do you want to tie authentication to something that the user has but also something that they are. Most people aren't prone to forget their eyes or hands when they come to work so biometrics give a very secure and reliable way of identifying a user. Biometrics also come in many flavors. Retinal and Iris scanning determine a person's proprietary features of their eye. Facial scanning is a way of photographing a persons face and determining distinct features such as shape, size, or cheek to nose ratio. Finger print scanning, the most effective for the least amount of money, looks at features of the fingerprint. Everyone is born with a distinct fingerprint that does not change during their lifetime. Many fingerprint scanners map out the finger's minutiae - interesting points in the print where the ridges branch out. Others measure distance. There are many types of algorithms. One fingerprint scanner is made by a company called American Biometrics sells for under $300. For more information please visit http://www.abio.com Biometrics tie into smart cards in many ways. They often compliment each other. For one, the users prints can be stored on the card which would keep authentication from leaving the reader, thus the fingerprint representation never travels across a data line. Second, smart cards provide the second token during authentication. If only biometrics were used, a scanned print would have to try and match itself to hundreds or thousands of stored prints in a database. With the smart card it only has to check one print, thus speeding up the authentication process.

    Useful Links