WO2002073337A2

WO2002073337A2 - Systems and methods for providing smart card interoperability

Info

Publication number: WO2002073337A2
Application number: PCT/US2002/005100
Authority: WO
Inventors: James Dray; Dominic Fedronic; Alberto Fernandez; Harry Jackson; Tom Barr; William Windsor; Daryl Hendricks
Original assignee: UNITED STATES GENERAL SERVICES ADMINISTRATION
Current assignee: UNITED STATES GENERAL SERVICES ADMINISTRATION
Priority date: 2001-03-07
Filing date: 2002-03-07
Publication date: 2002-09-19
Anticipated expiration: 2003-09-07
Also published as: AU2002247177A1; WO2002073337A3

Abstract

Methods and systems are provided for improving interoperability between an application (1000) program and a token (1060), such as a smart card, using a service provider module (SPM 1020). The SPM (1020) may receive a request for a service, selected from a predetermined set of services, from the application (1000) program. The SPM (1020) may then determine whether the token (1060) supports the requested service. If the SPM (1020) determines that the token (1060) does not support the requested service, it may provide information indicating an error to the application (1000) program. Otherwise, the SPM (1020) may process the request for service using the token (1060).

Description

SYSTEMS AND METHODS FOR PROVIDING SMART CARD INTEROPERABILITY DESCRIPTION OF THE INVENTION

Cross-Reference to Related Applications

[001] This application claims the benefit of U.S. Provisional Patent Application No. 60/273,317, entitled "SYSTEM AND METHOD FOR PROVIDING SMART CARD INTEROPERABILITY" and filed on March 7, 2001 , the entire contents of which are expressly incorporated herein by reference. Government License Rights

[002] The U.S. Government has a paid-up license in this invention and the right in limited circumstances to require the patent owner to license others on reasonable terms as provided for by the terms of the Smart Card Common Identification Card contract (Contract No. GS00T00ALD0208) awarded by the General Services Administration. Field of the Invention

[003] The invention relates to portable data storage devices in general, and to token devices in particular. Background of the Invention

[004] A token may be used to store and carry cryptographic keys and certificates that support user identity authentication. There are many types of tokens including smart cards, subscriber identity module (SIM) tokens, universal serial bus (USB) tokens, Personal Computer Memory Card International Association (PCMCIA) cards, and IBUTTONS™ / JAVA RINGS™. Various physical characteristics of a token may be established by a predetermined standard such as, for example, the ISO 7816-1 standard entitled "ID Cards - ICC, Part 1 - Physical Characteristics."

[005] Traditionally, there has been significant variation in architectures and features of tokens offered for commercial sale. In general, a token will contain at least a memory. Tokens may include various memory sizes such as, for example, 512 bytes, 1 K, 2K, 4K, 6K, 8K, 10K and 64K of EEPROM. Conventional tokens usually include a processor in addition to the memory. Tokens may include various types of processors such as, for example, 8-bit processors, 16-bit processors, and 32-bit processors. For example, tokens have been made using various processors, including the MOTOROLA™ 6805 processor, the INTEL™ 8051 processor, and the HITACHI™ H8 processor. Tokens may also include additional processors such as, for example, a math coprocessor or a cryptographic coprocessor. Various physical characteristics of a processor for a token may be established by a predetermined standard such as, for example, the ISO 7816-2 standard entitled "ID Cards - ICC Part 2 - Dimension and locations of Chip."

[006] Each manufacturer may select the token architecture, the processor, and the memory without regard to compatibility with tokens made by other manufacturers. Furthermore, various operating system programs are available for tokens including, for example, JAVACARD™, JAVA VIRTUAL MACHINE™, SMART CARDS FOR WINDOWS™, MPCOS™, STARCOS™, and MULTOS™. In addition, various tokens support different programming languages, including MEL™, JAVA™, C, C++, Assembler Language, and VISUAL BASIC™.

[007] In addition, devices for accessing tokens made by one manufacturer may be incompatible with tokens made by another manufacturer. For example, PCMCIA cards such as the National Security Agency (NSA) FORTEZZA™ Crypto Card, SIM tokens, USB tokens, and IBUTTONS / JAVA RINGS™ each use different electrical contact interfaces. The interface for accessing a token may be established by a predetermined standard such as, for example, the ISO 7816-3 standard entitled "ID Cards - ICC, Part 3 - Electronic Signal and Transmission Protocols." Consequently, devices for accessing one type of token may be unable to access another type of token.

[008] Other tokens such as, for example, contact-less smart cards may be accessed using transmitted signals such as radio signals or optical signals. The interface for accessing a contact-less token may be established by a predetermined standard such as the ISO 14443 standard entitled "Contactless Integrated Circuit Cards" which is incorporated herein by reference. Because the signals are transmitted, the information exchanged with the token may be intercepted.

[009] Tokens may contain privileged information such as, for example, information used to identify a person. Application programs that exchange privileged information with a token may be required to comply with a predetermined security standard such as the National Security Agency standard entitled "Guidelines for Placing Biometrics in Smart Cards;" the FIPS 140-1 standard entitled "Security Requirements for Cryptographic Modules;" the FIPS 180-1 standard entitled "Secure Hash Standards;" the FIPS 186-2 standard entitled "Digital Signature Standards;" and the National Institute of Standards and Technology standard entitled "Smart Card Protection Profile." Each of these standards is incorporated herein by reference.

[010] For example, the token may contain information that a person knows, such as a personal identification number, a password, or a memory phrase. For another example, the token may contain information that identifies a physical characteristic of the person that is difficult to change, such as biometric data. For yet another example, possession of tokens such as a magnetic stripe card, a physical key, or a smart card may serve to identify the person. Consequently, application programs may exchange information with the token using a cryptograph ically secure protocol and store the information to the token in an encrypted form to prevent interception or recovery of the privileged information.

[011] Due to the many possible combinations of features possible, application programs for tokens provided by one manufacturer may be incompatible with tokens provided by another manufacturer. Moreover, application programs for tokens made at one point in time may be incompatible with legacy tokens. Furthermore, systems for programming tokens may be incompatible with newer generation tokens made by the same manufacturer. For example, if the manufacturer revises the design of their tokens to provide additional memory, application programs written for an earlier type of tokens may be unable to access the additional memory provided with newer tokens. [012] A customer such as a government organization may purchase millions of tokens over a period spanning several years. The customer may purchase new tokens to replace tokens that have become lost or damaged. Maintaining compatibility with both the new tokens and with legacy tokens may require updates to the application programs each time new tokens are purchased. The effort required to update legacy systems and software for compatibility with new tokens may impose a significant administrative burden.

SUMMARY OF THE INVENTION

[013] The present invention provides a system for improving the interoperability of tokens. This is achieved by defining a model for a token Service Provider Module (SPM) that provides a basic services interface (BSI) to application programs that access the tokens. The BSI may include interoperable logical access control, physical access control, cryptography and biometrics services between the application program and the token. The BSI may provide predetermined services and a corresponding services interface common to all SPMs.

[014] Methods and systems are provided for improving interoperability between an application program and a token such as a smart card using a SPM. The SPM may receive a request from the application program for a service selected from a predetermined set of services and then determine whether the token supports the requested service. If the SPM determines that the token does not support the requested service, then it may provide information indicating an error to the application program. Otherwise, the SPM may process the request for service using the token.

[015] Methods and systems consistent with one aspect of the present invention may provide interoperability between an application program and a token using a service provider module, comprising: receiving at the service provider module a request for a service selected from a predetermined set of services, wherein the service provider module is configured to communicate with a plurality of types of tokens; determining, at the service provider module, whether the token supports the requested service; and providing information indicating an error to the application program in response to a determination that the token does not support the requested service.

[016] Methods and systems consistent with another aspect of the present invention may provide interoperability between an application program and a token using a service provider module, comprising: a first interface configured to receive at the service provider module a request for a service selected from a predetermined set of services, wherein the service provider module is configured to communicate with a plurality of types of tokens; logic configured to determine, at the service provider module, whether the token supports the requested service; and logic configured to provide information indicating an error to the application program in response to a determination that the token does not support the requested service.

[017] Methods and systems consistent with yet another aspect of the present invention may provider interoperability between an application program and a token using a service provider module, comprising: means for receiving at the service provider module a request for a service selected from a predetermined set of services, wherein the service provider module is configured to communicate with a plurality of types of tokens; means for determining, at the service provider module, whether the token supports the requested service; and means for providing information indicating an error to the application program in response to a determination that the token does not support the requested service.

[018] A computer program product consistent with yet another aspect of the present invention may provide for interfacing an application program to a token, the computer program product comprising: code for receiving at the service provider module a request for a service selected from a predetermined set of services, wherein the service provider module is configured to communicate with a plurality of types of tokens; code for determining, at the service provider module, whether the token supports the requested service; and code for providing information indicating an error to the application program in response to determining that the token does not support the requested service. [019] Additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Features of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as described. Further features and/or variations may be provided in addition to those set forth herein. For example, the present invention may be directed to various combinations and subcombinations of the disclosed features and/or combinations and subcombinations of several further features disclosed below in the detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

[020] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the invention and together with the description, serve to explain the principles of the invention.

[021] FIG. 1 is a general block diagram of an exemplary architecture for interfacing an application to a token in which methods and systems consistent with the present invention may be implemented;

[022] FIG. 2 shows an exemplary architecture for a token in accordance with methods and systems consistent with the present invention;

[023] FIG. 3 is a general block diagram of services provided by a Basic Services Interface in accordance with methods and systems consistent with the present invention;

[024] FIG. 4 shows an exemplary set of utility service commands that may be provided by a BSI in accordance with methods and systems consistent with the present invention;

[025] FIG. 5 shows an exemplary set of access control rules that a Basic Services Interface may support in accordance with methods and systems consistent with the present invention; [026] FIG. 6 shows an exemplary set of response values that a Basic Services Interface may issue in response to a request in accordance with methods and systems consistent with the present invention;

[027] FIGs. 7A-C are flowcharts showing an exemplary set of transactions between an application program, a Basic Services Interface, a token reader, and a token in accordance with methods and systems consistent with the present invention;

[028] FIG. 8 is a flowchart of a process for interfacing a service provider module to a token in which methods and systems consistent with the present invention may be implemented; and

[029] FIG. 9 is a general block diagram of an alternative exemplary architecture for interfacing a service provider module to a token in which methods and systems consistent with the present invention may be implemented.

DETAILED DESCRIPTION

[030] Reference will now be made in detail to the present embodiments of the invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[031] Methods and systems are provided for improving interoperability between an application program and a token such as, for example, a smart card using a service provider module (SPM). The SPM may receive a request for a service, selected from a predetermined set of services, from the application program. The SPM may then determine whether the token supports the requested service. If the SPM determines that the token does not support the requested service, then it may provide information indicating an error to the application program. Otherwise, the SPM may process the request for service using the token. Thus, application programs may be generated that are interoperable with various tokens, without requiring that the application program incorporate code for interfacing with each type of token.

[032] Typical application programs for tokens may include a broad range of services including, for example, physical access control, logical access control, property passes, medical record storage, cash equivalent storage, attendance monitoring, training record storage, miscellaneous information storage, and secure storage of certificates such as biometric access information.

[033] Token applications for physical access control may provide, for example, positive accounting for personnel, controlled access to a secure building or area, automatic generation of an audit log, and controlled access to sensitive spaces. Token applications for logical access control may provide, for example, computer security, data security, user authentication, non-repudiation of credentials, and encrypted data transmission. Additionally, token applications for logical access control may eliminate a need to memorize personal identification numbers (PINs) and may use biometrics for extra security. Because credentials stored on a token are portable, the token may be used to identify an individual's security clearances and authorization to access sensitive information or use equipment.

[034] Token applications for property passes may provide, for example, a positive record of equipment issued, reducing loss potential and increasing property accountability. The positive record may provide an electronic audit trail without requiring a paper trail, which may eliminate repetitious property tracking and save time when exiting a building. Moreover, a token property pass application may provide an audit trail for take-home equipment, as well as a reminder of property issued to the employee during his/her employment.

[035] Token applications may be used, for example, to contain medical information, reducing data entry and paper handling and enhancing the accuracy of patient information. Additionally, a medical record token may provide immediate access to medical information and reduce the time required to create medical reports and maintain the medical information securely, while ensuring a patient's privacy and providing enhanced portability. The medical records may be used to prevent drug interaction, to provide drug batch control, and to prevent drug treatment overlap. Medical information tokens may further provide a convenient storage to carry information regarding the patient's current or last treatment as a reference, or may be used to store immunization records.

[036] Token applications may be used, for example, to provide stored value cash equivalents to reduce handling of cash transactions and reduce potential for crime. For example, a token application may be used to eliminate a need for coins, to provide rewards for increased usage, to restrict use, to provide cash reimbursement, to record expenditures, to eliminate the need to carry cash, to provide electronic currency exchange as needed, and to capture customer demographics for improving delivery of products and services. Token applications may help to increase personal security, and may permit reloads from an automated teller machine or an on-line banking system.

[037] Token applications may be used, for example, to automate monitoring of attendance at an event or activity. Tokens may be used to register for the event, to capture e-mail addresses of the attendees, to generate accurate records and ensure complete capture of the attendees, and to reduce time and shorten waiting lines. Captured information may be used to create a database, which may be transferred to other applications.

[038] In consideration of the many possible applications for tokens, it is desirable to reduce the effort required to establish interoperability for tokens from various manufacturers. FIG. 1 shows a general block diagram of an exemplary architecture for interfacing an application to a token in which methods and systems consistent with the present invention may be implemented. An application program 1000 may communicate with a Service Provider Module (SPM) 1020 through a Basic Services Interface (BSI) 1010. SPM 1020 may include, for example, a token 1060, a token reader 1050 for interfacing to token 1060, a token-edge interface 1040 for accessing hardware in token reader 1050, as well as service provider software 1030 corresponding to token reader 1050 and token 1060.

[039] FIG. 2 shows an exemplary architecture for token 1060 in accordance with methods and systems consistent with the present invention. Token 1060 may include a physical interface 2010 used to exchange signals between token 1060 to token reader 1050. Physical interface 2010 may include an electrical contact interface such as a smart card interface, a subscriber identity module (SIM) interface, a universal serial bus (USB) interface, a Personal Computer Memory Card International Association (PCMCIA) card interface, or an IBUTTON / JAVA RING™ interface. In the alternative, physical interface 2010 may include a contact-less interface such as, for example, a contact-less smart card interface using radio or optical signals.

[040] Token 1060 may also include a processor 2020 and a memory 2030. Memory 2030 may include a plurality of storage types such as read-write memory (RAM) 2040, read-only memory (ROM) 2050, or electrically-erasable programmable read-only memory (EEPROM) 2060. The processor 2020 may be coupled to interface 2010 and memory 2030 using an electrical bus 2070. In some embodiments, token 1060 may include a sensor 2080 such as, for example, a biomethc sensor. In other embodiments, token 1060 may include a coprocessor 2090 such as, for example, a math coprocessor or a cryptographic coprocessor.

[041] When application program 1000 stores privileged information on token 1060, application program 1000 may transmit the information in an encrypted format so that the information cannot be intercepted or recovered from token 1060 by an unauthorized user. Thus, application program 1000 must determine whether token 1060 and token reader 1050 support exchanging information according to a secure cryptographic algorithm such as, for example, an Advanced Encryption Standard (AES) protocol, a Data Encryption Standard (DES) protocol, a Digital Signature Standard (DSS) protocol, a triple-DES protocol, an RSA™ protocol, or a Key Exchange Algorithm (KEA) protocol.

[042] Application program 1000 may determine whether token reader 1050 and token 1060 support a desired cryptographic algorithm by issuing a request to BSI 1010. FIG. 3 is a general block diagram of services provided by BSI 1010 in accordance with methods and systems consistent with the present invention. BSI 1010 may be established as a layer between application program 1000 and SPM 1020 to insulate application program 1000 from implementation-specific details of token reader 1050 and token 1060. BSI 1010 may provide interoperable logical access control, physical access control, cryptography and biometrics services between application program 1000 and token 1060.

[043] BSI 1010 may provide a standard set of predetermined services and a corresponding services interface common to all SPMs, providing access to the token in a manner which is transparent to application program 1000. In one exemplary embodiment, the BSI 1010 may include a utility services module 3010, a generic container services module 3020, and a cryptographic services module 3030. The utility services module 3010 may include services for detecting a token reader, detecting whether a token is coupled to the reader, and monitoring the status of the token. FIG. 4 shows an exemplary set of utility service commands that may be provided by the BSI 1010 in accordance with methods and systems consistent with the present invention.

[044] The generic container services module 3020 may include services for creating, deleting, reading, writing, and updating a collection of data items stored on token 1060. Each collection of data items may be stored in a container on the token 1060, and each container on token 1060 may be uniquely identified by a tag. Access to each container may be restricted according to an access rule. FIG. 5 shows an exemplary set of access control rules that BSI 1010 may support in accordance with methods and systems consistent with the present invention. Application program 1000 may access a data item on token 1060 by requesting the data item and providing the information required by an access rule corresponding to the container. SPM 1060 may then provide a response value indicating whether the request was successful. FIG. 6 shows an exemplary set of response values that a BSI 1050 may issue in response to a request in accordance with methods and systems consistent with the present invention.

[045] FIGs. 7A-C are flowcharts showing an exemplary set of transactions between application program 1000, BSI 1010, token reader 1050, and token 1060. Referring to FIG. 7a, it is shown that application program 1000 may issue a GetBSIVersionQ request to BSI 1010 to determine the version of an implementation of BSI 1010; BSI 1010 may provide a response with a BSI OK value to indicate that the request was successfully processed (Step 7010). Then application program 1000 may issue a GetReaderListQ request to BSI 1010 to determine whether at least one token reader 1050 is available. SPM 1020 may identify each available token reader 1050 through token-edge interface 1040. Then SPM 1020 may load appropriate Service Provider Software (SPS) such as driver software, and communicate with each token reader 1050 through token-edge interface 1040. SPM 1020 may determine the status of each token reader 1050 and then BSI 1010 may provide a response with a BSI OK value to indicate that the request was successfully processed (Step 7020).

[046] Next, application program 1000 may issue a GetTokenStatusQ request to BSI 1010 to determine whether token reader 1050 is coupled to token 1060. If token reader 1050 indicates that it is not coupled to token 1060, then BSI 1010 may provide a response with a BSI_TOKEN_NOT_PRESENT value to indicate that token 1060 is not available (Step 7030). Application program 1000 may issue additional GetTokenStatusQ requests to BSI 1010 to determine when token reader 1050 becomes coupled to token 1060. When token reader 1050 indicates that it is coupled to token 1060, then BSI 1010 may provide a response with a BSI_OK value to indicate that token 1060 is available (Step 7040).

[047] Then application program 1000 may issue a TokenConnectQ request to BSI 1010 to establish communication with token 1060 and BSI 1010 may provide a response with a BSI_OK value to indicate that a communication session has been established with token 1060 (Step 7050). Application program 1000 may issue a GetTokenPropertiesQ request to determine token-specific features, such as whether token 1060 supports a cryptographic communication protocol (Step 7060). Application program 1000 may also issue a GetContainerPropertiesQ request to BSI 1010 to determine what information is stored on token 1060 and what access protocols are supported to provide access to the stored information (Step 7070).

[048] Application program 1000 may then issue an AcquireContext() request to BSI 1010 to establish a cryptographically secure communication session, according to the determined access rules, with token 1060 (Step 7080). Next, application program 1000 may create, read, update, and write data items to token 1060 by issuing one or more PassThruQ requests (Step 7090). Application program 1000 may then terminate the cryptographically secure communication session by issuing a ReleaseContextQ request (Step 7100). Finally, application program 1000 may end the communication session with token 1060 by issuing a TokenDisconnectQ request (Step 7110), after which token 1060 may be safely decoupled from token reader 1050.

[049] From the previous description, it is clear that the present invention provides the capability for a plurality of tokens to interface with a plurality of application programs through SPM 1020. FIG. 8 is a flowchart of a process for interfacing SPM 1020 to token 1060 in which methods and systems consistent with the present invention may be implemented. As shown in FIG. 8, communication may be established using only SPM 1020 and token 1060. A transaction between SPM 1020 and token 1060 may be established by establishing a connection between SPM 1020 and token 1060.

[050] For example, a vending machine may incorporate SPM 1020 to accept payment from cash-equivalent storage on token 1060. A customer may request a product or service from the vending machine by connecting token 1060 to SPM 1020, such as by placing a contact-less token 1060 near SPM 1020. The vending machine may then establish a communication session, determine whether token 1060 has sufficient stored cash equivalent to purchase a product, debit the cash equivalent storage on token 1060, and provide the product or service to the customer.

[051] FIG. 9 is a general block diagram of an alternative exemplary architecture for interfacing a service provider module to a token in which methods and systems consistent with the present invention may be implemented. Application program 1000, BSI 1010, Service Provider Software 1030, token-edge interface 1040, and token reader 1050 may be incorporated within SPM 1020.

[052] The above embodiments and other aspects and principles of the present invention may be implemented in various environments. Such environments and related applications may be specially constructed for performing the various processes and operations of the invention or they may include a general-purpose computer or computing platform selectively activated or reconfigured by program code to provide the necessary functionality. The processes disclosed herein are not inherently related to any particular computer or other apparatus, and may be implemented by a suitable combination of hardware, software and/or firmware. For example, various general-purpose machines may be used with programs written in accordance with teachings of the present invention, or it may be more convenient to construct a specialized apparatus of system to perform the required methods and techniques.

[053] The present invention also relates to computer readable media that include program instructions or program code for performing various computer-implemented operations based on the methods and processes of the invention. The media and program instructions may be those specially designed and constructed for the purposes of the invention, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of program instructions include micro-code, machine code, such as produced by a compiler, and files containing a high-level code that can be executed by the computer using an interpreter.

[054] Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method for providing interoperability between an application program and a token using a service provider module, said method comprising: receiving at the service provider module a request for a service selected from a predetermined set of services, wherein the service provider module is configured to communicate with a plurality of types of tokens; determining, at the service provider module, whether the token supports the requested service; and providing information indicating an error to the application program in response to a determination that the token does not support the requested service.

2. The method of claim 1 , further comprising: processing the request for service using the token in response to a determination that the token does support the requested service.

3. The method of claim 1 , wherein the type of the token is selected from a group consisting of a smart card, a subscriber identity module (SIM), a universal serial bus (USB) token, a Personal Computer Memory Card International Association (PCMCIA) card, and an IBUTTON™.

4. The method of claim 1 , wherein the type of the token is configured to support at least one operating system selected from a group consisting of JAVACARD™, JAVA VIRTUAL MACHINE™, SMART CARDS FOR WINDOWS™, MPCOS™, STARCOS™, and MULTOS™.

5. The method of claim 1 , wherein the plurality of types of tokens is selected from at least one of a group consisting of tokens with different processors, tokens with different types of memory, tokens with different sizes of memory, tokens with different operating systems, tokens with different cryptographic protocols, and tokens with different programming languages.

6. The method of claim 1 , wherein said determining step further comprises: identifying, at the service provider module, at least one feature of the token and determining whether the token supports the requested service in accordance with the identified at least one feature.

7. The method of claim 6, wherein the at least one feature indicates whether the token is compatible with at least one cryptographic protocol selected from a group consisting of plaintext, an Advanced Encryption Standard (AES) protocol, a Data Encryption Standard (DES) protocol, a Digital Signature Standard (DSS) protocol, a triple-DES protocol, an RSA™ protocol, and a Key Exchange Algorithm (KEA) protocol.

8. The method of claim 6, wherein the at least one feature indicates a size of at least one memory in the token selected from a group consisting of RAM, ROM and EEPROM.

9. The method of claim 6, wherein the at least one feature indicates a type of a first processor in the token.

10. The method of claim 6, wherein the at least one feature indicates whether the token includes a cryptographic processor.

11. The method of claim 6, wherein the at least one feature indicates whether the token is configured to support at least one programming language selected from a group consisting of MEL™, JAVA™, C, C++, Assembler Language, and VISUAL BASIC™.

12. A system for providing interoperability between an application program and a token using a service provider module, said system comprising: a first interface configured to receive at the service provider module a request for a service selected from a predetermined set of services, wherein the service provider module is configured to communicate with a plurality of types of tokens; logic configured to determine, at the service provider module, whether the token supports the requested service; and logic configured to provide information indicating an error to the application program in response to a determination that the token does not support the requested service.

13. The system of claim 12, further comprising: logic configured to process the request for service using the token in response to a determination that the token does support the requested service.

14. The system of claim 12, wherein the type of the token is selected from a group consisting of a smart card, a subscriber identity module (SIM), a universal serial bus (USB) token, a Personal Computer Memory Card International Association (PCMCIA) card, and an IBUTTON™.

15. The system of claim 12, wherein the token is configured to support at least one operating system selected from a group consisting of JAVACARD™, JAVA VIRTUAL MACHINE™, SMART CARDS FOR WINDOWS™, MPCOS™, STARCOS™, and MULTOS™.

16. The method of claim 12, wherein the plurality of types of tokens is selected from at least one of a group consisting of tokens with different processors, tokens with different types of memory, tokens with different sizes of memory, tokens with different operating systems, tokens with different cryptographic protocols, and tokens with different programming languages.

17. The method of claim 12, wherein said logic is configured to determine whether the token supports the requested service further comprises: logic configured to identify, at the service provider module, at least one feature of the smart card; and logic configured to determine whether the token supports the requested service in accordance with the identified at least one feature.

18. The system of claim 17, wherein the at least one feature indicates whether the token is compatible with at least one cryptographic protocol selected from a group consisting of plaintext, an Advanced Encryption Standard (AES) protocol, a Data Encryption Standard (DES) protocol, a Digital Signature Standard (DSS) protocol, a triple-DES protocol, an RSA™ protocol, and a Key Exchange Algorithm (KEA) protocol.

19. The system of claim 17, wherein the at least one feature indicates a size of at least one memory in the token selected from a group consisting of RAM, ROM and EEPROM.

20. The system of claim 17, wherein the at least one feature indicates a type of a first processor in the token.

21. The system of claim 17, wherein the at least one feature indicates whether the token includes a cryptographic processor.

22. The system of claim 17, wherein the at least one feature indicates whether the token is configured to support at least one programming language selected from a group consisting of MEL™, JAVA™, C, C++, Assembler Language, and VISUAL BASIC™.

23. A system for providing interoperability between an application program and a token using a service provider module, said system comprising: means for receiving at the service provider module a request for a service selected from a predetermined set of services, wherein the service provider module is configured to communicate with a plurality of types of tokens; means for determining, at the service provider module, whether the token supports the requested service; and means for providing information indicating an error to the application program in response to a determination that the token does not support the requested service.

24. The system of claim 23, further comprising: means for processing the request for service using the token in response to a determination that the token does support the requested service.

25. A computer program product, comprising a computer readable medium having computer program code embodied in said medium, for interfacing an application program to a token, wherein said program code comprises: code for receiving at the service provider module a request for a service selected from a predetermined set of services, wherein the service provider module is configured to communicate with a plurality of types of tokens; code for determining, at the service provider module, whether the token supports the requested service; and code for providing information indicating an error to the application program in response to determining that the token does not support the requested service.

26. The computer program product of claim 25, further comprising: code for processing the request for service using the token in response to a determination that the token does support the requested service.