Abstract:
This invention provides a security token architecture which supports modular security application installations without loss of existing data or requiring the reinstallation of existing applications served by the security application modules. The architecture is compliant with the international standard ISO/IEC 7816-4, “Information technology—Identification tokens—Integrated circuit(s) tokens with contacts—Part 4: Interindustry commands for interchange.” An application is integrated into a security domain which serves as a centralized security applications programming interface between one or more token service applications and a series of security application modules. The API provides a more uniform security application interface which improves overall interoperability of the modular security applications and simplifies security application development. The API provides a separate shareable interface which facilitates changes in security applications without disruption of existing application dependencies and allows customization of security properties associated with the installed security applications.

Description:
FIELD OF INVENTION  
       [0001]     The present invention relates generally to a data processing system, method and computer program product and more specifically to a framework for implementing a uniform security token architecture.  
       BACKGROUND  
       [0002]     Application development for use in security tokens has until recently required highly customized programs designed to execute on a specific security token platform. Initially, little effort was exerted into providing cross platform or multi-application support as the token issuer controlled all aspects of development and deployment of the applications contained inside the security token. This situation changed somewhat when a newer generation of multi-application security tokens became available. This newer generation of security tokens provided greater flexibility by allowing high level programming languages such as Java™ or Visual Basic™ to be used in the development of security token applications. The use of high level programming languages greatly simplified the development of security token applications and provided a mechanism for cross platform support.  
         [0003]     However, the implementation of multi-application security tokens which facilitated inclusion of third party applications was slow to gain acceptance due in part to the lack of standards in which to develop applications and security concerns of the token issuers. To address these and other deficiencies, a industry consortium was formed called GlobalPlatform. GlobalPlatform has since developed a number of standards including GlobalPlatform Card Specification, the latest of which version 2.1, published Jun. 4, 2001.  
         [0004]     GlobalPlatform Card Specification 2.1, supports multiple applications residing in a security token, includes a mechanism for sharing of resources in a secure manner and standardizes the mechanism by which applications are loaded and installed in the security token. To implement the specification, a centralized management arrangement is installed inside the security token. This centralized management arrangement is controlled by the security token issuer and provides complete control over all post issuance applications, whether related to the security token issuer or otherwise. GlobalPlatform includes the ability to delegate certain token management aspects from the token issuer to third party application providers for performing approved and pre-authorized token content changes such as loading, installing or deleting applications owned by the third party. This token issuer-centric approach is described in U.S. Pat. Nos. 6,005,942 and 6,233,683, assigned to Visa International, Inc., one of the founding members of GlobalPlatform.  
         [0005]     While advantageous in many commercial deployments, GlobalPlatform&#39;s issuer-centric model does not fit deployments where an unaffiliated applications provider desires to configure and maintain security policies specific to its assigned security domain. In this type of deployment, the unaffiliated applications provider&#39;s security policies may be incompatible with the issuer-centric security policies required by GlobalPlatform.  
         [0006]     Another limitation in the relevant art, particularly in the JavaCard™ operating environment, is the lack of a standard in security service application design which impacts interoperability of applications and enforcement of security policies at the application level or security domain.  
         [0007]     This is a significant limitation in the relevant art since token security services are intermingled with token application management making the security policies difficult to maintain, limits scalability of common code, is inefficient in terms of space utilization and could potentially degrade interoperability between applications due to inconsistent usage of available token resources.  
         [0008]     Lastly, a final significant limitation in the relevant art is the difficulty in the addition or replacement of security service applications such as authentication and secure messaging applications. Token service applications establish dependencies with the token security service applications by way of shareable interface objects. These dependencies limit the ability to easily replace a token security service application since dependent token service applications would not be linked to the new security service applications without reinstalling both the token service applications and the new token security services applications. Furthermore, the replacement and reinstallation task becomes considerably more difficult after the security token has been issued due to the presence of subsequently stored security data which may become lost or corrupted.  
       SUMMARY  
       [0009]     This invention addresses the limitations described above and provides a security token architecture which supports modular security application installations without loss of existing data or requiring the reinstallation of existing applications served by the security service application modules, provides a consistent and uniform interface to critical security token services such as authentication and secure messaging, and provides application level administration and configuration of security policies, thus minimizing redundancies in source code and freeing critical storage space for other uses.  
         [0010]     The term “security token” as defined herein refers to hardware based security devices such as security tokens, integrated circuit tokens, subscriber identification modules (SIM), wireless identification modules (WIM), USB token dongles, identification tokens, secure application modules (SAM), hardware security modules (HSM), secure multi-media token (SMMC) and like devices.  
         [0011]     The security token architecture is compliant with the international standard ISO/IEC 7816-4, “Information technology—Identification tokens—Integrated circuit(s) tokens with contacts—Part 4: Interindustry commands for interchange,” included as a reference.  
         [0012]     The term “security domain” refers to one or more logical or physical workspaces within a security token allocated to an application provider for installation and execution of applications whose security policies are internally configured, maintained and enforced within the application provider&#39;s workspace apart from other security policies already existing within the security token.  
         [0013]     A security domain control services application extends from the runtime operating environment and provides a uniform security applications programming interface (API) between the token&#39;s runtime operating environment and a series of security application modules installed inside an associated security domain. The security domain control services application is designed to provide and implement security domain level security policies rather than relying on issuer or administrative level security policies.  
         [0014]     An object-oriented framework is envisioned for post issuance installations and backward compatibility using Java™ for implementation in Java Cards™ as described in “Java Card™ 2.2 Application Programming Interface,” included as a reference. In another embodiment of the invention, the security domain control services application is written in the native code language of the token processor and installed by the token manufacturer. Other embodiments adaptable to virtual machine tokens employing Windows for Smart Cards™ are also envisioned by the inventor.  
         [0015]     The security domain control services application includes a set of access control rules, a set of unlock control rules, a set of lock control rules, an accounting data and one or more registries. The registry (s) store the application identifiers (AID) for each installed security applications module and the current state of security requirements associated with the particular security domain. Optional parameters may be stored in the registry which provide a summary of security services available from security modules installed in the security domain, usage criteria, roles, activated components and administrative information. Single or multiple registries are envisioned which allows for future space and access optimization. The security domain control services application communicates with compliant applications through interface modules which are customized to support the specific functions of the installed security domain applications.  
         [0016]     Each interface module includes a collection of routines and library functions used to communicate with the security domain control services application which are specific to the function of its associated application. Communications between the security domain control services application and security applications may include cryptographic methods to further preclude unauthorized monitoring of transactions. In the preferred embodiment of the invention, the interface modules are incorporated or linked to the security applications at time of installation into the security token.  
         [0017]     The three basic categories of security applications include token services, token security administrative services and token security services and are discussed below.  
         [0018]     Token services applications are applications which require some form of security measures in the form of secure messaging and/or authentication before performing a requested transaction. The token services applications are the actual clients served by the security domain control services application. An example of a token service application is an electronic wallet which requires user authentication in the form of a personal identification number (PIN) before access is allowed to the electronic funds stored inside the wallet. Other common examples of token service applications include use of cryptographic keys, secure storage of information and management of loyalty credits. Multiple instances of token services applications may be present in a particular security domain.  
         [0019]     Each token service application includes pre-established commands and references to their associated access control rules which are maintained and enforced by the security domain control services application. The pre-established commands may include data to be transferred to the security domain control services application or minimized to include only applicable instructions steps in a command header.  
         [0020]     These references are used by the security domain control services application to determine the security prerequisites necessary for the token service application to successfully perform a transaction. To provide backward compatibility with existing applications, actual access control rules may be included with the token service applications as well. The access control rules may be associated with the interface module or linked directly to each token service application.  
         [0021]     Alternately, a security application identifier may be returned from the security domain control services application to a requesting service application as part of the security policy enforcement. In this embodiment of the invention, the requesting security application calls the security application directly using the returned application identifier.  
         [0022]     The access control rules define the required security policies which must be satisfied before a token service application is used in processing a security function. For example, expanding on the electronic wallet described above, a set of access control rules may require a PIN or a biometric authentication before access to funds contained in the electronic wallet is permitted. In the preferred embodiment of the invention, the calling token service application sends a reference corresponding to the appropriate access control rules to the security domain control services application to determine the security states required by the requesting service application. The access control rules include logical AND, OR or NULL (none.)  
         [0023]     Token security administrative services applications provide access to the parameters associated with the registries(s), access control rules, unlock control rules and accounting data for definition, configuration and management of security policies prescribed for the particular security domain. As such, each application provider may access and manage their own security policies but are prohibited from accessing or altering the security policies, parameters and rules of other entities installed in other security domains. In the preferred embodiment of the invention, the token security administrative services applications are separate applications modules. However, it is also envisioned by the inventor that the functionality of the token security administrative services applications may be incorporated into the security domain control services application as well to save critical storage space and improve execution speed. It is further envisioned that one or two token security administrative services applications may be installed in each security domain.  
         [0024]     The token security services applications perform application level authentications, verify required authorizations and establish and maintain secure messaging sessions. The token security services applications establish the prerequisite security states required by the token services applications in accordance with an associated set of access control rules. The end results of executing one or more of the token security services applications are recorded in the registry (s) which are used to enforce the predefined application level security policies. Examples of token security services applications include authentication using personal identification numbers (PIN), authentication using biometrics, secure messaging using IPsec, SSL, TLS, WAP, etc. In the preferred embodiment of the invention, limited PIN and biometric unlock features are available through the token security services applications to minimize external support requirements. It is envisioned that multiple instances of token security services applications will be installed in a given security domain to accomplish traditional and emerging authentication technologies.  
         [0025]     All of the security applications (token services, token security administrative services and token security services) are directly addressable by external resources using one or more of the following addressing formats: 
        APDU, INS, Object Identifier     APDU, INS, AID     Method Identifier, Object Identifier,        
 
         [0029]     where APDU is an application protocol data unit, INS is an instruction byte, AID is an application identifier and the method identifier and object identifier are implicit references for implementation using Java Card™ 2.2 remote method invocation (RMI) services.  
         [0030]     Each security application is designed to update its associated security state in the registry (s) following execution of a security command. The modular nature of the security applications allows expansion of a base set of modular security applications without having to reconstruct dependencies.  
         [0031]     The token&#39;s runtime operating environment provides error trapping, recovery and message routing functions between the various applications and external resources. Each security application is registered with the token&#39;s runtime operating environment and is addressable using its unique application identifier (AID) by the runtime operating environment. The invention may coexist with other API level applications including components associated with the aforementioned GlobalPlatform specification. 
     
    
     BRIEF DESCRIPTION OF DRAWINGS  
       [0032]     The features and advantages of the invention will become apparent from the following detailed description when considered in conjunction with the accompanying drawings. Where possible, the same reference numerals and characters are used to denote like features, elements, components or portions of the invention. It is intended that changes and modifications can be made to the described embodiment without departing from the true scope and spirit of the subject invention as defined in the claims.  
         [0033]      FIG. 1P A—is a generalized prior art diagram illustrating a shareable interface establishing dependencies between security service applications and service applications.  
         [0034]      FIG. 1 —is a detailed block diagram illustrating the major components included in the invention where the shareable interface is centralized in a separate applications programming interface.  
         [0035]      FIG. 1A —is a generalized block diagram illustrating the multiple instances of the security applications included in a plurality of security domains installed inside a single security token.  
         [0036]      FIG. 1B —is a generalized block diagram illustrating an alternate embodiment of the invention where certain functionalities of the security applications are incorporated into a security domain control application.  
         [0037]      FIG. 2 —is a detailed block diagram illustrating the functional relationship between a security domain control application, a plurality of security applications and associated security policies.  
         [0038]      FIG. 2A —is a detailed block diagram illustrating the security applications and references to associated security policies maintained and enforced by the security domain control application.  
         [0039]      FIG. 2A   1 —is a detailed block diagram illustrating an alternate embodiment of the invention where only a APDU command header including an instruction step is sent to the security domain control application.  
         [0040]      FIG. 2A   2 —is a detailed block diagram illustrating a variation of the alternate embodiment of the invention where only a APDU command header including an instruction step is sent to the security domain control application and an address of token security services application is returned for addressing directly by a token services application.  
         [0041]      FIG. 2B —is a detailed block diagram illustrating a plurality of security parameters included in one or more registries associated with the security domain control application.  
         [0042]      FIG. 2C —is a detailed block diagram illustrating a set of access control rules which are referenced by the security applications for enforcement of the token&#39;s predefined security policies.  
         [0043]      FIG. 2D —is a detailed block diagram illustrating a set of unlock control rules which are referenced by certain of the security applications for unlocking of an authentication credential or cryptographic key.  
         [0044]      FIG. 2E —is a detailed block diagram illustrating a set of lock control rules which are referenced by certain of the security applications for locking of an authentication credential or cryptographic key.  
         [0045]      FIG. 2F —is a detailed block diagram illustrating an accounting data including various administrative parameters available for future review using an administrative services application.  
         [0046]      FIG. 2G —is a detailed block diagram illustrating a set of security control methods utilized by the token security services applications to implement a particular security policy.  
         [0047]      FIG. 2H —is a detailed block diagram illustrating a set of accounting data provided for performing auditing of transactions and other administrative functions.  
         [0048]      FIG. 3 —is a flow diagram illustrating the steps necessary to install an application into a security token using the invention.  
         [0049]      FIG. 3A —is a flow diagram illustrating the steps necessary to set prerequisite states for using a token services application.  
         [0050]      FIG. 3B —is a flow diagram illustrating the steps necessary to use a token services application. 
     
    
     DETAILED DESCRIPTION  
       [0051]     This present invention provides an application level security token architecture which supports modular security application installations without loss of existing data or requiring the reinstallation of existing applications served by the security application modules.  
         [0052]     The invention has the added features of providing a more uniform security application programming interface which improves overall interoperability of security applications, simplifies security application development and provides application level management and enforcement of security policies.  
         [0053]      FIG. 1P A depicts the prior art where a shareable interface  80  is incorporated into a security service application  40 . In the prior art, messaging between the security service applications  40 ,  40 A and the dependent token service applications  30 ,  30 A,  30   b  is accomplished by the runtime operating environment  5  which routes messages and data between the applications using the designated shareable interface  80  in essentially a client/server relationship. The dependencies  70 A, 70 B, 70 C, 70 D are shown as dashed lines. In this simplified example, if the PIN security service application  40  is removed, the shareable interface  80  and client dependencies  70 A, 70 B, 70 C, 70 D would be lost, including access to any data associated with the token service applications  30 , 30 A, 30 B. Also, the security services applications  40 , 40 A may be owned and administered by the security token issuer, which would allow access and configuration of security policies not necessarily compatible with those of the token service applications  30 , 30 A, 30 B provider. While only one sharable interface is shown, one skilled in the art will appreciate that multiple sharable interfaces may exist having a multiplicity of relationships.  
         [0054]      FIG. 1  depicts one embodiment of the invention&#39;s architecture where the shareable interface  80  is incorporated into a security domain control services application  10 . By relocating the shareable interface  80  to the security domain control services application  10 , the token security administrative services application  35 , the security services applications  40 , 40 A, 40 B and token services applications  30 , 30 A, 30 B become independent of each other, facilitating removal, replacement and/or addition of all three kinds of security applications without disruption of the existing interface dependencies  70 A,  70 B,  70 C,  70 D,  70 E,  70 F, 70 G.  
         [0055]     The invention&#39;s architecture allows configuration and enforcement of security policies  60  specific to each application  30 , 30 A, 30 B, 35 , 40 , 40 A, 40 B and is manageable by the owner of the security domain  50 . Each token security application is externally addressable using a unique application identifier (AID) shown as ID 1   105 , ID 2   105 A, ID 3   105 B, ID 4   115 , ID 5   115 A, ID 6   110 , ID 7   125  and ID 8   115 B.  
         [0056]     The runtime operating environment  5  is shown as a layer below the token security applications. The three basic types of token security applications include a token services application  30 , a token security administrative services application  35  and a token security services application  40 . Addressing the security applications may be accomplished explicitly using traditional APDU messaging or implicitly by remote method invocation (RMI) both of which are supported by the JCRE version 2.2. The “Java Card™ 2.2 Runtime Environment (JCRE) Specification,” and included as a reference to this specification.  
         [0057]     In addition, each token security application includes pre-established references incorporated into either or both application protocol data units (APDUs) or invokeable using remote method invocation (RMI). The references refer to the security policies  60  maintained and enforced by the security domain control services application  10 . The references are used by the security domain control services application  10  to determine the security prerequisites necessary for the token security application(s) to successfully perform a transaction. When using remote method invocation, the APDUs include remote object identifiers, method identifiers and includes any parameters to be passed to the receiving security application. A more detailed discussion of the pre-established commands and implementation of the security policies is provided in the discussion for  FIGS. 2A-2G .  
         [0058]     The token services application(s)  30  are applications which generally require implementation of some type of security policy(ies)  60  before performing a requested transaction. This type of application is envisioned to be the most common type of application installed inside the security domain  50 . Examples of token service applications include electronic wallets, credential verification applications, secure storage of personal information and management of loyalty credits.  
         [0059]     The token security administrative services application  35  allows creation and maintenance of security policies, parameters, logic based rules, transaction accounting, registration and deregistration of installed applications and other administrative parameters included in the security domain control services application  10 . This type of application is the least common type of application installed in the security domain  50  and provides specific authenticated access to the security policies, parameters, rules and administrative information associated with each compliant security application installed in the security domain  50 .  
         [0060]     As such, each application provider may access and manage their own applications but are prohibited from accessing or altering the security policies, parameters and rules of other entities installed inside other security domains present in the security token.  
         [0061]     The token security administrative services application  35  is shown as a separate application, however, it is also envisioned by the inventor that the functionality of the administrative services application  35  may be incorporated into the security domain control services application  10  to conserve critical storage space and improve execution speed.  
         [0062]     The token security services application(s)  40  perform authentication, secure messaging  40 A and authorization functions  40 B. This type of application is anticipated to be the second most common type of program installed in the security domain  50 . The token security services application(s) establish the prerequisite security state(s) required by the token service application(s)  30  and set using the token security administrative services application  35 . The end result(s) of executing one or more of the token security services applications  40  are recorded in a registry and enforced by the security domain control services application  10  as prescribed by the security policies  60 .  
         [0063]     Examples of token security services applications include entity authentication using personal identification numbers (PIN), authentication using biometrics, secure messaging using IPsec, SSH, SSL, TLS, WAP, etc., and validating internal and external criteria against at least one set of rules. In the preferred embodiment of the invention, limited PIN and biometric unlock features are available through the token security services applications to minimize external support or “help desk” requirements.  
         [0064]     Each of the client security applications  30 ,  30 A,  30 B,  35 ,  40 ,  40 A,  40 B may be associated with an interface  15 ,  15 A,  15 B,  20 ,  25 ,  25 A,  25 B. The interfaces, shown in dotted lines, provide a collection of routines and library functions that are used by the client security applications to communicate with the server security domain control services application  10 . In the preferred embodiment of the invention, the interfaces  15 ,  15 A,  15 B,  20 ,  25 ,  25 A,  25 B are incorporated or linked to the security applications  30 , 30 A, 30 B, 35 , 40 , 40 A, 40 B when loaded into the security token. For backward compatibility the interfaces may be installed as separate modules.  
         [0065]     Each of the security applications  30 ,  30 A,  30 B,  35 ,  40 ,  40 A,  40 B will utilize a copy or instance of the interface module specific to the type of security application, to communicate with the security domain control services application  10 . The type of interface controls access to various entry points and services available in either the security domain control services application  10  or runtime operating environment.  
         [0066]     The security domain control services application  10  provides a uniform security applications programming interface (API) between the token&#39;s runtime operating environment and the security applications  10 ,  30 ,  30 A,  30 B,  35 ,  40 ,  40 A,  40 B installed within the security domain  50 . The security domain control services application  10  is designed to provide and enforce application level security policies  60  rather than relying on “generic” security policies established by the security token issuer.  
         [0067]     An object-oriented framework for the security domain control services application  10  is envisioned for post issuance installations and backward compatibility using Java Cards™. In another embodiment of the invention, the security domain control services application  10  is written in the native code language of the token processor and installed by the token manufacturer. The invention is intended to coexist with other API level applications including components associated with the GlobalPlatform specification. GlobalPlatform is not required for implementation of this invention.  
         [0068]     In  FIG. 1A , a typical embodiment of the invention is depicted where several security domains  50 A,  50 B,  50 C are installed inside a security token. Each security domain may register itself with another security domain to allow interoperability between security applications in separate security domains.  
         [0069]     In reference to  FIG. 1B , an alternate embodiment of the invention is shown where prerequisite security applications are incorporated into the security domain control services application  10 . This embodiment of the invention takes into account that a token security administrative services application  35 , a token security services application  40  related to user PIN authentication and at least one token security services application  40 C related to secure messaging will always be required as a prerequisite to the successful execution of one or more of the token services applications  30 ,  30 A,  30 B. The integration of the two security applications into the security domain control services application  10  does not materially change the functionality of the invention but may provide limited memory storage savings and improved execution speed.  
         [0070]     Referring to  FIG. 2 , the security domain control services application  10  is associated with the security policies  60  to be enforced. The security policies  60  are comprised of a registry  205 , access control rules  210 , unlock control rules  215 , lock control rules  220 , security control methods  280 , authorization rules  270  and accounting data  225 . The registry  205  includes a plurality of security parameters related to the installed security applications  30 , 35 , 40 . Single or multiple registries  205  are envisioned which allows for future development and optimization. The access control rules  210  includes the security requirements related to authentication and secure messaging to be enforced by the security domain control services application  10 .  
         [0071]     The unlock control rules  215  include the security policies to be enforced by the security domain control services application  10  for unlocking of a credential or a cryptographic key. The lock control rules  220  include the security policies to be enforced by the security domain control services application  10  to prevent use of a credential or a cryptographic key. The security control methods  280  provides a mechanism where parameters required to accomplish a certain task such as authentication or secure messaging are maintained and associated with a particular access or unlock control rule. The security control methods  280  also allow incorporation of authorization rules  270  into the overall security policies. The authorization rules  270  are provided as a way to extend the security policies to other parameters or states not normally maintained as part of the registry.  
         [0072]     The accounting data  225  includes administrative parameters and information accessible by the token security administrative services application  35  for use in configuring and managing the security policies associated with the particular security domain  50 .  
         [0073]     It will be appreciated by one skilled in the art that the types of parameters, data structures and functional relationships with other parameters may be varied to accomplish a particular security policy. The parameters, structures and functional relationships shown in the drawings are intended as examples only. No limitation of the invention should be construed from these examples.  
         [0074]     In  FIG. 2A , example pre-established references to sets of predefined security policies are shown. For simplicity and ease in understanding of the invention, actual APDU formats and/or java method and object identifiers are excluded. The codes contained in the ovals associated with the token services application  30  and token security administrative services application  35  refers to the logic based rules shown in  FIGS. 2C, 2D  and  2 E, while the codes included in ovals associated with the token security services application  40  refers to the authorization rules and security control methods shown in  FIGS. 2F  and G.  
         [0075]     For example, the token services application  30  is shown associated with two pre-established references  202  representing access control rules. In practice, there may be several pre-established references to perform different functions available to a particular application as specified by the code included in the ovals. The references  202  may be linked directly to the token services application  30  or incorporated into the interface module  15  shown in  FIG. 1 . For backward compatibility purposes, actual access control rules rather than references may be included in either the token services application  30  or interface  15 .  
         [0076]     The references  204  associated with the token security administrative services application  35  allows administrative tasks to be performed on the credential and cryptographic key unlock rules, access control rules, lock control rules and accounting data. In the preferred embodiment of the invention, the token security administrative services application  35  has full editing capability of the registries, credential and cryptographic key unlock rules, access control rules, lock control rules, security control methods, authorization rules and accounting data. The references  204  may be linked directly to the token security administrative services application  35  or incorporated into the interface module  20  shown in  FIG. 1 . For backward compatibility purposes, actual access control rules rather than references may be included in either the token services application  35  or interface  20 .  
         [0077]     The references  206  associated with the token security services application are used to perform authentications, establish secure messaging, verify authorization states and allow limited credential unlocking capabilities. The references  206  to the security control methods shown in  FIG. 2G  may be linked directly to the token security services application  40  or incorporated into the interface module  25  shown in  FIG. 1 . For backward compatibility purposes, actual access control rules rather than references may be included in either the token services application  40  or interface  25 . The references  202 ,  204  and  206  may exist in a traditional APDU command format or in the remote object and method identifier formats required for use with remote method invocation services.  
         [0078]     Referring to  FIG. 2A   1  an alternate embodiment of the invention is shown where the token services application  30  transfers a minimal APDU which includes only the mandatory header information of class (CLS), instruction step INS and parameter bytes (P 1 , P 2 ). This arrangement simplifies interfacing requirements and improves communications efficiencies between the security applications. In this embodiment of the invention, a request for service  223  causes the token services application to send  227  an APDU comprised essentially of an instruction step INS[ 00 ]  208 A to the security domain control services application  10 . The security domain control services application  10  determines the applicable security policies  208 B to enforce based on the received instruction step INS[ 00 ]  208 A. The determined security policies are then enforced  232  on the token security services application  40 A.  
         [0079]     Referring to  FIG. 2A   2  a variation of the inventive embodiment described for  FIG. 2A   1  is shown. In this embodiment of the invention, a request for service  223  causes the token services application to send  227  an APDU comprised essentially of an instruction step INS[ 00 ]  208 A to the security domain control services application  10  as before. However, in this embodiment of the invention, the security domain control services application  10  determines the applicable security policies  60  and returns  235  to the token services application  30  an APDU which includes the address AID[ID 5 ]  233  of the token security services application  40 A specified by the applicable security policies  60 . The token services application  30  then addresses  236  the token security services application  40 A directly as part of the security policy enforcement.  
         [0080]     Referring to  FIG. 2B , an example registry  205  is depicted and includes a number of separate parameters. The registry  205  is maintained by the security domain control services application. The first set of parameters included in the registry relates to available token services  207 . For example, authentication (AM 0 , AM 1 ), secure messaging (SM 0 , SM 1 ), electronic wallet (EW 1 ) administrative services (AD 1 ) and external information (EX). Each separate entry being indicative of a separately available application operatively installed in the associated security domain.  
         [0081]     Associated with each installed application is a unique application identifier ID  209 , which is used to address the specific application. Optional, but highly desirable parameters include a retrievable list of available service types Type  211  for example, token security services such as authentication and secure messaging are denoted by SS, token services applications such as an electronic wallet is denoted by TS and token administrative services such as auditing is denoted as AS. The enablement status of each registered application is provided  213 . The ability to enable or disable a registered application is performed using the token administrative services application to change the status flag  213  included in this portion of the registry  205 . If the registered application is not enabled  213 , the application will not be allowed to operate.  
         [0082]     Lastly, it is envisioned that one or more multifunction applications may be installed. In order to control each portion of the multifunction application, a set of functional control elements  262  is provided. The functional control elements include instruction codes  269  which are interpreted when the selected application is executed. The number of functional control elements shown are for example only.  
         [0083]     The actual number of functional control elements may vary depending on the applications installed. In a traditional embodiment of the invention, the functional elements utilize standard instruction bytes or when using remote invocation services, the functional control elements utilize remote method and object identifiers.  
         [0084]     A second set of parameters included in the registry relates to credential management. Each available credential  217  is included in this portion of the registry and associated with a unique identifier ID  219 . The current authentication state  222  for each credential is recorded in the registry  205 . The current credential authentication state  222  is verified by the security domain control services application in accordance with the predefined security policies. For example, an electronic wallet may require user authentication by a PIN entry before access to electronic funds is permitted. If the proper PIN state  222  is not present, the user will be prevented from accessing the electronic funds.  
         [0085]     The optional, but highly desirable parameters associated with the second set of parameters include tracking of the number of failed access attempts  228  associated with a particular credential, maximum number of attempts  230 , locked  231  status flags for credentials where an excessive number of failed access attempts has occurred, expiration date or expired status flag  234 , maximum number of uses of a credential  237  before the credential becomes locked  231 , the number of current or remaining uses of a credential  239 , the associated lock rules identifier  241  and the administrative status of each installed application is provided  243 . The ability to enable or disable an installed credential is performed using the token administrative services application to change the status flag included in this portion of the registry  243 . Activation or deactivation of a credential is accomplished by changing the status of the credential flag in the registry  243 .  
         [0086]     A third set of parameters included in the registry  205  relates to cryptographic key management. Each available cryptographic key  245  included in this portion of the registry  205  is associated with a unique identifier ID  247 . Session flag  249  is available to determine if an active session has been established.  
         [0087]     Optional, but highly desirable parameters associated with the third set of parameters include expiration date or expired status flag  251 , maximum number of uses of a cryptographic key before the key becomes locked  253 , the number of current or remaining uses for a cryptographic key  255 , locked  257  status flag and its associated lock rule identifier  259 , and the ability to administratively enable or disable each installed cryptographic key using the token administrative services application to change the enabled  261  status flag included in this portion of the registry. Activation or deactivation of a cryptographic is accomplished by changing the status of the credential in the registry  261 .  
         [0088]     Referring to  FIG. 2C , an example set of access control rules  210  is provided. Each access control rule  214  is associated with a unique identifier  212 . The access control rules  214  specifies which token security service applications must have completed processing successfully including updating of their associated entries in the registry  205  before a token services application may successfully complete processing.  
         [0089]     The unique identifier  212  has a functional relationship to a particular security control method  280  shown in  FIG. 2G , and is processed by the security domain control services application. The security domain control services application verifies that all prescribed required states and parameters are satisfied. If one or more required states or parameters differ from the particular access control rule  214  requirements, the requesting security application receives a negative response from the security domain control services application and the transaction ends. If the security requirements are verified processing continues. The access control rules  210  include the logical operators AND, OR or NULL (none). Other Boolean or logic based rules are envisioned as well. The access control rules are combinable with other security rules or security parameters. Administration of the access control rules  210  and related parameters is accomplished using the token security administrative services application.  
         [0090]     The operation of the access control rules  210  is shown by way of example. Referring to  FIG. 2A , if the token services application  30  is executed with the security policy requirements specifying access control rule AC 00   208 , the security domain control services application would interpret the access control rule AC 00   218  as shown below;  
                                                                     AC00 PIN1 AND XAUT1                0   {circumflex over ( )}   1 = 0 FAIL                      
 
         [0091]     Referring again to  FIG. 2B , the security domain control program would verify that the pre-requisite registry states controlled by authentication application AM 1   263  in conjunction with PIN 1   265  and secure messaging using secure messaging application SM 1   264  in conjunction with cryptographic key XAUT 1   269  are present in the registry.  
         [0092]     Based on the result of this example, the security requirements have not been met and a negative response will be returned to the requesting application and processing terminated. The relationship between a token security services application and access control rules is more fully described in the accompanying discussion for  FIGS. 2F  and G.  
         [0093]     Referring to  FIG. 2D , a first special case of access control rules referred to as unlock control rules  215  are provided for unlocking a credential or cryptographic key which has become disabled due to an excessive number of failed authentication attempts or possible compromise. Each unlock control rule  224  is associated with a unique identifier  220 . The unique identifier  220  for a particular unlock control rule is referenced by either a token security services application or token administrative services application and processed by the security domain control services application analogously to the access control rules described above. The unlock control rules  215  likewise use logical operators such as AND, OR or NULL (none.) Other Boolean or logical based operators such as NOT, unions, etc. are also envisioned.  
         [0094]     An optional set of parameters  226  are included which specifies the credential or cryptographic key associated with a particular unlock rule. The unlock control rules  224  shown are intended as examples only. Administration of the unlock control rules  224  is accomplished using the token administrative services application. The unlock control rules are likewise combinable with other security rules or security parameters.  
         [0095]     The operation of the unlock control rules  215  is again shown by way of example. Referring to  FIG. 2A , if the token administrative services application  35  is executed with the security policy requirements specifying unlock control rule UC 01   201 , the security domain control services application would interpret unlock control rule UC 01   201  as shown below;  
                                                                     UC01 BIO2 AND PKI1                1   {circumflex over ( )}   1 = 1 PASS                      
 
         [0096]     Referring back to  FIG. 2B , the security domain control program would verify that the pre-requisite registry states controlled by authentication application AM 0   266  in conjunction with BIO 2   267  and secure messaging using secure messaging application SM 2   264  in conjunction with cryptographic key PKI 1   268  are present in the registry  
         [0097]     Based on the result of this example, the security requirements have been met allowing the Lock status flag  231  associated with PIN 2   271  to be unlocked. The relationship between a token security services application and access control rules is more fully described in the accompanying discussion for  FIGS. 2F  and G.  
         [0098]     Referring to  FIG. 2E , a second special case of access control rules referred to as lock control rules  220  are provided for locking a credential or cryptographic key which should be disabled due to an excessive number of failed authentication attempts or possible compromise. Each lock control rule  283  is associated with a unique identifier  281 . The unique identifier  281  for a particular lock control rule is referenced by either a token security services application or token security administrative services application and processed by the security domain control services application analogously to the access control rules described above.  
         [0099]     An optional set of parameters  285  are provided which specifies the credential or cryptographic key associated with the particular lock rule. The lock control rules  225  include the logical operators AND, OR or NULL (none), GREATER THAN, LESS THAN, NOT EQUAL TO and EQUAL TO. Other Boolean or logic based rules are envisioned as well. Administration of the lock control rules  220  is accomplished using the token security administrative services application. The lock control rules are likewise combinable with other security rules or security parameters.  
         [0100]     The operation of the lock control rules  220  is again shown by way of example. Referring to  FIG. 2A , if the token administrative services application  35  is executed with the security policy requirements specifying unlock control rule LC 01   203 , the security domain control services application would interpret unlock control rule LC 01   203  as shown below;  
                                                             LC01 C_USE &gt; MAX_USE                301 &gt; 300 = 1 (TRUE)                      
 
         [0101]     Referring back to  FIG. 2B , the security domain control program would compare the Max Use  237  to the Current Use  239  parameters for PIN 2   273  which would result in PIN 2  becoming locked  271  due to excessive usage.  
         [0102]     Referring to  FIG. 2F , authorization rules  270  are provided which allows for additional the extension of the security policies to other parameters or states not normally maintained as part of the registry. Each authorization rule is associated with a unique identifier  272 . The unique identifier  272  for a particular authorization rule is referenced by the security domain control services application during execution and may refer to either internal or external sources of information. For example, in order for a particular internal applet to be permitted to execute, a revision number greater than a base number may be required.  
         [0103]     Alternately, another applet may be only be permitted to execute when an associated external host has a particular universal resource locator ID. The authorization rules  274  may utilize AND, OR or NULL (none), GREATER THAN, LESS THAN, NOT EQUAL TO and EQUAL TO. Other Boolean or logic based rules are envisioned as well. Administration of the authorization rules  270  is again accomplished using the token security administrative services application and are likewise combinable with other security rules. It will be appreciated by one skilled in the art that other internal and/or external criteria may be utilized for an authorization rule.  
         [0104]     Referring to  FIG. 2G , security control methods  280  are provided which are utilized by the token security services applications to implement a particular security policy. Each security control method is associated with a unique identifier  282 . The unique identifier  282  for a particular security control methods is referenced by a token security services application in order to establish a pre-requisite security state. Each security control method is associated with a specific access control rule  284  and provides the methodology  286  and required parameters for the token security services applications to implement a security policy.  
         [0105]     For example, referring back to  FIG. 2A , a token security services application  40  is executed with the security policy requirements specifying security control method SCM 00   216 , the token security services application would implement the security control method SCM 00   216  by executing access control rule AC 00   218  shown in  FIG. 2C . Referring now to  FIG. 2B , access control rule AC 00   218  requires authentication applet AM 1   263  in conjunction with PIN 1   265  and establishment of secure messaging using secure messaging applet SM 1   264  in conjunction with cryptographic key XAUT 1   269 . The actual security control method SCM 00   288  specifies the proper credentials to use in authentication transactions and proper cryptographic keys to use in secure messaging sessions. In addition, accounting policies and authorization rules may be added to a particular security control method.  
         [0106]     Lastly, referring to  FIG. 2H , accounting data  225  is provided for performing auditing of transactions and other administrative functions. Each entry in the accounting data  225  is associated with a unique identifier  287 , an optional transaction type  289  such as security services (SS), token services (TS) or administrative services (AS) transactions, a failed or successful status entry  291 , an exception  293  entry indicating which access control rule was violated, and a time stamp entry  295 . Access to the accounting data  225  and selection of the parameters to be audited are configurable using the token security administrative services application. As with all the previous rules and parameters, administration of the security control methods  280  is accomplished using the token security administrative services application.  
         [0107]     It will be appreciated by one skilled in the art that the specific parameters employed and their interrelationships with the access control rules, lock control rules, unlock control rules, security control rules and accounting data may be varied to accomplish a specific security arrangement or security policy without deviating from the spirit and intent of this invention.  
         [0108]     In  FIG. 3 , a flow chart is shown which details the necessary steps for the installation of a security application. The process is initiated  300  by receiving a security domain control services downloadable. In a multiple security domain environment, the security domain control services downloadable is registered with a central security domain control services application  303  to allow interoperability between security domains. In either case, the following step requires that the security application downloadable be received  304  and registered  306  with the security domain control services downloadable. The next step is to configure the security policies  308  associated with the security application downloadable including access control rules, lock and unlock control rules, security control methods, associated credentials and cryptographic keys, etc. which are retained by the security domain control services downloadable.  
         [0109]     The next step requires that the required security states be established for the security application downloadable  310 . If one or more additional security application downloadables are to be installed, steps  304 - 310  are repeated. Otherwise, this ends the installation process  314 .  
         [0110]     Referring to  FIG. 3A , once the security application downloadables are properly installed as described above, the use of the newly installed security applications are controlled by their associated security policies. To use the new security applications the process begins  320  by performing an authentication  322  in accordance with one or more security control methods  326 . If one or more applicable authorization methods are required, then the authorization rules  328  are implemented. If accounting data is required, then the accounting data is collected  330 . Upon completion of all required steps  326 ,  328 ,  330  the authentication state  324  is set in a registry. If the security policies do not require secure messaging, processing ends  336 .  
         [0111]     If the security policies do require secure messaging, a secure messaging session is established  332  in accordance with one or more security control methods  326 . If one or more applicable authorization methods are required, then the authorization rules  328  are implemented. If accounting data is required, then the accounting data is collected  330 . Upon completion of all required steps  326 ,  328 ,  330  the secure messaging state  334  is set in the registry followed by processing end  336 .  
         [0112]     Referring to  FIG. 3B  in order to use the security application, the process is initiated  340  by executing the security application  342  and verifying if the security application module is enabled  344 . If the security application is not enabled  344  processing ends  356 . Otherwise, processing continues by determining whether the portion (i.e., functional control element) of the security module is enabled  346 . If the portion of the security application is not enabled  346 , processing ends  356 . Otherwise, processing continues by retrieving a security policy  348  and validating the applicable security policy. If security policy is not validated  352 , processing ends  356 . If the applicable security policy is validated  352 , the security application completes the transaction  354  followed by normal end of processing  358 .  
         [0113]     The foregoing described embodiments of the invention are provided as illustrations and descriptions. They are not intended to limit the invention to precise form described. In particular, it is contemplated that functional implementation of the invention described herein may be implemented equivalently in hardware, software, firmware, and/or other available functional components or building locks. No specific limitation is intended to a particular security token operating environment. Other variations and embodiments are possible in light of above teachings, and it is not intended that this Detailed Description limit the scope of invention, but rather by the Claims following herein.