US20040221174A1 - Uniform modular framework for a host computer system - Google Patents

Uniform modular framework for a host computer system Download PDF

Info

Publication number
US20040221174A1
US20040221174A1 US10/425,028 US42502803A US2004221174A1 US 20040221174 A1 US20040221174 A1 US 20040221174A1 US 42502803 A US42502803 A US 42502803A US 2004221174 A1 US2004221174 A1 US 2004221174A1
Authority
US
United States
Prior art keywords
security
token
application
policies
composite
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/425,028
Inventor
Eric Le Saint
John Boyer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ActivIdentity Inc
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US10/425,028 priority Critical patent/US20040221174A1/en
Assigned to ACTIVCARD IRELAND, LIMITED reassignment ACTIVCARD IRELAND, LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BOYER, JOHN, LE SAINT, ERIC
Priority to EP04291090.1A priority patent/EP1473618B1/en
Publication of US20040221174A1 publication Critical patent/US20040221174A1/en
Priority to US11/939,444 priority patent/US7921298B2/en
Priority to US12/932,499 priority patent/US8732478B2/en
Priority to US13/065,992 priority patent/US8942429B2/en
Assigned to ACTIVCARD IRELAND, LIMITED reassignment ACTIVCARD IRELAND, LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ACTIVIDENTITY, INC.
Assigned to ACTIVIDENTITY, INC. reassignment ACTIVIDENTITY, INC. CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNOR AND ASSIGNEE NAMES PREVIOUSLY RECORDED ON REEL 029444 FRAME 0562. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT OF ASSIGNORS INTEREST. Assignors: ACTIVCARD IRELAND LIMITED
Priority to US14/248,389 priority patent/US9576111B2/en
Priority to US15/402,307 priority patent/US20170195368A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • G06F21/121Restricting unauthorised execution of programs
    • G06F21/123Restricting unauthorised execution of programs by using dedicated hardware, e.g. dongles, smart cards, cryptographic processors, global positioning systems [GPS] devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/32User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/34User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/006Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models

Definitions

  • the present invention relates generally to a data processing system, method and computer program product and more specifically to a uniform security application framework for a host computer system in communication with a security token.
  • one vendor may excel at providing user authentication mechanisms using dynamic passwords while another may excel at providing certain types of biometric authentication mechanisms such as fingerprint reading, while another may excel at providing biometric iris scanning mechanisms.
  • This invention addresses the limitations described above and provides a uniform applications framework for host computers which supports modular host security application installations and allows independent operations of applications installed in the security token.
  • proprietary biometric applications such as match on card technologies are decoupled from other host middleware applications and from the applications installed in the security token.
  • security token 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), Trusted Computer Platform Alliance chip (TCPA), and like devices. Temporary virtual security tokens are included as well.
  • credential refers to critical security parameters (CSP) such as authentication data, passwords, PINs, biometric templates, secret and private cryptographic keys and challenge/response messages or combinations thereof.
  • CSP critical security parameters
  • parameter refers to a status flag, text, a number, arguments or an argument name assigned to a value that is passed from one routine to another or used as a means of customizing program operation which is broader than its normal context.
  • the invention comprises a system which provides a uniform security applications framework for a host computer system which cooperates with one or more compliant security tokens.
  • the compliant security token(s) is in processing communications with the host computer system and includes a compatible uniform security framework which interfaces with the host security framework, a set of token security policies and one or more token security applications.
  • the host computer system includes a token access control application, token selection policies and several security application agents which are counterparts to the token security application(s).
  • a set of host security policies associated with each of the security application agents is retrievably coupled to the token access control application.
  • the token access control application allows the retrieval of at least a portion of the token security policies from which a composite set of security policies is generated by logically combining the host security policies, token selection policies and the token security policies.
  • the token access control application determines that a required security application agent and/or token security application is not present, the required applications may be downloaded and operatively installed from either a local or a remote storage location as individual modules without disruption of existing dependencies.
  • the token access control application further includes the ability to receive a credential, cause at least one of the security application agents to execute in response to an access request and the ability to send a credential to the appropriate security application agent.
  • ensuring enforcement of the composite security policies is performed by the applicable security application agents which receive the composite security policy from the token access control application.
  • a hierarchy exists between security application agents which causes the required security application agents to execute sequentially in accordance with the applicable portion of the composite set of security policies.
  • credentials are sent directly to the appropriate security application agent.
  • the responsibility for ensuring enforcement of the composite set of security policies is performed by a calling application.
  • the token access control application generates the composite security policies and forwards them to a calling application.
  • the calling application then sequentially causes the required security application agents to execute sequentially in accordance with the applicable portion of the composite set of security policies.
  • credentials are forwarded to the appropriate security application agent by the calling application.
  • the security application agents include the ability to perform a security function with one or more counterpart token security applications in accordance with the composite set of security policies and return objects in which a security function is performed by a token application.
  • the security application agents may exist as separate applications, dynamically linked libraries associated with the token access control application or any combination thereof.
  • the composite set of security policies includes token access control rules, host access control rules, token selection rules and composite access control rules but lacks a registry.
  • an operating system installed on the host administers the security application agents.
  • a local registry is included which is administered by the token access control application.
  • the local registry is comprised of enablement flags and operational states related to authentication, secure messaging and application enablement.
  • Each available application requires a corresponding entry in the registry including registered token security applications and registered security agent applications.
  • the token security applications includes a token security domain control application, a token services application, a token administrative services application to and a token security services application.
  • the token security services application includes the ability to perform authentication and secure messaging.
  • the token services application includes the ability to perform cryptography, return objects in which a security function was performed to a security agent application.
  • the object includes a credential, a digital certificate, data to undergo a cryptographic function or data to be stored in said security token.
  • Processing by the uniform security framework involves the following steps:
  • step d. includes the steps of;
  • the invention also provides for retrieval of compatibility information related to one or more counterpart security application agents from a functionally connected security token by at least one security application installed on a host computer system wherein the retrievable capability information relates to compatibility between the one or more counterpart security application agents and the one or more token security applications.
  • the at least one security application includes functionality for;
  • the at least one security application includes either a security application installed in a middleware services layer or is a token access control application retrieved from either a local or remote storage location.
  • Installation of the retrieved at least one compatible counterpart security application agent is accomplished by entering one or more parameters associated with the at least one compatible counterpart security application agent in a registry.
  • the at least one compatible counterpart security application agent is a nodular software application which can be added, removed or replaced without disruption of any existing dependencies by changing the one or more parameters in entered in the registry.
  • the programs and data may be placed onto transportable medium such as a CD ROM, floppy disk, data tape, portable hard disk, flash memory device or DVD for installing on a host computer system.
  • transportable medium such as a CD ROM, floppy disk, data tape, portable hard disk, flash memory device or DVD for installing on a host computer system.
  • FIG. 1 is a generalized block diagram of a host computer system and a electromagnetically connected security token.
  • FIG. 1A is a detailed block diagram invention illustrating the relationship and arrange of various applications employed in the invention.
  • FIG. 1B is a detailed block diagram illustrating a plurality of available security tokens for implementing the invention.
  • FIG. 1C is a detailed block diagram illustrating retrieval and installation of a security application agent or a token security application.
  • FIG. 2 is a detailed block diagram illustrating the functional relationship between a token access control application (TACA) and associated security and token policies.
  • TACA token access control application
  • FIG. 2A is a detailed block diagram illustrating an embodiment of the invention which uses a registry having an associated with the security policies.
  • FIG. 2B is a detailed block diagram illustrating token selection policies and rules.
  • FIG. 2C is a detailed block diagram illustrating host access control policies and rules.
  • FIG. 2D is a detailed block diagram illustrating token access control policies and rules.
  • FIG. 2E is a detailed block diagram illustrating a composite set of access control rules derived from the logical combination of host and token access control rules.
  • FIG. 3 is a detailed block diagram illustrating a first embodiment of the invention.
  • FIG. 3A is a detailed block diagram illustrating a second embodiment of the invention.
  • FIG. 3B is a detailed block diagram illustrating a third embodiment of the invention.
  • FIG. 4 is a flow diagram illustrating the major steps necessary to implement the first embodiment of the invention.
  • FIG. 4A is a flow diagram illustrating the major steps necessary to implement the second embodiment of the invention.
  • FIG. 4B is a flow diagram illustrating the major steps necessary to implement the third embodiment of the invention.
  • FIG. 4C is a flow diagram illustrating the major steps necessary to retrieve compatibility information from the security token to the host computer system.
  • This present invention provides a uniform host application framework which separates authentication and secure messaging functions into modular security applications, allows interoperability of host security applications and interfaces with security tokens having a compatible internal framework.
  • the invention further allows selection of individual security tokens to perform selected security tasks administered by token selection policies.
  • 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.
  • the applications are envisioned to be programmed using high level programming languages such as JavaTM, Visual BasicTM, C++ or C.
  • a typical host computer system 105 which includes a processor 5 , a main memory 10 , a display 20 electromagnetically coupled to a display interface 15 , a secondary memory subsystem 25 electromagnetically coupled to a hard disk drive 30 , a removable storage drive 35 electromagnetically coupled to a removable storage unit 40 and an auxiliary removable storage interface 45 electromagnetically coupled to an auxiliary removable storage unit 50 .
  • a communications interface 55 subsystem is coupled to a network interface 60 and a network 65 , a security token interface 70 and a security token 75 , a user input interface 80 including a mouse and a keyboard 85 , a biometric scanner interface 90 and a biometric scanner 95 .
  • the processor 5 , main memory 10 , display interface 15 , secondary memory subsystem 25 and communications interface system 55 are electromagnetically coupled to a communications infrastructure 100 .
  • the host computer system 105 includes an operating system, a token access control application (TACA) and associated middleware security agent application agents, one or more applications requiring security services from a security token 75 , cryptography software capable of performing symmetric and asymmetric cryptographic functions, secure messaging software and device interface software. Data necessary to support the security functions should be assumed to be present as well.
  • TACA token access control application
  • the security token 75 includes a wireless and/or electrical connection means compatible with the security token interface 70 , a processor, volatile and non-volatile memory electromagnetically coupled to the processor, a runtime operating environment, cryptography extensions incorporated into the operating system and capable of performing symmetric and asymmetric cryptographic functions compatible with the host cryptography software, a security domain access control application (SDCA) and associated security applications, one or more credential protected applications functionally coupled to the security executive application and a public key infrastructure (PKI) key pair functionally coupled to the security executive application. Data necessary to support the security functions should be assumed to be present as well.
  • the non-volatile memory has operatively stored therein one or more reference credentials which are verified by the security applications to allow access to the one or more credential protected applications.
  • FIG. 1A depicts the invention and associated host applications and resources.
  • a plurality of security applications for example, a biometric based application 114 , a signing based application 118 and an authentication based application which uses a personal identification number (PIN) 122 .
  • the security applications are coupled to an applications programming interface (API) layer 128 .
  • the API layer includes a set of routines used by the application program to direct the performance of procedures by the host's operating system.
  • the API layer 128 is shown in dotted lines to indicate that no substantial changes are made to the functionality of this layer.
  • the API layer 128 rides above a cryptographic services layer 134 .
  • the cryptographic services layer 134 allows access to host cryptographic resources and acts as a gateway to a middleware services layer 138 .
  • the middleware services layer 138 routes requests for token services sent by the host applications 114 , 118 , 122 to a token access control application (TACA) 142 .
  • TACA token access control application
  • the middleware services layer 138 is intended to provide a consistent and modular application interface between the security applications 114 , 118 , 122 and the token access control application (TACA) 142 and in an alternate embodiment of the invention, maintains security application agent module consistency with their counterpart security applications 186 , 188 , 192 , 194 , 198 installed inside the security token 75 .
  • the TACA 142 is associated with a set of token security policies 146 that controls which security token will perform a specific type of security transaction when a plurality of security tokens are available to perform the transaction.
  • the TACA 142 is also associated with a set of host security policies 152 which controls a security function of one or more security application agents 156 , 162 , 166 , 168 , 172 and in one embodiment of the invention, maintains security application agent module consistency with their counterpart security applications 186 , 198 , 192 , 194 , 198 installed inside the security token 75 .
  • the security application agents 156 , 162 , 166 , 168 , 172 may exist as separate applications, dynamically linked libraries associated with the token access control application or any combination thereof. Both the security application agents 156 , 162 , 166 , 168 , 172 and token security applications 186 , 188 , 192 ; 194 , 198 are modular in nature and may be retrieved locally if available on a local hard drive or downloaded from a centralized repository and dynamically installed without disruption of existing dependencies, which is a central concept of the uniform modular framework.
  • the uniform modular framework being comprised of the API layer 128 , cryptographic services layer 134 , middleware services layer 138 , token access control application 142 , token messaging layer 176 , token runtime operating environment 178 and security domain control application 182 .
  • the TACA ensures enforcement of the security policies.
  • the appropriate security application agents 156 , 162 , 166 receives the security policies from the TACA and self enforces the security policies.
  • the TACA sends the security policies to the requesting application which ensures enforcement of the security policies.
  • the security application agents 156 , 162 , 166 , 168 , 172 are designed to perform a security function in conjunction with their counterpart security applications 182 , 186 , 188 , 192 , 194 , 198 installed in the security token 75 .
  • the security application agents functionally decouples security applications installed on the host from those applications installed in the security token, allowing greater interoperability between host applications and security token applications and is part of the nodular plug-in architecture.
  • a typical arrangement of security application agents includes a PIN agent 156 , a biometric agent 162 , a secure messaging agent 166 and a public key cryptography agent 168 . Additional agents may be installed to perform other functions as is shown by the other agent 172 . In another embodiment of the invention, administrative control of the security application agents 156 , 162 , 166 , 168 , 172 remains with the operating system installed on the host.
  • a token messaging layer 176 provides communications protocol conversion into ISO 7816 compliant application protocol data unit (APDU) format. Addressing of the counterpart token 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 CardTM 2.2 Runtime Environment (JCRE) Specification,” is included as a reference to this specification.
  • a security token 75 includes a security domain control application (SDCA) 182 coupled to a runtime operating environment 178 and a set of token security policies 184 .
  • the token security policies control a security function associated with a PIN application 186 , a biometric application 188 , a secure messaging application 192 , a PKI cryptography application 194 and an additional application 198 .
  • the token security applications 186 , 188 , 192 , 194 , 198 each includes information 185 , 187 , 191 , 193 , 197 which is used by the middleware services layer 138 to determine if the proper counterpart security application agent(s) 156 , 162 , 166 , 168 , 172 is installed.
  • This information is transferred along with the token security policies and is used by the middleware services layer 138 for security application agent version control and security application agent module loading.
  • the operation of the token security applications and SDCA is described in co-pending U.S. application Ser. No. 10/321,624 to Eric Le Saint & al., entitled “Uniform Framework for Security Tokens” and filed on Dec. 18, 2002
  • the security tokens include a traditional smart card 75 A, a Trusted Computer Platform Alliance (TPCA) chip 75 B, a local virtual security 75 C, a remote virtual security 75 D, a remote TPCA chip 75 E or a hardware security module (HSM) 75 F.
  • the token access control application (TACA) 142 selects the appropriate security token in which to process a security transaction based on criteria included in the Token Policies 146 .
  • One or more of the security tokens may be employed to complete a security transactions.
  • authentication may be performed using a local virtual security token 75 C installed in the host 105 and a remote virtual security token 75 D installed in a remote server 195 connected by a network 65 may be used to establish secure messaging.
  • the TACA 142 or middleware services layer 138 determines that a required security application agent either not present or incompatible with a token security application, the application agent 127 a maybe securely retrieved from a local storage location 125 a or the application 127 b may be downloaded a remote storage location 125 b and installed in the applicable location(s).
  • the new application is registered in either a registry table maintained by the host operating system or a separate registry table maintained by the TACA 142 described below.
  • An optional code authentication may be performed by comparing digital signatures before installation and registration is performed.
  • the composite security policies 152 C include a set of logic based host access control rules 210 , a set of logic based token access control rules 215 and a composite set of access control rules 217 derived from the logical combination of the host access control rules 210 and the token access control rules 215 .
  • the composite security policies 152 C may be stored locally on the host or stored remotely on a security server and retrieved by the host TACA 142 .
  • a local registry 205 (shown in dashed lines) is included.
  • the local registry is administered by the TACA 142 and provides additional administrative controls over the security application agents.
  • the token policies 146 are likewise based on logic based rules and may be stored locally on the host or stored remotely on a security server and retrieved by the host TACA 142 as well. In the embodiment of the invention including a registry, entries are included to designate which security token(s) are to perform specific security transactions.
  • the local registry is comprised of a set of unique identifiers (Host App_ID) 225 for the available security application agents and a set of security type (Type) indicators 230 for the security application agents.
  • Host App_ID unique identifiers
  • Type security type indicators
  • the security type divides the security application agents into two broad categories including security services (SS) such as authentication and secure messaging and token services (TS) such as signing and secure storage of information.
  • SS security services
  • TS secure messaging and token services
  • the local registry may either be stored on the host computer system 105 or retrieved from a remote source, for example a server.
  • a set of enablement status flags (Enabled) 235 is provided which allows for administrative control over the security application agents. Activation and inactivation of the security application agents is accomplished by changing the status flag value. In this example, 1 indicates an active state while a 0 would indicate an inactive state,
  • Host ID Another set of unique identifiers (Host ID) 237 is included for the host access control rules. These entries provide a relational link to a table or equivalent data structure which includes the specific access control rule identified in the registry.
  • a set of security application agent versions 240 are retained inside the registry and checked by either the TACA 142 or middleware services layer 138 shown in FIG. 1A, to ensure that the proper version of the security application agent is operatively installed. If the required version is not present, it may be retrieved and installed as described above in FIG. 1C. Upon installation, the required entries are included in the registry.
  • the registry table is part of the modular framework which allows changes to available security application agents without disruption of existing dependencies.
  • a list 241 of available tokens is provided and updated by the TACA.
  • a counterpart set of unique token application identifiers (Token App_ID) 245 is provided for available security applications installed in one or more available security tokens.
  • the security token entries included in the registry are obtained either by directing a request to a specific security token or returned automatically by the token messaging layer 176 shown in FIG. 1A.
  • a set of unique identifiers (Token ID) 250 is likewise provided for the token access control rules. These entries are retrieved from the security policies included in a security token by the security domain control application (SDCA) 182 shown in FIG. 1A.
  • SDCA security domain control application
  • a set of enablement status flags (Enabled) 255 is provided which accomplishes the same administrative functions for the token security applications as described above for the security application agents.
  • Token Rule 257 Another set of unique identifiers (Token Rule) 257 is provided for the token selection rules. These entries may be administratively defined or determined using information received from the token interface layer 138 shown in FIG. 1A.
  • a set of unique identifiers codes (Cred_ID) 260 is provided for the credentials required by one or more active security tokens.
  • P refers to PIN
  • B refers to biometric type credentials.
  • These codes are referred to by the access control rules to specify which credential is required for a specific transaction.
  • an additional set of credential type indicators (Type) 265 is provided for each credential type.
  • a set of authentication states (State) 270 associated with each of the credentials is provided.
  • the authentication states are checked by the TACA during enforcement of a required security policy.
  • a value of 0 indicates that no successful authentication has occurred within the current session for the particular credential.
  • a value of 1 indicates that a successful authentication has occurred within the current session for the particular credential.
  • a set of enablement status flags (Enabled) 275 is provided for each credential which accomplishes the same administrative functions as described above.
  • a set of unique cryptographic key codes (Key_ID) 280 for each cryptographic key included in the active security tokens is provided. These codes are referred to by the access control rules to specify which key is to be used in a specific transaction.
  • an additional set of key type indicators (Key) 285 is provided.
  • PKI refers to a public key infrastructure key while XAUT refers to a symmetric type key.
  • a set of secure messaging session flags (State) 290 associated with each of the cryptographic keys is provided.
  • the session states are checked by the TACA during enforcement of a required security policy.
  • a value of 0 indicates that no active session has been established during the current session.
  • a value of 1 indicates that an active session is established during the current session using a particular cryptographic key.
  • a set of enablement status flags (Enabled) 295 is provided for each cryptographic key which accomplishes the same administrative functions as described above.
  • the secure messaging session state 290 and secure messaging application enablement flag 295 are automatically transferred from the SDCA to the TACA upon insertion of the security token into a hardware interface with the host, upon a first attempted access of the security token or provided automatically from the token interface layer 138 shown in FIG. 1A
  • TACA token access control application
  • FIG. 21 depicts the token policies 146 retrieved by the TACA.
  • FIG. 2C depicts the host access control rules 210 included in the host security policies.
  • the host access control rules are comprised of a unique identifier 237 for each rule and the actual host access control rules 242 .
  • Rule HAC 00 284 translates to receiving a personal identification number (PIN) being 6 characters in length.
  • PIN personal identification number
  • the abbreviations LIF, RIF refer to biometric inputs of left index finger and right index finger.
  • the host security policies can be generated from an aggregation of policies gathered from multiple sources such as a user, security application, group usage policy, security domain, the particular workstation, etc.
  • the host security policies may be stored on the security token, in the local registry, or remotely on a server or remote data base or any combination thereof.
  • FIG. 2D depicts the token access control rules 215 included in the token security policies received from one or more active security tokens.
  • the token access control rules are comprised of a unique identifier 250 for each rule and the actual token access control rules 252 .
  • Rule AC 02 301 translates to use authentication application AM 0 which requires a biometric input BIO 1 or use authentication application AM 1 which requires a credential PIN 2 and a secure messaging session using secure messaging application with cryptographic key PKI 1 .
  • FIG. 2E depicts the composite access control rules 217 generated by the TACA.
  • the composite access control rules are comprised of a unique identifier 222 for each rule and the actual composite access control rules 224 .
  • the composite access control rules 224 are generated by logically combining the token access control rules and host access control rules.
  • Combined rule CAC 02 313 was generated by the TACA from the logical combination of host access control rule HAC 00 284 with token access control rule AC 02 301 and translates to use authentication application AM 0 with biometric input BIO 1 and receive a right index finger (RIF) input and establish a secure messaging session using secure messaging application SM 2 using cryptographic key PKI 1 .
  • the composite access control may then be combined with the token selection rule TK 2 282 which requires a first use of token 1 if available, otherwise use token 2 .
  • the most restrictive rule is adopted for the composite access control rule.
  • FIG. 3 depicts an example implementation of one embodiment of the invention where a requesting application 118 requests an object 305 to be signed by a PKI cryptography application 194 included in an associated security token 75 .
  • the requesting application 118 sends a request 310 to the token access control application (TACA) 142 which causes the TACA to request 315 the token security policies 184 from the token's security domain control application (SDCA) 182 and retrieves the token policies 146 for proper token selection.
  • TACA token access control application
  • SDCA security domain control application
  • the token security policies are returned 320 to the TACA 142 and logically combined with the host security policies 152 resulting in a set of composite security policies 152 C.
  • information related to the required counterpart security application agents is returned as well for verification and if necessary installation.
  • the TACA 142 applies the composite security policies for signing the object 305 .
  • the security parameters associated with the security token may be passed as well to the TACA. The operation of one embodiment of the invention is shown by way of example.
  • a composite security policy CAC 02 313 requires a user to authenticate using token authentication application AM 1 186 by entry of a personal identification number (PIN) 330 having a pin length of 8 characters and establishment of a secure messaging session using token application SM 1 192 before allowing access to the token signing application (PKI) 194 .
  • PIN personal identification number
  • PKI token signing application
  • the TACA 142 verifies that the required enablement status flags are set to true ( 1 ) 302 , 323 , 317 for the required host application agents, (Enabled) 235 , verifies that the required enablement status flags are set to true ( 1 ) 304 , 319 , 321 for the token security applications (Enabled) 255 , verifies that the required enablement status flags are set to true ( 1 ) 306 for the credentials (Enabled) 275 and verifies that the required enablement status flags are set to true ( 1 ) 308 for the cryptographic keys (Enabled) 295 .
  • the TACA 142 also checks the flag 311 for the current authentication state (State) 270 and session state flag 314 for secure messaging (Session State) 290 . If either or both of these states meet the required composite security policy, the portion or all of the policy meeting the requirements may be bypassed to improve operational performance.
  • TACA also determines which security tokens to perform the authentication and secure messaging functions using token selection rule TK 2 282 . Based on the determination 327 , TOKEN 1 is not available, therefore TOKEN 2 will be used to perform the security transactions.
  • the authentication state 311 and secure messaging state 314 are required to fulfill the composite security access control rule CAC 02 313 shown in FIG. 2C, before processing with the security token is permitted.
  • the authentication 311 and secure messaging states 314 are received from the token's security domain control application (SDCA) 182 and stored in either volatile memory or in a temporary file.
  • SDCA token's security domain control application
  • the TACA 142 causes the PIN application 122 to execute 325 which causes a graphic user interface (GUI) to be displayed which requires a users credential input, in this case a PIN 330 .
  • GUI graphic user interface
  • the user enters his or her PIN 330 which is returned 335 to the PIN agent 156 via the TACA 142 .
  • the PIN agent 156 routes 340 the PIN 330 to its counterpart token PIN application 186 for processing. Upon successful authentication by the token PIN application 186 , the PIN agent 156 is notified of the successful authentication 340 and a state is updated 345 in the registry maintained by the SDCA 182 .
  • an unsuccessful authentication by the token PIN application 186 would return an access denied response to the PIN agent 156 which terminates the signing transaction.
  • the TACA 142 signals 350 the secure messaging agent SM 166 to establish a secure messaging session using the token secure messaging application SM 1 192 .
  • the secure messaging agent 166 causes the secure messaging application SM 1 192 to establish a secure messaging session in accordance with the combined security policy CAC 02 313 .
  • the secure messaging agent 166 upon successfully establishing a secure messaging session by the token secure messaging application SM 1 192 , the secure messaging agent 166 is notified of the successful session 355 and a state is updated 360 in a registry maintained by the SDCA 182 .
  • the secure messaging agent 166 upon receipt of the successful secure messaging establishment notification, the secure messaging agent 166 updates the secure messaging session state 290 of the registry 205 maintained by the TACA 142 . In the non-local registry version of the invention, processing continues without performing this step.
  • an unsuccessful secure messaging session establishment by the token secure messaging application 192 would return an access denied response to the secure messaging agent 166 which terminates the signing transaction.
  • the TACA 142 Upon establishment of the secure messaging session, the TACA 142 signals 365 the requesting application 118 to transfer the object 305 to be signed. The TACA 142 forwards 370 the object 305 to the PKI agent 168 for signing by the token PKI application 194 . The object 305 is sent 375 to the token PKI application 194 where it is signed and returned 385 to the PKI agent 168 .
  • the signed object 305 A is sent 390 by the PKI agent 168 to the TACA 142 where it is returned 395 to the requesting application 118 .
  • the TACA 142 receives a request 310 from a requesting application 118 .
  • the requesting application 118 sends a request 310 to the token access control application (TACA) 40 which causes the TACA to request 315 the token security policies 184 from the token's security domain control application (SDCA) 182 .
  • the token security policies are returned 320 to the TACA 142 and logically combined with the host security policies 152 resulting in the set of composite security policies 152 C.
  • information related to the required counterpart security application agents is returned as well for verification and if necessary installation. The authentication, enablement, secure messaging states and token selection are verified as before.
  • the TACA 142 extracts the applicable portions of the composite security policies for signing the object 305 and forwards 335 , 350 the applicable security policies onto the PIN agent 156 and secure messaging agent 166 which enforce their portion of the forwarded composite security policies.
  • the PIN agent 156 causes 327 the PIN application 122 to execute.
  • the entered PIN 330 is then sent directly 327 to the PIN agent 156 where processing of the PIN 330 by the token PIN application 186 and the updating of registry information, if applicable to the embodiment of the invention, is performed as previously described.
  • the successful completion of the authentication transaction causes the TACA 142 to forward the applicable security policies associated with secure messaging to the secure messaging agent 166 .
  • the secure messaging agent 166 causes the secure messaging application SM 1 192 to establish a secure messaging session in accordance with the applicable portion of the composite security policy. Establishment of a secure messaging session and updating of registry entries is performed, if applicable to the embodiment of the invention, as previously described.
  • the TACA 142 signals 370 the PKI agent 168 to process the object 305 to be signed.
  • the PKI agent 168 signals the requesting application 118 to send 367 the object 305 .
  • the object 305 is sent by the requesting application 118 to the PKI agent 168 where it is transferred 375 to the token PKI application 194 , signed and returned 385 to the PKI agent 168 .
  • the PKI agent 168 returns 392 the signed object 305 A directly to the requesting application.
  • the TACA 142 receives a request 310 from a requesting application 118 .
  • the requesting application 118 sends a request 310 to the token access control application (TACA) 142 which causes the TACA to request 315 the token security policies 184 from the token's security domain control application (SDCA) 182 and retrieves the token policies 146 for proper token selection.
  • TACA token access control application
  • SDCA token's security domain control application
  • the token security policies are returned 320 to the TACA 142 and logically combined with the host security policies 152 resulting in the set of composite security policies 152 C.
  • information related to the required counterpart security application agents is returned as well for verification and if necessary installation.
  • the authentication, enablement, secure messaging parameters and token selection are again verified as before, if applicable to the embodiment of the invention.
  • the TACA 142 forwards 326 the applicable portion of the security policy to the requesting application 118 .
  • the requesting application 118 becomes responsible for implementing the composite set of security policies.
  • the requesting application signals the PIN agent 327 and causes 328 the PIN application 122 to execute.
  • the PIN 330 is sent directly 329 to the PIN agent 156 where processing of the PIN 330 by the token PIN application 186 and the updating of registry information, if applicable to the embodiment of the invention, is performed as previously described.
  • the PIN agent 156 signals 327 the requesting application 18 of the successful completion of the authentication transaction.
  • the requesting application 118 then signals 347 the secure messaging agent 166 to establish a secure messaging session.
  • the secure messaging agent 166 causes the secure messaging application SM 1 192 to establish a secure messaging session in accordance with the applicable portion of the composite security policy. Establishment of a secure messaging session and updating of registry entries, if applicable to the embodiment of the invention, is performed as previously described.
  • the secure messaging agent 166 signals 347 the requesting application that a secure messaging session is established.
  • the requesting application 118 then signals 367 the PKI agent 168 to receive the object 305 to be signed.
  • the object 305 is sent by the requesting application 118 to the PKI agent 168 where it is transferred 375 to the token PKI application, signed and returned 385 to the PKI agent 168 .
  • the PKI agent 168 again returns 394 the signed object 305 A directly to the requesting application.
  • the sequence is initiated 400 by receiving a request to perform a security function using a security token from an application by a token access control application (TACA) 405 .
  • TACA token access control application
  • the TACA retrieves the token policy and selects the proper security token(s) to implement the transaction 410 .
  • the TACA then retrieves a token security policy 415 from the selected security token(s), reads the host security policy 420 and generates a composite set of security policies 425 from the logical combination of the token and host security policies.
  • the TACA ensure enforcement of the security policies 430 in one embodiment of the invention by accessing a registry comprising security parameters for verifying a set of enablement states in a registry 431 , verifying an authentication state in a registry 432 , verifying a secure messaging state in the registry 433 and verifying that the required security agent and/or counterpart security application are compatible 435 .
  • the discussion of compatibility verification between token security applications and host security application agents is provided under FIG. 4C below.
  • the compatibility verification process is initiated at step A 471 and if compatibility is established between the token security applications and host security application agents at step B 493 processing continues by enforcement of the combined security policies 430 . If compatibility is not established between the token security applications and host security application agents at step C 487 , processing ends 480 .
  • the security policy is enforced without verifying security parameters (non-local registry embodiment) and continues by receiving a specific credential, if required 450 ) causing the execution of one or more appropriate security agents 455 , sending the received credential to the appropriate security agent, if required 460 , sending the received credential to the proper token application 465 , establishing a secure messaging session, if required 470 , performing a security function 475 and ending processing 480 after performing the security function.
  • the sequence is initiated 406 by receiving a request to perform a security function using a security token from an application by a token access control application (TACA) 412 .
  • TACA token access control application
  • the TACA retrieves a token selection policy 418 and selects the security tokens to perform the security transactions.
  • the TACA retrieves a token security policy 418 from the selected security token(s), reads an associated host security policy 424 and generates a composite security policy 432 from the logical combination of the token and host security policies.
  • the TACA accesses a registry comprising security parameters for verifying a set of enablement states in the registry 434 , verifying an authentication state in the registry 436 , verifying a secure messaging state in the registry 438 and verifying that the required security agent and/or counterpart security application are compatible 442 .
  • the compatibility verification process is initiated at step A 471 and if compatibility is established between the token security applications and host security application agents at step B 493 processing continues by enforcement of the combined security policies 432 . If compatibility is not established between the token security applications and host security application agents at step C 487 , processing ends 496 . Otherwise 448 , processing continues by enforcement of the combined security policies 432 .
  • the security policy is enforced without verifying security parameters (non-local registry embodiment) and continues by executing the appropriate security application agents 462 , sending the combined set of security policies to the appropriate security application agents 468 , ensuring enforcement of the composite set of security policies by the appropriate security agents 474 , receiving a specific credential, if required 480 , sending the received credential to the proper token application, if required 484 , establishing a secure messaging session, if required 488 , performing a security function 492 and ending processing 496 after performing the security function.
  • the sequence is initiated 403 by receiving a request to perform a security function using a security token from an application by a token access control application (TACA) 407 .
  • TACA token access control application
  • the TACA retrieves token policies and selects the proper security token(s) to perform the transaction 409 .
  • the TACA then retrieves a token security policy 409 from the selected security token(s), retrieves the host security policy 413 and generates a composite security policy 419 from the logical combination of the token and host security policies.
  • the TACA accesses a registry comprising security parameters for verifying a set of enablement states in the registry 421 , verifying an authentication state in the registry 423 , verifying a secure messaging state in the registry 427 and verifying that the required security agent and/or counterpart security application are compatible 431
  • the compatibility verification process is initiated at step A 471 and if compatibility is established between the token security applications and host security application agents at step B 493 processing continues by enforcement of the combined security policies 430 .
  • the security policy is enforced without verifying security parameters and continues by executing the appropriate security agents 443 , sending the combined security policy to the requesting application 447 , ensuring enforcement of the security policy by the appropriate security agents 449 , receiving a specific credential, if required 451 , sending the received credential to the proper token application, if required 453 , establishing a secure messaging session, if required 457 , performing a security function 459 and ending processing 461 after performing the security function.
  • the compatibility information ensures that the proper version of security application agent is installed on the host computer system in order to properly operate with their counterpart token security applications.
  • the process is initiated at step A 471 by retrieving the compatibility information from the security token 473 .
  • the information may be retrieved from a registry maintained by the security domain control application installed inside the security token or provided directly by each of the token security applications.
  • the retrieved compatibility information is then used to verify that the installed host security application agents are compatible with the installed token security applications 475 . If the security application agents are compatible with token security applications 477 , this portion of the processing ends and returns at step B 493 .
  • one or more of the security application agents are not compatible with one or more of the token security applications 477 , one or more compatible security application agents are retrieved 479 .
  • the security application agent(s) may be retrieved from either a local or remote storage location.
  • a digital signature verification is then performed 481 .
  • step C 487 If the digital signature(s) are not verified 483 , the installation process is aborted 485 and processing terminated at step C 487 . If the digital signature(s) are verified 483 , the retrieved application(s) are installed on the host computer system 489 . The newly installed security application agent(s) are then registered with either the host operating system or token access control application by entry of parameters in a registry 491 . Once the appropriate registry has been updated with the parameters, processing is completed at step B 493 .

Abstract

A security framework for a host computer system which allows a host to control access to a compliant security token by ensuring enforcement of established security policies administered by a middleware application. Processing between the host computer system and the security token is performed using one or more modular security application agents. The modular security application agents are counterpart applications to security applications installed in the security token and may be retrieved and installed upon to ensure compatibility between counterpart token and host security applications. The security policies are a composite of host security policies and token security policies which are logically combined by the middleware application at the beginning of a session.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The present application is related to co-pending U.S. patent application Ser. No. 10/321,624 entitled, “Uniform Framework for Security Tokens,” filed on Dec. 18, 2002, by Eric Le Saint & al. Applicant hereby incorporates by reference the above-mentioned co-pending application.[0001]
  • FEDERALLY SPONSORED RESEARCH AND DEVELOPMENT
  • Not Applicable. [0002]
  • REFERENCE TO A MICROFICHE APPENDIX
  • Not Applicable. [0003]
  • FIELD OF INVENTION
  • The present invention relates generally to a data processing system, method and computer program product and more specifically to a uniform security application framework for a host computer system in communication with a security token. [0004]
  • BACKGROUND
  • In the relevant art, host applications for supporting authentication and secure messaging functions involving the use of security tokens lack a uniform programming framework which has largely resulted in development of proprietary applications. The proprietary nature of these applications limits the ability to provide a uniform approach in the development and implementation of security applications. Vendors prefer to provide end-to-end solutions which generally work well with there own applications but are difficult to configure and maintain when combined with software and/or firmware provided by others. [0005]
  • Efforts to address interoperability of host security applications have focused primarily on resolving specific compatibility issues rather than providing a uniform programming framework in which to develop security applications. Little effort has been made to provide a standardized framework for a host computer system which allows applications developed by different providers to be installed without encountering interoperability issues. To date, the majority of attention has been focused on developing customized security token applications rather than on the host applications intended to interface with the security token applications. [0006]
  • For example, one vendor may excel at providing user authentication mechanisms using dynamic passwords while another may excel at providing certain types of biometric authentication mechanisms such as fingerprint reading, while another may excel at providing biometric iris scanning mechanisms. [0007]
  • However, in the relevant art it is generally difficult to mix vendor products due to compatibility issues and the non-modular nature of security applications deployed. While efforts have been made to standardize certain portions of the host security applications, the majority of host security applications available today intend to provide the entire solution rather than allowing a potential customer to pick and choose the most cost effective application(s) to meet a particular security requirement. The vendor's host security applications are specifically written to interface with the vendor's security token applications. Compatibility with other vendor products being of secondary importance. [0008]
  • Therefore, what is needed is a uniform host applications framework for deployment on a host computer system which allows interoperability of host security applications, allows modularization of host security applications and interfaces with security tokens having a compatible internal framework. [0009]
  • SUMMARY
  • This invention addresses the limitations described above and provides a uniform applications framework for host computers which supports modular host security application installations and allows independent operations of applications installed in the security token. In particular, proprietary biometric applications such as match on card technologies are decoupled from other host middleware applications and from the applications installed in the security token. [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), Trusted Computer Platform Alliance chip (TCPA), and like devices. Temporary virtual security tokens are included as well. [0011]
  • The term “credential” as defined herein refers to critical security parameters (CSP) such as authentication data, passwords, PINs, biometric templates, secret and private cryptographic keys and challenge/response messages or combinations thereof. [0012]
  • The term “parameter” as defined herein refers to a status flag, text, a number, arguments or an argument name assigned to a value that is passed from one routine to another or used as a means of customizing program operation which is broader than its normal context. [0013]
  • The invention comprises a system which provides a uniform security applications framework for a host computer system which cooperates with one or more compliant security tokens. The compliant security token(s) is in processing communications with the host computer system and includes a compatible uniform security framework which interfaces with the host security framework, a set of token security policies and one or more token security applications. [0014]
  • The host computer system includes a token access control application, token selection policies and several security application agents which are counterparts to the token security application(s). A set of host security policies associated with each of the security application agents is retrievably coupled to the token access control application. [0015]
  • The token access control application allows the retrieval of at least a portion of the token security policies from which a composite set of security policies is generated by logically combining the host security policies, token selection policies and the token security policies. [0016]
  • If the token access control application determines that a required security application agent and/or token security application is not present, the required applications may be downloaded and operatively installed from either a local or a remote storage location as individual modules without disruption of existing dependencies. [0017]
  • In one embodiment of the invention, ensuring enforcement of the composite set of security policies is performed by the token access control application. In this embodiment of the invention, the token access control application further includes the ability to receive a credential, cause at least one of the security application agents to execute in response to an access request and the ability to send a credential to the appropriate security application agent. [0018]
  • In a second embodiment of the inventions ensuring enforcement of the composite security policies is performed by the applicable security application agents which receive the composite security policy from the token access control application. In this embodiment of the invention, a hierarchy exists between security application agents which causes the required security application agents to execute sequentially in accordance with the applicable portion of the composite set of security policies. In this embodiment of the invention, credentials are sent directly to the appropriate security application agent. [0019]
  • In yet another embodiment of the invention, the responsibility for ensuring enforcement of the composite set of security policies is performed by a calling application. In this embodiment of the invention, the token access control application generates the composite security policies and forwards them to a calling application. The calling application then sequentially causes the required security application agents to execute sequentially in accordance with the applicable portion of the composite set of security policies. In this embodiment of the invention, credentials are forwarded to the appropriate security application agent by the calling application. [0020]
  • In all embodiments of the invention, the security application agents include the ability to perform a security function with one or more counterpart token security applications in accordance with the composite set of security policies and return objects in which a security function is performed by a token application. The security application agents may exist as separate applications, dynamically linked libraries associated with the token access control application or any combination thereof. [0021]
  • In another embodiment of the invention, the composite set of security policies includes token access control rules, host access control rules, token selection rules and composite access control rules but lacks a registry. In this embodiment of the invention, an operating system installed on the host administers the security application agents. [0022]
  • In yet another embodiment of the invention, a local registry is included which is administered by the token access control application. The local registry is comprised of enablement flags and operational states related to authentication, secure messaging and application enablement. Each available application requires a corresponding entry in the registry including registered token security applications and registered security agent applications. [0023]
  • The token security applications includes a token security domain control application, a token services application, a token administrative services application to and a token security services application. The token security services application includes the ability to perform authentication and secure messaging. The token services application includes the ability to perform cryptography, return objects in which a security function was performed to a security agent application. The object includes a credential, a digital certificate, data to undergo a cryptographic function or data to be stored in said security token. [0024]
  • Processing by the uniform security framework involves the following steps: [0025]
  • a. receiving a token security function request from a requesting application, [0026]
  • b. retrieving token selection policies, [0027]
  • c. retrieving a set of token security policies, [0028]
  • d. retrieving a set of host security policies, [0029]
  • e. combining the token security policies, the host security policies and the token selection policies into a composite security policy, [0030]
  • f. ensuring enforcement of said composite security policy on the security function request, [0031]
  • g. receiving a credential if required by the composite security policy, [0032]
  • h. sending the credential to an appropriate security application agent if required by the composite security policy, [0033]
  • i. sending the credential to an appropriate token security application if required by the composite security policy, and [0034]
  • j. performing a security function in accordance with the composite security policy. [0035]
  • In an alternate embodiment of the invention which includes a registry, step d. includes the steps of; [0036]
  • i.) verifying a plurality of enablement states in a registry, [0037]
  • ii.) verifying at least one authentication state in the registry, [0038]
  • iii.) verifying a secure messaging state in the registry, [0039]
  • iv) verifying that at least one counterpart pair of a token security application and host security application agent are operatively installed, and retrieving and operatively installing a missing component of the counterpart pair from either a local or a remote storage location. [0040]
  • The invention also provides for retrieval of compatibility information related to one or more counterpart security application agents from a functionally connected security token by at least one security application installed on a host computer system wherein the retrievable capability information relates to compatibility between the one or more counterpart security application agents and the one or more token security applications. The at least one security application includes functionality for; [0041]
  • retrieving the compatibility information related to the one or more counterpart security application agents; [0042]
  • verifying that at least one compatible counterpart security application agent is operatively installed and if not, retrieving and operatively installing at least one compatible counterpart security application agent. [0043]
  • The at least one security application includes either a security application installed in a middleware services layer or is a token access control application retrieved from either a local or remote storage location. [0044]
  • Installation of the retrieved at least one compatible counterpart security application agent is accomplished by entering one or more parameters associated with the at least one compatible counterpart security application agent in a registry. [0045]
  • The at least one compatible counterpart security application agent is a nodular software application which can be added, removed or replaced without disruption of any existing dependencies by changing the one or more parameters in entered in the registry. [0046]
  • The retrieval of compatibility information related to one or more counterpart security application agents from a functionally connected security token by at least one security application installed on a host computer system is accomplished by performing the steps of: [0047]
  • a. retrieving compatibility information related to one or more counterpart security application agents from a security token, [0048]
  • b. verifying that at least one compatible counterpart security application agent is operatively installed on a host computer system, and if not, [0049]
  • c. retrieving at least one compatible counterpart security application agent, [0050]
  • d. performing a signature verification process and allowing installation if successful, or aborting the installation if unsuccessful, [0051]
  • e. operatively installing said at least one compatible counterpart security application agent on said host computer system, and [0052]
  • f. entering one or parameters associated with said at least one compatible counterpart security application agent into a registry. [0053]
  • The programs and data may be placed onto transportable medium such as a CD ROM, floppy disk, data tape, portable hard disk, flash memory device or DVD for installing on a host computer system.[0054]
  • BRIEF DESCRIPTION OF DRAWINGS
  • 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. [0055]
  • FIG. 1—is a generalized block diagram of a host computer system and a electromagnetically connected security token. [0056]
  • FIG. 1A—is a detailed block diagram invention illustrating the relationship and arrange of various applications employed in the invention. [0057]
  • FIG. 1B—is a detailed block diagram illustrating a plurality of available security tokens for implementing the invention. [0058]
  • FIG. 1C—is a detailed block diagram illustrating retrieval and installation of a security application agent or a token security application. [0059]
  • FIG. 2—is a detailed block diagram illustrating the functional relationship between a token access control application (TACA) and associated security and token policies. [0060]
  • FIG. 2A—is a detailed block diagram illustrating an embodiment of the invention which uses a registry having an associated with the security policies. [0061]
  • FIG. 2B—is a detailed block diagram illustrating token selection policies and rules. [0062]
  • FIG. 2C—is a detailed block diagram illustrating host access control policies and rules. [0063]
  • FIG. 2D—is a detailed block diagram illustrating token access control policies and rules. [0064]
  • FIG. 2E—is a detailed block diagram illustrating a composite set of access control rules derived from the logical combination of host and token access control rules. [0065]
  • FIG. 3—is a detailed block diagram illustrating a first embodiment of the invention. [0066]
  • FIG. 3A—is a detailed block diagram illustrating a second embodiment of the invention. [0067]
  • FIG. 3B—is a detailed block diagram illustrating a third embodiment of the invention, [0068]
  • FIG. 4—is a flow diagram illustrating the major steps necessary to implement the first embodiment of the invention. [0069]
  • FIG. 4A—is a flow diagram illustrating the major steps necessary to implement the second embodiment of the invention. [0070]
  • FIG. 4B—is a flow diagram illustrating the major steps necessary to implement the third embodiment of the invention. [0071]
  • FIG. 4C—is a flow diagram illustrating the major steps necessary to retrieve compatibility information from the security token to the host computer system.[0072]
  • DETAILED DESCRIPTION
  • This present invention provides a uniform host application framework which separates authentication and secure messaging functions into modular security applications, allows interoperability of host security applications and interfaces with security tokens having a compatible internal framework. The invention further allows selection of individual security tokens to perform selected security tasks administered by token selection policies. [0073]
  • 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. The applications are envisioned to be programmed using high level programming languages such as Java™, Visual Basic™, C++ or C. [0074]
  • Referring to FIG. 1, a typical [0075] host computer system 105 is shown which includes a processor 5, a main memory 10, a display 20 electromagnetically coupled to a display interface 15, a secondary memory subsystem 25 electromagnetically coupled to a hard disk drive 30, a removable storage drive 35 electromagnetically coupled to a removable storage unit 40 and an auxiliary removable storage interface 45 electromagnetically coupled to an auxiliary removable storage unit 50.
  • A [0076] communications interface 55 subsystem is coupled to a network interface 60 and a network 65, a security token interface 70 and a security token 75, a user input interface 80 including a mouse and a keyboard 85, a biometric scanner interface 90 and a biometric scanner 95.
  • The [0077] processor 5, main memory 10, display interface 15, secondary memory subsystem 25 and communications interface system 55 are electromagnetically coupled to a communications infrastructure 100. The host computer system 105 includes an operating system, a token access control application (TACA) and associated middleware security agent application agents, one or more applications requiring security services from a security token 75, cryptography software capable of performing symmetric and asymmetric cryptographic functions, secure messaging software and device interface software. Data necessary to support the security functions should be assumed to be present as well.
  • The [0078] security token 75 includes a wireless and/or electrical connection means compatible with the security token interface 70, a processor, volatile and non-volatile memory electromagnetically coupled to the processor, a runtime operating environment, cryptography extensions incorporated into the operating system and capable of performing symmetric and asymmetric cryptographic functions compatible with the host cryptography software, a security domain access control application (SDCA) and associated security applications, one or more credential protected applications functionally coupled to the security executive application and a public key infrastructure (PKI) key pair functionally coupled to the security executive application. Data necessary to support the security functions should be assumed to be present as well. The non-volatile memory has operatively stored therein one or more reference credentials which are verified by the security applications to allow access to the one or more credential protected applications.
  • FIG. 1A depicts the invention and associated host applications and resources. A plurality of security applications for example, a biometric based [0079] application 114, a signing based application 118 and an authentication based application which uses a personal identification number (PIN) 122. The security applications are coupled to an applications programming interface (API) layer 128. The API layer includes a set of routines used by the application program to direct the performance of procedures by the host's operating system. The API layer 128 is shown in dotted lines to indicate that no substantial changes are made to the functionality of this layer. The API layer 128 rides above a cryptographic services layer 134.
  • The [0080] cryptographic services layer 134 allows access to host cryptographic resources and acts as a gateway to a middleware services layer 138. The middleware services layer 138 routes requests for token services sent by the host applications 114, 118, 122 to a token access control application (TACA) 142. The middleware services layer 138 is intended to provide a consistent and modular application interface between the security applications 114, 118, 122 and the token access control application (TACA) 142 and in an alternate embodiment of the invention, maintains security application agent module consistency with their counterpart security applications 186, 188, 192, 194, 198 installed inside the security token 75.
  • The [0081] TACA 142 is associated with a set of token security policies 146 that controls which security token will perform a specific type of security transaction when a plurality of security tokens are available to perform the transaction.
  • The [0082] TACA 142 is also associated with a set of host security policies 152 which controls a security function of one or more security application agents 156, 162, 166, 168, 172 and in one embodiment of the invention, maintains security application agent module consistency with their counterpart security applications 186, 198, 192, 194, 198 installed inside the security token 75.
  • The [0083] security application agents 156, 162, 166, 168, 172 may exist as separate applications, dynamically linked libraries associated with the token access control application or any combination thereof. Both the security application agents 156, 162, 166, 168, 172 and token security applications 186, 188, 192; 194, 198 are modular in nature and may be retrieved locally if available on a local hard drive or downloaded from a centralized repository and dynamically installed without disruption of existing dependencies, which is a central concept of the uniform modular framework. The uniform modular framework being comprised of the API layer 128, cryptographic services layer 134, middleware services layer 138, token access control application 142, token messaging layer 176, token runtime operating environment 178 and security domain control application 182.
  • In one embodiment of the invention, the TACA ensures enforcement of the security policies. In another embodiment of the invention, the appropriate [0084] security application agents 156, 162, 166 receives the security policies from the TACA and self enforces the security policies. In a third embodiment of the invention, the TACA sends the security policies to the requesting application which ensures enforcement of the security policies.
  • The [0085] security application agents 156, 162, 166, 168, 172 are designed to perform a security function in conjunction with their counterpart security applications 182, 186, 188, 192, 194, 198 installed in the security token 75. The security application agents functionally decouples security applications installed on the host from those applications installed in the security token, allowing greater interoperability between host applications and security token applications and is part of the nodular plug-in architecture.
  • This allows the security application agents and their counterpart token security applications to act in concert with a middleware security application but functionally independent from the middleware security application. [0086]
  • A typical arrangement of security application agents includes a [0087] PIN agent 156, a biometric agent 162, a secure messaging agent 166 and a public key cryptography agent 168. Additional agents may be installed to perform other functions as is shown by the other agent 172. In another embodiment of the invention, administrative control of the security application agents 156, 162, 166, 168, 172 remains with the operating system installed on the host. A token messaging layer 176 provides communications protocol conversion into ISO 7816 compliant application protocol data unit (APDU) format. Addressing of the counterpart token 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,” is included as a reference to this specification.
  • A [0088] security token 75 includes a security domain control application (SDCA) 182 coupled to a runtime operating environment 178 and a set of token security policies 184. The token security policies control a security function associated with a PIN application 186, a biometric application 188, a secure messaging application 192, a PKI cryptography application 194 and an additional application 198. The token security applications 186, 188, 192, 194, 198 each includes information 185, 187, 191, 193, 197 which is used by the middleware services layer 138 to determine if the proper counterpart security application agent(s) 156, 162, 166, 168, 172 is installed.
  • This information is transferred along with the token security policies and is used by the [0089] middleware services layer 138 for security application agent version control and security application agent module loading. The operation of the token security applications and SDCA is described in co-pending U.S. application Ser. No. 10/321,624 to Eric Le Saint & al., entitled “Uniform Framework for Security Tokens” and filed on Dec. 18, 2002
  • Referring to FIG. 1B, an embodiment of the invention is shown where several security tokens are available to perform one or more security transactions. The security tokens include a traditional [0090] smart card 75A, a Trusted Computer Platform Alliance (TPCA) chip 75B, a local virtual security 75C, a remote virtual security 75D, a remote TPCA chip 75E or a hardware security module (HSM) 75F. The token access control application (TACA) 142 selects the appropriate security token in which to process a security transaction based on criteria included in the Token Policies 146. One or more of the security tokens may be employed to complete a security transactions.
  • For instance authentication may be performed using a local virtual security token [0091] 75C installed in the host 105 and a remote virtual security token 75D installed in a remote server 195 connected by a network 65 may be used to establish secure messaging.
  • Referring to FIG. 1C, if upon generating a composite security policy, the [0092] TACA 142 or middleware services layer 138 determines that a required security application agent either not present or incompatible with a token security application, the application agent 127 a maybe securely retrieved from a local storage location 125 a or the application 127 b may be downloaded a remote storage location 125 b and installed in the applicable location(s). Upon installation, the new application is registered in either a registry table maintained by the host operating system or a separate registry table maintained by the TACA 142 described below. An optional code authentication may be performed by comparing digital signatures before installation and registration is performed.
  • In FIG. 2, a relationship between the [0093] TACA 142, host security policies 152 and token security policies 146 is provided. In one embodiment of the invention, the composite security policies 152C include a set of logic based host access control rules 210, a set of logic based token access control rules 215 and a composite set of access control rules 217 derived from the logical combination of the host access control rules 210 and the token access control rules 215. The composite security policies 152C may be stored locally on the host or stored remotely on a security server and retrieved by the host TACA 142. In an alternate embodiment of the invention, a local registry 205 (shown in dashed lines) is included.
  • The local registry is administered by the [0094] TACA 142 and provides additional administrative controls over the security application agents. The token policies 146 are likewise based on logic based rules and may be stored locally on the host or stored remotely on a security server and retrieved by the host TACA 142 as well. In the embodiment of the invention including a registry, entries are included to designate which security token(s) are to perform specific security transactions.
  • Referring to FIG. 2A, the embodiment including a local registry administered by the TACA is depicted. The local registry is comprised of a set of unique identifiers (Host App_ID) [0095] 225 for the available security application agents and a set of security type (Type) indicators 230 for the security application agents.
  • The security type divides the security application agents into two broad categories including security services (SS) such as authentication and secure messaging and token services (TS) such as signing and secure storage of information. The local registry may either be stored on the [0096] host computer system 105 or retrieved from a remote source, for example a server.
  • A set of enablement status flags (Enabled) [0097] 235 is provided which allows for administrative control over the security application agents. Activation and inactivation of the security application agents is accomplished by changing the status flag value. In this example, 1 indicates an active state while a 0 would indicate an inactive state,
  • Another set of unique identifiers (Host ID) [0098] 237 is included for the host access control rules. These entries provide a relational link to a table or equivalent data structure which includes the specific access control rule identified in the registry. A set of security application agent versions 240 are retained inside the registry and checked by either the TACA 142 or middleware services layer 138 shown in FIG. 1A, to ensure that the proper version of the security application agent is operatively installed. If the required version is not present, it may be retrieved and installed as described above in FIG. 1C. Upon installation, the required entries are included in the registry. The registry table is part of the modular framework which allows changes to available security application agents without disruption of existing dependencies.
  • A [0099] list 241 of available tokens is provided and updated by the TACA. A counterpart set of unique token application identifiers (Token App_ID) 245 is provided for available security applications installed in one or more available security tokens. The security token entries included in the registry are obtained either by directing a request to a specific security token or returned automatically by the token messaging layer 176 shown in FIG. 1A.
  • A set of unique identifiers (Token ID) [0100] 250 is likewise provided for the token access control rules. These entries are retrieved from the security policies included in a security token by the security domain control application (SDCA) 182 shown in FIG. 1A. A set of enablement status flags (Enabled) 255 is provided which accomplishes the same administrative functions for the token security applications as described above for the security application agents.
  • Another set of unique identifiers (Token Rule) [0101] 257 is provided for the token selection rules. These entries may be administratively defined or determined using information received from the token interface layer 138 shown in FIG. 1A.
  • A set of unique identifiers codes (Cred_ID) [0102] 260 is provided for the credentials required by one or more active security tokens. In this example, P refers to PIN, while B refers to biometric type credentials. These codes are referred to by the access control rules to specify which credential is required for a specific transaction. To simplify administration, an additional set of credential type indicators (Type) 265 is provided for each credential type.
  • A set of authentication states (State) [0103] 270 associated with each of the credentials is provided. The authentication states are checked by the TACA during enforcement of a required security policy. In this example, a value of 0 indicates that no successful authentication has occurred within the current session for the particular credential.
  • A value of 1 indicates that a successful authentication has occurred within the current session for the particular credential. A set of enablement status flags (Enabled) [0104] 275 is provided for each credential which accomplishes the same administrative functions as described above.
  • A set of unique cryptographic key codes (Key_ID) [0105] 280 for each cryptographic key included in the active security tokens is provided. These codes are referred to by the access control rules to specify which key is to be used in a specific transaction. To simplify administration, an additional set of key type indicators (Key) 285 is provided. In this example, PKI refers to a public key infrastructure key while XAUT refers to a symmetric type key.
  • A set of secure messaging session flags (State) [0106] 290 associated with each of the cryptographic keys is provided. The session states are checked by the TACA during enforcement of a required security policy. In this example, a value of 0 indicates that no active session has been established during the current session. A value of 1 indicates that an active session is established during the current session using a particular cryptographic key. A set of enablement status flags (Enabled) 295 is provided for each cryptographic key which accomplishes the same administrative functions as described above.
  • The secure [0107] messaging session state 290 and secure messaging application enablement flag 295 are automatically transferred from the SDCA to the TACA upon insertion of the security token into a hardware interface with the host, upon a first attempted access of the security token or provided automatically from the token interface layer 138 shown in FIG. 1A Once the necessary information is retrieved, the token access control application (TACA) verities the state and enablement status locally rather than retrieving the security parameters from the associated security token.
  • This limits the amount of data sent to and from the security token(s) thus improving performance. Overall, system security remains unaffected as a change in a security state in the local registry does not necessarily reflect the controlling security state of the security token. [0108]
  • FIG. 21 depicts the [0109] token policies 146 retrieved by the TACA. The token selection rules are comprised of a unique identifier (ID) 257 for each rule and the actual rules (Rule) 259 themselves. All access control rules as well as the token selection rules utilize standard Boolean, logic operators and logic statements including AND, OR, NOT, ELSE, LF, XOR. In addition, standard arithmetic statements including <, >, < >, =, +, − may be used as well. Rule TK2 282 translates simply to use token1 if available, otherwise use token2. As an example, this arrangement allows the first use of a virtual token which is considerably faster than a hardware based token.
  • FIG. 2C depicts the host [0110] access control rules 210 included in the host security policies. The host access control rules are comprised of a unique identifier 237 for each rule and the actual host access control rules 242. Rule HAC00 284 translates to receiving a personal identification number (PIN) being 6 characters in length. The abbreviations LIF, RIF refer to biometric inputs of left index finger and right index finger. The host security policies can be generated from an aggregation of policies gathered from multiple sources such as a user, security application, group usage policy, security domain, the particular workstation, etc. The host security policies may be stored on the security token, in the local registry, or remotely on a server or remote data base or any combination thereof.
  • FIG. 2D depicts the token [0111] access control rules 215 included in the token security policies received from one or more active security tokens. The token access control rules are comprised of a unique identifier 250 for each rule and the actual token access control rules 252.
  • [0112] Rule AC02 301 translates to use authentication application AM0 which requires a biometric input BIO1 or use authentication application AM1 which requires a credential PIN2 and a secure messaging session using secure messaging application with cryptographic key PKI1.
  • FIG. 2E depicts the composite [0113] access control rules 217 generated by the TACA. The composite access control rules are comprised of a unique identifier 222 for each rule and the actual composite access control rules 224. The composite access control rules 224 are generated by logically combining the token access control rules and host access control rules.
  • [0114] Combined rule CAC02 313 was generated by the TACA from the logical combination of host access control rule HAC00 284 with token access control rule AC02 301 and translates to use authentication application AM0 with biometric input BIO1 and receive a right index finger (RIF) input and establish a secure messaging session using secure messaging application SM2 using cryptographic key PKI1. As an alternative, use authentication application AM1 and receive a PIN having a length of eight characters and establish a secure messaging session using secure messaging application SM1 using cryptographic key PKI1.
  • The composite access control may then be combined with the token [0115] selection rule TK2 282 which requires a first use of token1 if available, otherwise use token2. In all cases where token selection rules, token access control rules and host access control rules address a specific security requirement, the most restrictive rule is adopted for the composite access control rule.
  • FIG. 3, depicts an example implementation of one embodiment of the invention where a requesting [0116] application 118 requests an object 305 to be signed by a PKI cryptography application 194 included in an associated security token 75. The requesting application 118 sends a request 310 to the token access control application (TACA) 142 which causes the TACA to request 315 the token security policies 184 from the token's security domain control application (SDCA) 182 and retrieves the token policies 146 for proper token selection.
  • The token security policies are returned [0117] 320 to the TACA 142 and logically combined with the host security policies 152 resulting in a set of composite security policies 152C. In an alternate embodiment of the invention, information related to the required counterpart security application agents is returned as well for verification and if necessary installation. The TACA 142 applies the composite security policies for signing the object 305. Depending on the embodiment of the invention (register embodiment), the security parameters associated with the security token may be passed as well to the TACA. The operation of one embodiment of the invention is shown by way of example.
  • Referring back to FIG. 2E, a composite [0118] security policy CAC02 313 requires a user to authenticate using token authentication application AM1 186 by entry of a personal identification number (PIN) 330 having a pin length of 8 characters and establishment of a secure messaging session using token application SM1 192 before allowing access to the token signing application (PKI) 194.
  • The applicable portion of the composite security policy implemented is CAC[0119] 02 (AM1[PIN2] AND PIN_LN=8) AND SM1[PKI1] and token selection rule TK2 282 requires a first use of TOKEN1 if available, otherwise use TOKEN2.
  • Referring back to FIG. 2A, the requirements of the composite [0120] security policy CAC02 313, token selection rule TK2 282 and the required local security states must be verified by the TACA 142 before a security function is allowed using a designated security token. The TACA 142 verifies that the required enablement status flags are set to true (1) 302, 323, 317 for the required host application agents, (Enabled) 235, verifies that the required enablement status flags are set to true (1) 304, 319, 321 for the token security applications (Enabled) 255, verifies that the required enablement status flags are set to true (1) 306 for the credentials (Enabled) 275 and verifies that the required enablement status flags are set to true (1) 308 for the cryptographic keys (Enabled) 295.
  • If any of the required enablement flags are not set to the proper value an error is returned and processing ends. The [0121] TACA 142 also checks the flag 311 for the current authentication state (State) 270 and session state flag 314 for secure messaging (Session State) 290. If either or both of these states meet the required composite security policy, the portion or all of the policy meeting the requirements may be bypassed to improve operational performance.
  • In addition, TACA also determines which security tokens to perform the authentication and secure messaging functions using token [0122] selection rule TK2 282. Based on the determination 327, TOKEN 1 is not available, therefore TOKEN 2 will be used to perform the security transactions.
  • In the local registry, all of the required enablement states are shown with the [0123] proper values 302, 304, 306, 308, 317, 319, 321, 323. However, the authentication state 311 and secure messaging state 314 are required to fulfill the composite security access control rule CAC02 313 shown in FIG. 2C, before processing with the security token is permitted. In the non-local registry embodiment of the invention, the authentication 311 and secure messaging states 314 are received from the token's security domain control application (SDCA) 182 and stored in either volatile memory or in a temporary file.
  • In either embodiment of the invention, the [0124] TACA 142 causes the PIN application 122 to execute 325 which causes a graphic user interface (GUI) to be displayed which requires a users credential input, in this case a PIN 330. The user enters his or her PIN 330 which is returned 335 to the PIN agent 156 via the TACA 142.
  • The [0125] PIN agent 156 routes 340 the PIN 330 to its counterpart token PIN application 186 for processing. Upon successful authentication by the token PIN application 186, the PIN agent 156 is notified of the successful authentication 340 and a state is updated 345 in the registry maintained by the SDCA 182.
  • In the local registry embodiment of the invention an analogous process occurs where upon receipt of the successful authentication notification, the [0126] PIN agent 156 updates the authentication state 270 of the registry 205 maintained by the TACA 142. In the non-local registry embodiment of the invention, processing continues without this step.
  • In either embodiment of the invention, an unsuccessful authentication by the [0127] token PIN application 186 would return an access denied response to the PIN agent 156 which terminates the signing transaction.
  • Upon successful completion of the authentication, the [0128] TACA 142 signals 350 the secure messaging agent SM 166 to establish a secure messaging session using the token secure messaging application SM1 192. The secure messaging agent 166 causes the secure messaging application SM1 192 to establish a secure messaging session in accordance with the combined security policy CAC02 313.
  • Analogously, upon successfully establishing a secure messaging session by the token secure [0129] messaging application SM1 192, the secure messaging agent 166 is notified of the successful session 355 and a state is updated 360 in a registry maintained by the SDCA 182. In the registry embodiment of the invention, upon receipt of the successful secure messaging establishment notification, the secure messaging agent 166 updates the secure messaging session state 290 of the registry 205 maintained by the TACA 142. In the non-local registry version of the invention, processing continues without performing this step.
  • In either embodiment of the invention, an unsuccessful secure messaging session establishment by the token [0130] secure messaging application 192 would return an access denied response to the secure messaging agent 166 which terminates the signing transaction.
  • Upon establishment of the secure messaging session, the [0131] TACA 142 signals 365 the requesting application 118 to transfer the object 305 to be signed. The TACA 142 forwards 370 the object 305 to the PKI agent 168 for signing by the token PKI application 194. The object 305 is sent 375 to the token PKI application 194 where it is signed and returned 385 to the PKI agent 168.
  • The signed [0132] object 305A is sent 390 by the PKI agent 168 to the TACA 142 where it is returned 395 to the requesting application 118.
  • Referring to FIG. 3A, another embodiment of the invention is illustrated and continues with the previous example. In this embodiment of the invention, the [0133] TACA 142 receives a request 310 from a requesting application 118. As before, the requesting application 118 sends a request 310 to the token access control application (TACA) 40 which causes the TACA to request 315 the token security policies 184 from the token's security domain control application (SDCA) 182. The token security policies are returned 320 to the TACA 142 and logically combined with the host security policies 152 resulting in the set of composite security policies 152C. In an alternate embodiment of the invention, information related to the required counterpart security application agents is returned as well for verification and if necessary installation. The authentication, enablement, secure messaging states and token selection are verified as before.
  • However, in this embodiment of the invention, the [0134] TACA 142 extracts the applicable portions of the composite security policies for signing the object 305 and forwards 335, 350 the applicable security policies onto the PIN agent 156 and secure messaging agent 166 which enforce their portion of the forwarded composite security policies. In this embodiment of the invention, the PIN agent 156 causes 327 the PIN application 122 to execute.
  • The entered [0135] PIN 330 is then sent directly 327 to the PIN agent 156 where processing of the PIN 330 by the token PIN application 186 and the updating of registry information, if applicable to the embodiment of the invention, is performed as previously described.
  • The successful completion of the authentication transaction causes the [0136] TACA 142 to forward the applicable security policies associated with secure messaging to the secure messaging agent 166. The secure messaging agent 166 causes the secure messaging application SM1 192 to establish a secure messaging session in accordance with the applicable portion of the composite security policy. Establishment of a secure messaging session and updating of registry entries is performed, if applicable to the embodiment of the invention, as previously described.
  • Once the required security policies have been achieved, the [0137] TACA 142 signals 370 the PKI agent 168 to process the object 305 to be signed. The PKI agent 168 signals the requesting application 118 to send 367 the object 305. The object 305 is sent by the requesting application 118 to the PKI agent 168 where it is transferred 375 to the token PKI application 194, signed and returned 385 to the PKI agent 168. In this embodiment of the inventions the PKI agent 168 returns 392 the signed object 305A directly to the requesting application.
  • Referring to FIG. 3B, a third embodiment of the invention is illustrated and again continues with the previous example. In this embodiment of the invention, the [0138] TACA 142 receives a request 310 from a requesting application 118.
  • As before, the requesting [0139] application 118 sends a request 310 to the token access control application (TACA) 142 which causes the TACA to request 315 the token security policies 184 from the token's security domain control application (SDCA) 182 and retrieves the token policies 146 for proper token selection.
  • The token security policies are returned [0140] 320 to the TACA 142 and logically combined with the host security policies 152 resulting in the set of composite security policies 152C. In an alternate embodiment of the invention, information related to the required counterpart security application agents is returned as well for verification and if necessary installation. The authentication, enablement, secure messaging parameters and token selection are again verified as before, if applicable to the embodiment of the invention.
  • In this embodiment of the invention, the [0141] TACA 142 forwards 326 the applicable portion of the security policy to the requesting application 118. The requesting application 118 becomes responsible for implementing the composite set of security policies. The requesting application signals the PIN agent 327 and causes 328 the PIN application 122 to execute. The PIN 330 is sent directly 329 to the PIN agent 156 where processing of the PIN 330 by the token PIN application 186 and the updating of registry information, if applicable to the embodiment of the invention, is performed as previously described. The PIN agent 156 signals 327 the requesting application 18 of the successful completion of the authentication transaction.
  • The requesting [0142] application 118 then signals 347 the secure messaging agent 166 to establish a secure messaging session. The secure messaging agent 166 causes the secure messaging application SM1 192 to establish a secure messaging session in accordance with the applicable portion of the composite security policy. Establishment of a secure messaging session and updating of registry entries, if applicable to the embodiment of the invention, is performed as previously described.
  • The [0143] secure messaging agent 166 signals 347 the requesting application that a secure messaging session is established. The requesting application 118 then signals 367 the PKI agent 168 to receive the object 305 to be signed. The object 305 is sent by the requesting application 118 to the PKI agent 168 where it is transferred 375 to the token PKI application, signed and returned 385 to the PKI agent 168. In this embodiment of the invention, the PKI agent 168 again returns 394 the signed object 305A directly to the requesting application.
  • Referring to FIG. 4, the steps required for implementing the invention are depicted. The sequence is initiated [0144] 400 by receiving a request to perform a security function using a security token from an application by a token access control application (TACA) 405. The TACA retrieves the token policy and selects the proper security token(s) to implement the transaction 410. The TACA then retrieves a token security policy 415 from the selected security token(s), reads the host security policy 420 and generates a composite set of security policies 425 from the logical combination of the token and host security policies.
  • The TACA ensure enforcement of the [0145] security policies 430 in one embodiment of the invention by accessing a registry comprising security parameters for verifying a set of enablement states in a registry 431, verifying an authentication state in a registry 432, verifying a secure messaging state in the registry 433 and verifying that the required security agent and/or counterpart security application are compatible 435. The discussion of compatibility verification between token security applications and host security application agents is provided under FIG. 4C below. The compatibility verification process is initiated at step A 471 and if compatibility is established between the token security applications and host security application agents at step B 493 processing continues by enforcement of the combined security policies 430. If compatibility is not established between the token security applications and host security application agents at step C 487, processing ends 480.
  • In another embodiment of the invention, the security policy is enforced without verifying security parameters (non-local registry embodiment) and continues by receiving a specific credential, if required [0146] 450) causing the execution of one or more appropriate security agents 455, sending the received credential to the appropriate security agent, if required 460, sending the received credential to the proper token application 465, establishing a secure messaging session, if required 470, performing a security function 475 and ending processing 480 after performing the security function.
  • Referring to FIG. 4A, the steps required for implementing another embodiment of the invention are depicted. The sequence is initiated [0147] 406 by receiving a request to perform a security function using a security token from an application by a token access control application (TACA) 412. The TACA retrieves a token selection policy 418 and selects the security tokens to perform the security transactions. The TACA then retrieves a token security policy 418 from the selected security token(s), reads an associated host security policy 424 and generates a composite security policy 432 from the logical combination of the token and host security policies.
  • In one embodiment of the invention, the TACA accesses a registry comprising security parameters for verifying a set of enablement states in the [0148] registry 434, verifying an authentication state in the registry 436, verifying a secure messaging state in the registry 438 and verifying that the required security agent and/or counterpart security application are compatible 442. The compatibility verification process is initiated at step A 471 and if compatibility is established between the token security applications and host security application agents at step B 493 processing continues by enforcement of the combined security policies 432. If compatibility is not established between the token security applications and host security application agents at step C 487, processing ends 496. Otherwise 448, processing continues by enforcement of the combined security policies 432.
  • In another embodiment of the invention, the security policy is enforced without verifying security parameters (non-local registry embodiment) and continues by executing the appropriate [0149] security application agents 462, sending the combined set of security policies to the appropriate security application agents 468, ensuring enforcement of the composite set of security policies by the appropriate security agents 474, receiving a specific credential, if required 480, sending the received credential to the proper token application, if required 484, establishing a secure messaging session, if required 488, performing a security function 492 and ending processing 496 after performing the security function.
  • Referring to FIG. 4B, the steps required for implementing the yet another embodiment of the invention are depicted. The sequence is initiated [0150] 403 by receiving a request to perform a security function using a security token from an application by a token access control application (TACA) 407. The TACA retrieves token policies and selects the proper security token(s) to perform the transaction 409. The TACA then retrieves a token security policy 409 from the selected security token(s), retrieves the host security policy 413 and generates a composite security policy 419 from the logical combination of the token and host security policies.
  • In one embodiment of the invention, the TACA accesses a registry comprising security parameters for verifying a set of enablement states in the [0151] registry 421, verifying an authentication state in the registry 423, verifying a secure messaging state in the registry 427 and verifying that the required security agent and/or counterpart security application are compatible 431 The compatibility verification process is initiated at step A 471 and if compatibility is established between the token security applications and host security application agents at step B 493 processing continues by enforcement of the combined security policies 430.
  • If compatibility is not established between the token security applications and host security application agents at [0152] step C 487, processing ends 480. Otherwise 439, processing continues by enforcement of the combined security policies 419.
  • In another embodiment of the invention (non-local registry embodiment), the security policy is enforced without verifying security parameters and continues by executing the [0153] appropriate security agents 443, sending the combined security policy to the requesting application 447, ensuring enforcement of the security policy by the appropriate security agents 449, receiving a specific credential, if required 451, sending the received credential to the proper token application, if required 453, establishing a secure messaging session, if required 457, performing a security function 459 and ending processing 461 after performing the security function.
  • Referring to FIG. 4C, the steps required to retrieve compatibility information from the compliant security token to the host computer system is depicted. The compatibility information ensures that the proper version of security application agent is installed on the host computer system in order to properly operate with their counterpart token security applications. The process is initiated at [0154] step A 471 by retrieving the compatibility information from the security token 473. The information may be retrieved from a registry maintained by the security domain control application installed inside the security token or provided directly by each of the token security applications.
  • The retrieved compatibility information is then used to verify that the installed host security application agents are compatible with the installed [0155] token security applications 475. If the security application agents are compatible with token security applications 477, this portion of the processing ends and returns at step B 493.
  • If one or more of the security application agents are not compatible with one or more of the [0156] token security applications 477, one or more compatible security application agents are retrieved 479. The security application agent(s) may be retrieved from either a local or remote storage location. A digital signature verification is then performed 481.
  • If the digital signature(s) are not verified [0157] 483, the installation process is aborted 485 and processing terminated at step C 487. If the digital signature(s) are verified 483, the retrieved application(s) are installed on the host computer system 489. The newly installed security application agent(s) are then registered with either the host operating system or token access control application by entry of parameters in a registry 491. Once the appropriate registry has been updated with the parameters, processing is completed at step B 493.
  • 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 blocks. 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. [0158]

Claims (54)

What is claimed:
1. A system which provides a modular uniform security applications framework for a host computer system and a compliant security token in processing communications with the host computer system comprising:
said compliant security token including a set of retrievable token security policies and one or more token security applications;
said host computer system including a retrievable set of host security policies and a token access control application, wherein said token access control application includes means for;
retrieving at least a portion of said host security policies from said host computer system,
retrieving at least a portion of said token security policies from said compliant security token,
generating a composite set of security policies from said host security policies and said token security policies, and
ensuring enforcement of said composite set of security policies on a request to perform a security function using said compliant security token.
2. The system according to claim 1 further including at least one security application agent functionally associated with said token access control application, wherein said at least one security application agent includes means for performing said security function with said one or more token security applications in accordance with said composite security policies.
3. The system according to claim 2 wherein said token access control application further including means for;
receiving an object from an application,
causing said at least one of security application agent to execute,
sending said object to said at least one security application agent, and
returning said object to said application after said at least one security application agent and said one or more token security applications have completed performing said security function.
4. The system according to claim 3 wherein said at least one security application agent further includes means for returning said object to said token access control application after performing said security function with said one or more token security applications.
5. The system according to claim 3 wherein said object includes a digital certificate, data to undergo a cryptographic function or data to be stored in said compliant security token.
6. The system according to claim 1 wherein said security function includes authentication using a credential.
7. The system according to claim 6 wherein said credential includes a personal identification number, a password or a biometric sample.
8. The system according to claim 6 wherein said security function further includes establishing a secure messaging session.
9. A system which provides a modular uniform security applications framework for a host computer system and a compliant security token in processing communications with the host computer system comprising:
said compliant security token including a set of retrievable token security policies and one or more token security applications;
said host computer system including a token access control application, a retrievable set of host security policies and at least one security application agent functionally associated with said token access control application;
said token access control application including means for;
retrieving at least a portion of said host security policies from said host computer system,
retrieving at least a portion of said token security policies from said compliant security token,
generating a composite set of security policies from said host security policies and said token security policies, and
transferring at least a portion of said composite set of security policies to said at least one of security application agent.
10. The system according to claim 9 wherein said at least one security application agent further includes means for;
ensuring enforcement of said at least a portion of said composite set of security policies on a request to perform a security function using said compliant security token,
performing one or more security functions independently with said one or more token security applications in accordance with said composite set of security policies.
11. The system according to claim 10 wherein said at least one security application agent and said one or more token security applications perform said one or more security functions independently but in concert with a middleware security application.
12. The system according to claim 11 wherein said one or more security functions includes biometric authentication.
13. A system which provides a modular uniform security applications framework for a host computer system and a compliant security token in processing communications with the host computer system comprising:
said compliant security token including a set of retrievable token security policies and one or more token security applications;
said host computer system including a requesting application, a token access control application, a retrievable set of host security policies and at least one security application agent functionally associated with said token access control application;
said token access control application including means for;
retrieving at least a portion of said host security policies from said host computer system,
retrieving at least a portion of said token security policies from said compliant security token,
generating a composite set of security policies from said host security policies and said token security policies, and
returning at least a portion of said composite set of security policies to said requesting application;
said requesting application including means for;
generating a request to perform a security function using said compliant security token,
ensuring enforcement of said at least a portion of said composite set of security policies, and
causing said at least one security application agent to execute in response to said request; and
said at least one security application agent including means for performing a security function with said one or more token security applications in accordance with said at least a portion of said composite set of security requirements.
14. The system according to claim 13 wherein said security function includes authentication using a credential.
15. The system according to claim 14 wherein said security function further includes establishing a secure messaging session.
16. The system according to claim 13 wherein said at least one security application agent further includes means for returning an object to said requesting application after performing said security function with said one or more token security applications.
17. A system which provides a modular uniform security applications framework for a host computer system and a compliant security token in processing communications with the host computer system comprising:
said compliant security token including a set of retrievable token security policies and one or more token security applications;
said host computer system including a token access control application, a retrievable set of host security policies and at least one security application agent functionally associated with said token access control application;
said token access control application including means for;
retrieving at least a portion of said host security policies from said host computer system,
retrieving at least a portion of said token security policies from said compliant security token,
generating a composite set of security policies from said host security policies and said token security policies,
ensuring enforcement of said composite set of security policies on a request to perform a security function using said compliant security token, and
said at least one security application agent, including means for performing said security function with said one or more token security applications in accordance with said composite set of security policies.
18. The system according to claim 1, 9, 13 or 17 wherein said one or more token security applications includes an authentication application.
19. The system according to claim 18 wherein said one or more token security applications further includes a secure messaging application.
20. The system according to claim 18 wherein said token access control application further includes a registry.
21. The system according to claim 20 wherein said registry is comprised of a plurality of security parameters associated with at least one registered token security application, at least one registered security agent application, at least one enablement flag and at least one operational state.
22. The system according to claim 19 wherein said host computer system further includes means for storing said composite security policies.
23. The system according to claim 19 wherein said host security policies includes at least one host access control rule.
24. The system according to claim 23 wherein said token security policies include at least one token access control rule.
25. The system according to claim 24 wherein said composite set of security policies is generated from a most restrictive logical combination of said at least one host access control rule and said at least one token access control rule by said token access control application.
26. The system according to claim 25 wherein said host security policies further includes token selection rules.
27. A method for using a modular uniform security applications framework for a host computer system and a compliant security token comprising the steps of:
a. receiving a token security function request from a requesting application,
b. retrieving a set of token security policies,
c. retrieving a set of host security policies,
d. combining said token security policies and said host security policies into a composite security policy,
e. ensuring enforcement of said composite security policy on said security function request,
f. receiving a credential if required by said composite security policy,
g. sending said credential to an appropriate security application agent if required by said composite security policy,
h. sending said credential to an appropriate token security application if required by said composite security policy, and
i. performing a security function in accordance with said composite security policy.
28. A method for using a modular uniform security applications framework for a host computer system and a compliant security token comprising the steps of:
a. receiving a token security function request from a requesting application,
b. retrieving a set of token security policies,
c. retrieving a set of host security policies,
d. combining said token security policies and said host security policies into a composite security policy,
e. sending at least a portion of said composite security policy to a appropriate security application agent,
f. ensuring enforcement of at least a portion of said composite security policy on said security function request,
g. receiving a credential if required by said composite security policy,
h. sending said credential to an appropriate token security application if required by said composite security policy, and
h. performing a security function in accordance with said composite security policy.
29. A method for providing a modular uniform security applications framework for a host computer system and a compliant security token comprising the steps of:
a. receiving a token security function request from a requesting application,
b. retrieving a set of token security policies,
c. retrieving a set of host security policies,
d. combining said token security policies and said host security policies into a composite security policy,
e. sending at least a portion of said composite security policy to said requesting application,
f. ensuring enforcement of at least a portion of said composite security policy by said requesting application,
g. receiving a credential if required by said composite security policy,
h. sending said credential to an appropriate security application agent if required by said composite security policy,
i. sending said credential to an appropriate token security application if required by said composite security policy, and
j. performing a security function in accordance with said composite security policy.
30. The method according to claim 27, 28 or 29 wherein step 27.d, 28.d or 29.d further including the steps of:
a. verifying a plurality of enablement states in a registry,
b. verifying at least one authentication state in said registry, and
c. verifying a secure messaging state in said registry.
31. The method according to claim 30 further including the steps of verifying that all required applications are operatively installed to ensure enforcement said composite set of security policies and if not, retrieving and operatively installing the missing of said required applications.
32. A computer program product embodied in a tangible form readable by a processor having executable instructions stored thereon for causing a computer to provide a modular uniform security applications framework for a host computer system and a compliant security token, said executable instructions comprising computer readable program code means for causing said computer to;
a. receive a token security function request from a requesting application,
b. retrieve a set of token security policies,
c. retrieve a set of host security policies,
d. combine said token security policies and said host security policies into a composite security policy,
e. enforce said composite security policy on said security function request, receive a credential if required by said composite security policy,
h. send said credential to an appropriate security application agent if required by said composite security policy,
i. send said credential to an appropriate token security application if required by said composite security policy, and
j. perform a security function in accordance with said composite security policy.
33. A computer program product embodied in a tangible form readable by a processor having executable instructions stored thereon for causing a computer to provide a modular uniform security applications framework for a host computer system and a compliant security token, said executable instructions comprising computer readable program code means for causing said computer to;
a. receive a security function request from a requesting application,
b. retrieve a set of token security policies,
c. retrieve a set of host security policies,
d. combine said token security policies and said host security policies into a composite security policy,
e. send at least a portion of said composite security policy to an appropriate security application agent,
f. enforce at least a portion of said composite security policy on said security function request,
g. receive a credential if required by said composite security policy,
h. send said credential to an appropriate token security application if required by said composite security policy, and
i. perform a security function in accordance with said composite security policy.
34. A computer program product embodied in a tangible form readable by a processor having executable instructions stored thereon for causing a computer to provide a modular uniform security applications framework for a host computer system and a compliant security token, said executable instructions comprising computer readable program code means for causing said computer to;
a. receive a security function request from a requesting application,
b. retrieve a set of token security policies,
c. retrieve a set of host security policies,
d. combine said token security policies and said host security policies into a composite security policy,
e. send at least a portion of said composite security policy to requesting application,
f. enforce at least a portion of said composite security policy by said requesting application,
g. receive a credential if required by said composite security policy,
h. send said credential to an appropriate security application agent if required by said composite security policy,
i. send said credential to an appropriate token security application if required by said composite security policy, and
j. perform a security function in accordance with said composite security policy.
35. The computer program product according to claim 32, 33 or 34 wherein step 32.d, 33.d or 34.d further including the executable instructions for:
a. verification of a plurality of enablement states in a registry,
b. verification of at least one authentication state in said registry, and
c. verification of a secure messaging state in said registry.
36. The computer program product according to claim 35 further including the executable instructions for verification that all required applications are operatively installed to enforce said composite set of security policies and if not, to cause the retrieval and operative installation of the missing of said required applications.
37. A system which provides for retrieval of compatibility information associated with one or more counterpart security application agents from a functionally connected security token by at least one security application installed on a host computer system comprising:
said functionally connected security token including said retrievable compatibility information and one or more token security applications installed in said functionally connected security token, wherein said retrievable capability information relates to compatibility between said one or more counterpart security application agents and said one or more token security applications;
said host computer system including said one or more counterpart security application agents and said at least one security application, wherein said at least one security application includes means for;
retrieving said compatibility information related to said one or more counterpart security application agents;
verifying that at least one compatible counterpart security application agent is operatively installed and if not, retrieving and operatively installing at least one compatible counterpart security application agent.
38. The system according to claim 37 wherein said at least one security application is installed in a middleware services layer.
39. The system according to claim 37 wherein said at least one security application includes a token access control application.
40. The system according to claim 37 wherein said retrieved at least one compatible counterpart security application agent is retrieved from a local storage location.
41. The system according to claim 37 wherein said retrieved at least one compatible counterpart security application agent is retrieved from a remote storage location.
42. The system according to claim 37 wherein installing said retrieved at least one compatible counterpart security application agent is accomplished by entering one or more parameters associated with said at least one compatible counterpart security application agent in a registry.
43. The system according to claim 42 wherein said at least one compatible counterpart security application agent is a module which can be added, removed or replaced without disruption of any existing dependencies by changing said one or more parameters in said registry.
44. The system according to claim 37 wherein said at least one security application further includes means for causing a digital signature verification to performed on said retrieved at least one compatible counterpart security application agent before said at least one compatible counterpart security application agent is operatively installed and if said digital signature verification is unsuccessful aborting said installation.
45. A method which provides for retrieval of compatibility information related to one or more counterpart security application agents from a functionally connected security token by at least one security application installed on a host computer system comprising the steps of:
a. retrieving said compatibility information related to said one or more counterpart security application agents from said functionally connected security token,
b. verifying that at least one compatible counterpart security application agent is operatively installed on a host computer system, and if not,
c. retrieving said at least one compatible counterpart security application agent and
d. operatively installing said at least one compatible counterpart security application agent on said host computer system.
46. The method according to claim 45 wherein said at least one compatible counterpart security application agent is retrieved from a local storage location.
47. The method according to claim 45 wherein said at least one compatible counterpart security application agent is retrieved from a remote storage location.
48. The method according to claim 45 wherein step 45.c includes the steps of;
a. performing a signature verification of said retrieved at least one compatible counterpart security application agent, and
b. aborting an installation of said retrieved at least one compatible counterpart security application agent if said signature verification is unsuccessful.
49. The method according to claim 45 wherein step 45.d includes the step of entering one or parameters associated with said at least one compatible counterpart security application agent into a registry.
50. A computer program product embodied in a tangible form readable by a processor having executable instructions stored thereon for causing a computer to provide for retrieval of compatibility information related to one or more counterpart security application agents from a functionally connected security token by at least one security application installed on a host computer system, said executable instructions comprising computer readable program code means for causing said computer to;
a. retrieve said compatibility information related to said one or more counterpart security application agents from said functionally connected security token,
b. verify that at least one compatible counterpart security application agent is operatively installed on a host computer system, and if not,
c. retrieve said at least one compatible counterpart security application agent and
d. operatively install said at least one compatible counterpart security application agent on said host computer system.
51. The computer program product according to claim 50 further including the executable instructions for retrieval of said at least one compatible counterpart security application agent from a local storage location.
52. The computer program product according to claim 50 further including the executable instructions for retrieval of said at least one compatible counterpart security application agent from a remote storage location.
53. The computer program product according to claim 50 further including the executable instructions for;
a. performance of a signature verification of said retrieved at least one compatible counterpart security application agent, and
b. aborting an installation of said retrieved at least one compatible counterpart security application agent if said signature verification is unsuccessful.
54. The computer program product according to claim 50 further including the executable instructions for entry of one or parameters associated with said at least one compatible counterpart security application agent into a registry.
US10/425,028 2003-04-29 2003-04-29 Uniform modular framework for a host computer system Abandoned US20040221174A1 (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
US10/425,028 US20040221174A1 (en) 2003-04-29 2003-04-29 Uniform modular framework for a host computer system
EP04291090.1A EP1473618B1 (en) 2003-04-29 2004-04-27 Uniform modular framework for a host computer system
US11/939,444 US7921298B2 (en) 2003-04-29 2007-11-13 Uniform modular framework for a host computer system
US12/932,499 US8732478B2 (en) 2003-04-29 2011-02-25 Uniform modular framework for a host computer system
US13/065,992 US8942429B2 (en) 2003-04-29 2011-04-04 Method for improving false acceptance rate discrimination for biometric authentication systems
US14/248,389 US9576111B2 (en) 2003-04-29 2014-04-09 Uniform modular framework for a host computer system
US15/402,307 US20170195368A1 (en) 2003-04-29 2017-01-10 Uniform modular framework for a host computer system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/425,028 US20040221174A1 (en) 2003-04-29 2003-04-29 Uniform modular framework for a host computer system

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/939,444 Continuation US7921298B2 (en) 2003-04-29 2007-11-13 Uniform modular framework for a host computer system

Publications (1)

Publication Number Publication Date
US20040221174A1 true US20040221174A1 (en) 2004-11-04

Family

ID=32990357

Family Applications (5)

Application Number Title Priority Date Filing Date
US10/425,028 Abandoned US20040221174A1 (en) 2003-04-29 2003-04-29 Uniform modular framework for a host computer system
US11/939,444 Expired - Fee Related US7921298B2 (en) 2003-04-29 2007-11-13 Uniform modular framework for a host computer system
US12/932,499 Expired - Lifetime US8732478B2 (en) 2003-04-29 2011-02-25 Uniform modular framework for a host computer system
US14/248,389 Expired - Lifetime US9576111B2 (en) 2003-04-29 2014-04-09 Uniform modular framework for a host computer system
US15/402,307 Abandoned US20170195368A1 (en) 2003-04-29 2017-01-10 Uniform modular framework for a host computer system

Family Applications After (4)

Application Number Title Priority Date Filing Date
US11/939,444 Expired - Fee Related US7921298B2 (en) 2003-04-29 2007-11-13 Uniform modular framework for a host computer system
US12/932,499 Expired - Lifetime US8732478B2 (en) 2003-04-29 2011-02-25 Uniform modular framework for a host computer system
US14/248,389 Expired - Lifetime US9576111B2 (en) 2003-04-29 2014-04-09 Uniform modular framework for a host computer system
US15/402,307 Abandoned US20170195368A1 (en) 2003-04-29 2017-01-10 Uniform modular framework for a host computer system

Country Status (2)

Country Link
US (5) US20040221174A1 (en)
EP (1) EP1473618B1 (en)

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050022012A1 (en) * 2001-09-28 2005-01-27 Derek Bluestone Client-side network access polices and management applications
US20050081045A1 (en) * 2003-08-15 2005-04-14 Fiberlink Communications Corporation System, method, apparatus and computer program product for facilitating digital communications
US20050138421A1 (en) * 2003-12-23 2005-06-23 Fedronic Dominique L.J. Server mediated security token access
EP1551149A2 (en) 2003-12-22 2005-07-06 Activcard Inc. Universal secure messaging for remote security tokens
WO2005069530A1 (en) * 2004-01-05 2005-07-28 Oqo Incorporated Connector including electronic device
US20050254651A1 (en) * 2001-07-24 2005-11-17 Porozni Baryy I Wireless access system, method, signal, and computer program product
US20060168653A1 (en) * 2005-01-27 2006-07-27 Contrera Suzanne H Personal network security token
US20070055752A1 (en) * 2005-09-08 2007-03-08 Fiberlink Dynamic network connection based on compliance
US20070143851A1 (en) * 2005-12-21 2007-06-21 Fiberlink Method and systems for controlling access to computing resources based on known security vulnerabilities
US20070143827A1 (en) * 2005-12-21 2007-06-21 Fiberlink Methods and systems for intelligently controlling access to computing resources
US20080066160A1 (en) * 2006-09-11 2008-03-13 Microsoft Corporation Security Language Expressions for Logic Resolution
US20080066170A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Security Assertion Revocation
US20080065899A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Variable Expressions in Security Assertions
US20080066171A1 (en) * 2006-09-11 2008-03-13 Microsoft Corporation Security Language Translations with Logic Resolution
US20080066175A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Security Authorization Queries
US20080066147A1 (en) * 2006-09-11 2008-03-13 Microsoft Corporation Composable Security Policies
US20080066159A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Controlling the Delegation of Rights
US20080222696A1 (en) * 2004-08-16 2008-09-11 Fiberlink Communications Corporation System, Method, Apparatus, and Computer Program Product for Facilitating Digital Communications
US20090222879A1 (en) * 2008-03-03 2009-09-03 Microsoft Corporation Super policy in information protection systems
US20090260071A1 (en) * 2008-04-14 2009-10-15 Microsoft Corporation Smart module provisioning of local network devices
US7636844B2 (en) * 2003-11-17 2009-12-22 Intel Corporation Method and system to provide a trusted channel within a computer system for a SIM device
US7690032B1 (en) * 2009-05-22 2010-03-30 Daon Holdings Limited Method and system for confirming the identity of a user
US20110205020A1 (en) * 2003-04-29 2011-08-25 Le Saint Eric F Method for improving false acceptance rate discrimination for biometric authentication systems
US20120124643A1 (en) * 2005-02-23 2012-05-17 Mark Moriconi Systems and Methods for Analyzing Application Security Policies
US8225378B2 (en) 2006-09-08 2012-07-17 Microsoft Corporation Auditing authorization decisions
US20130031595A1 (en) * 2011-07-26 2013-01-31 Nevstruev Sergey V Efficient securing of data on mobile devices
US20130326581A1 (en) * 2003-12-18 2013-12-05 Casey S. Bahr Client Side Security Management for an Operations, Administrations and Maintenance System for Wireless Clients
US20140066015A1 (en) * 2012-08-28 2014-03-06 Selim Aissi Secure device service enrollment
US20150288722A1 (en) * 2011-08-09 2015-10-08 CloudPassage, Inc. Systems and methods for implementing security
US9678727B1 (en) * 2005-03-15 2017-06-13 Open Invention Network, Llc Code generator tool for building software applications with reusable components

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10181953B1 (en) 2013-09-16 2019-01-15 Amazon Technologies, Inc. Trusted data verification
US20060021003A1 (en) * 2004-06-23 2006-01-26 Janus Software, Inc Biometric authentication system
EP1861807B1 (en) 2005-03-24 2012-11-07 Privaris, Inc. Biometric identification device with smartcard capabilities
US8656268B2 (en) 2005-07-01 2014-02-18 Microsoft Corporation Queueing events in an interactive media environment
US8799757B2 (en) 2005-07-01 2014-08-05 Microsoft Corporation Synchronization aspects of interactive multimedia presentation management
US8327142B2 (en) 2006-09-27 2012-12-04 Secureauth Corporation System and method for facilitating secure online transactions
JP2008176435A (en) 2007-01-17 2008-07-31 Hitachi Ltd Settlement terminal and ic card
US8301877B2 (en) 2008-03-10 2012-10-30 Secureauth Corporation System and method for configuring a valid duration period for a digital certificate
GB2471282B (en) 2009-06-22 2015-02-18 Barclays Bank Plc Method and system for provision of cryptographic services
US8613067B2 (en) 2009-11-17 2013-12-17 Secureauth Corporation Single sign on with multiple authentication factors
WO2011106716A1 (en) 2010-02-25 2011-09-01 Secureauth Corporation Security device provisioning
US20110219440A1 (en) * 2010-03-03 2011-09-08 Microsoft Corporation Application-level denial-of-service attack protection
US9258312B1 (en) 2010-12-06 2016-02-09 Amazon Technologies, Inc. Distributed policy enforcement with verification mode
US9237155B1 (en) 2010-12-06 2016-01-12 Amazon Technologies, Inc. Distributed policy enforcement with optimizing policy transformations
US8874888B1 (en) 2011-01-13 2014-10-28 Google Inc. Managed boot in a cloud system
US8769642B1 (en) 2011-05-31 2014-07-01 Amazon Technologies, Inc. Techniques for delegation of access privileges
US8973108B1 (en) 2011-05-31 2015-03-03 Amazon Technologies, Inc. Use of metadata for computing resource access
US9075979B1 (en) 2011-08-11 2015-07-07 Google Inc. Authentication based on proximity to mobile device
US8966198B1 (en) 2011-09-01 2015-02-24 Google Inc. Providing snapshots of virtual storage devices
US9203613B2 (en) 2011-09-29 2015-12-01 Amazon Technologies, Inc. Techniques for client constructed sessions
US9197409B2 (en) 2011-09-29 2015-11-24 Amazon Technologies, Inc. Key derivation techniques
US9178701B2 (en) 2011-09-29 2015-11-03 Amazon Technologies, Inc. Parameter based key derivation
US8856780B2 (en) * 2011-11-25 2014-10-07 Automotive Data Solutions Inc. Method and system to remotely flash an external module
CA2859794A1 (en) 2011-12-22 2013-06-27 Abbvie Inc. Application security framework
US8800009B1 (en) * 2011-12-30 2014-08-05 Google Inc. Virtual machine service access
US8892865B1 (en) 2012-03-27 2014-11-18 Amazon Technologies, Inc. Multiple authority key derivation
US9215076B1 (en) 2012-03-27 2015-12-15 Amazon Technologies, Inc. Key generation for hierarchical data access
US8739308B1 (en) 2012-03-27 2014-05-27 Amazon Technologies, Inc. Source identification for unauthorized copies of content
US9258118B1 (en) 2012-06-25 2016-02-09 Amazon Technologies, Inc. Decentralized verification in a distributed system
US9660972B1 (en) 2012-06-25 2017-05-23 Amazon Technologies, Inc. Protection from data security threats
EP2741461A1 (en) * 2012-12-07 2014-06-11 Gemalto SA Method of allowing communication between a secure element and a server
US9407440B2 (en) 2013-06-20 2016-08-02 Amazon Technologies, Inc. Multiple authority data security and access
EP2827274A1 (en) * 2013-07-17 2015-01-21 PT Oberthur Technologies Indonesia LTD. Method of enforcing control of access by a device to a secure element, and corresponding secure element
US9521000B1 (en) 2013-07-17 2016-12-13 Amazon Technologies, Inc. Complete forward access sessions
US9237019B2 (en) 2013-09-25 2016-01-12 Amazon Technologies, Inc. Resource locators with keys
US9311500B2 (en) 2013-09-25 2016-04-12 Amazon Technologies, Inc. Data security using request-supplied keys
US10243945B1 (en) 2013-10-28 2019-03-26 Amazon Technologies, Inc. Managed identity federation
US9420007B1 (en) 2013-12-04 2016-08-16 Amazon Technologies, Inc. Access control using impersonization
US9374368B1 (en) 2014-01-07 2016-06-21 Amazon Technologies, Inc. Distributed passcode verification system
US9369461B1 (en) 2014-01-07 2016-06-14 Amazon Technologies, Inc. Passcode verification using hardware secrets
US9292711B1 (en) 2014-01-07 2016-03-22 Amazon Technologies, Inc. Hardware secret usage limits
US9270662B1 (en) 2014-01-13 2016-02-23 Amazon Technologies, Inc. Adaptive client-aware session security
US10771255B1 (en) 2014-03-25 2020-09-08 Amazon Technologies, Inc. Authenticated storage operations
US9258117B1 (en) 2014-06-26 2016-02-09 Amazon Technologies, Inc. Mutual authentication with symmetric secrets and signatures
US10326597B1 (en) 2014-06-27 2019-06-18 Amazon Technologies, Inc. Dynamic response signing capability in a distributed system
US20160231731A1 (en) * 2015-02-10 2016-08-11 StandLogix, Inc System, method and apparatus for user interaction with a workstation
US10122689B2 (en) 2015-06-16 2018-11-06 Amazon Technologies, Inc. Load balancing with handshake offload
US10122692B2 (en) 2015-06-16 2018-11-06 Amazon Technologies, Inc. Handshake offload
US10116440B1 (en) 2016-08-09 2018-10-30 Amazon Technologies, Inc. Cryptographic key management for imported cryptographic keys
US10819518B2 (en) 2018-10-12 2020-10-27 Mastercard International Incorporated Systems and methods for advanced application security
US11025672B2 (en) * 2018-10-25 2021-06-01 Palantir Technologies Inc. Approaches for securing middleware data access
US11809611B2 (en) * 2020-02-24 2023-11-07 Microsoft Technology Licensing, Llc Protecting device detachment with bus encryption

Citations (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4945468A (en) * 1988-02-01 1990-07-31 International Business Machines Corporation Trusted path mechanism for virtual terminal environments
US4993068A (en) * 1989-11-27 1991-02-12 Motorola, Inc. Unforgeable personal identification system
US5491752A (en) * 1993-03-18 1996-02-13 Digital Equipment Corporation, Patent Law Group System for increasing the difficulty of password guessing attacks in a distributed authentication scheme employing authentication tokens
US5577121A (en) * 1994-06-09 1996-11-19 Electronic Payment Services, Inc. Transaction system for integrated circuit cards
US5655148A (en) * 1994-05-27 1997-08-05 Microsoft Corporation Method for automatically configuring devices including a network adapter without manual intervention and without prior configuration information
US5802176A (en) * 1996-03-22 1998-09-01 Activcard System for controlling access to a function, using a plurality of dynamic encryption variables
US5878142A (en) * 1994-07-12 1999-03-02 Information Resource Engineering, Inc. Pocket encrypting and authenticating communications device
US5887065A (en) * 1996-03-22 1999-03-23 Activcard System and method for user authentication having clock synchronization
US5937068A (en) * 1996-03-22 1999-08-10 Activcard System and method for user authentication employing dynamic encryption variables
US6005942A (en) * 1997-03-24 1999-12-21 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6016476A (en) * 1997-08-11 2000-01-18 International Business Machines Corporation Portable information and transaction processing system and method utilizing biometric authorization and digital certificate security
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US6076075A (en) * 1995-09-25 2000-06-13 Cardis Enterprise International N.V. Retail unit and a payment unit for serving a customer on a purchase and method for executing the same
US6108789A (en) * 1998-05-05 2000-08-22 Liberate Technologies Mechanism for users with internet service provider smart cards to roam among geographically disparate authorized network computer client devices without mediation of a central authority
US6169804B1 (en) * 1996-11-21 2001-01-02 Pitney Bowes Inc. Method for verifying the expected postage security device and its status
US6175922B1 (en) * 1996-12-04 2001-01-16 Esign, Inc. Electronic transaction systems and methods therefor
US6178504B1 (en) * 1998-03-12 2001-01-23 Cheyenne Property Trust C/O Data Securities International, Inc. Host system elements for an international cryptography framework
US20010024066A1 (en) * 2000-01-20 2001-09-27 International Business Machines Corporation Handheld device, smart card interface device (IFD) and data transmission method
US6308317B1 (en) * 1996-10-25 2001-10-23 Schlumberger Technologies, Inc. Using a high level programming language with a microcontroller
US20020002684A1 (en) * 1998-05-01 2002-01-03 Barbara L. Fox Intelligent trust management method and system
US20020040936A1 (en) * 1998-10-27 2002-04-11 David C. Wentker Delegated management of smart card applications
US6397328B1 (en) * 1996-11-21 2002-05-28 Pitney Bowes Inc. Method for verifying the expected postage security device and an authorized host system
US20020089410A1 (en) * 2000-11-13 2002-07-11 Janiak Martin J. Biometric authentication device for use with a personal digital assistant
US20020095587A1 (en) * 2001-01-17 2002-07-18 International Business Machines Corporation Smart card with integrated biometric sensor
US6547150B1 (en) * 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method
US20030154375A1 (en) * 2002-02-08 2003-08-14 Weimin Yang Universal crypto-adaptor system for supporting multiple APIs and multiple smart cards
US6609199B1 (en) * 1998-10-26 2003-08-19 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
US6657956B1 (en) * 1996-03-07 2003-12-02 Bull Cp8 Method enabling secure access by a station to at least one server, and device using same
US6738901B1 (en) * 1999-12-15 2004-05-18 3M Innovative Properties Company Smart card controlled internet access
US6748532B1 (en) * 1999-10-29 2004-06-08 Sun Microsystems, Inc. Universal smart card access system
US6788956B2 (en) * 1999-12-06 2004-09-07 Alcatel Terminal to execute a terminal application
US7024689B2 (en) * 2002-12-13 2006-04-04 Intuit, Inc. Granting access rights to unattended software
US7152230B2 (en) * 2000-11-09 2006-12-19 Hitachi, Ltd. Storage media storing data related to smart card, smart card system and smart card application loading method

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5577209A (en) * 1991-07-11 1996-11-19 Itt Corporation Apparatus and method for providing multi-level security for communication among computers and terminals on a network
US5276735A (en) * 1992-04-17 1994-01-04 Secure Computing Corporation Data enclave and trusted path system
US6148083A (en) * 1996-08-23 2000-11-14 Hewlett-Packard Company Application certification for an international cryptography framework
US6230271B1 (en) * 1998-01-20 2001-05-08 Pilot Network Services, Inc. Dynamic policy-based apparatus for wide-range configurable network service authentication and access control using a fixed-path hardware configuration
US6484261B1 (en) * 1998-02-17 2002-11-19 Cisco Technology, Inc. Graphical network security policy management
US7111321B1 (en) * 1999-01-25 2006-09-19 Dell Products L.P. Portable computer system with hierarchical and token-based security policies
US7174452B2 (en) * 2001-01-24 2007-02-06 Broadcom Corporation Method for processing multiple security policies applied to a data packet structure
US6513721B1 (en) * 2000-11-27 2003-02-04 Microsoft Corporation Methods and arrangements for configuring portable security token features and contents
US8141144B2 (en) * 2001-05-10 2012-03-20 Hewlett-Packard Development Company, L.P. Security policy management for network devices
US20020194499A1 (en) * 2001-06-15 2002-12-19 Audebert Yves Louis Gabriel Method, system and apparatus for a portable transaction device
US8209753B2 (en) * 2001-06-15 2012-06-26 Activcard, Inc. Universal secure messaging for remote security tokens
US7546629B2 (en) * 2002-03-06 2009-06-09 Check Point Software Technologies, Inc. System and methodology for security policy arbitration
US7024351B2 (en) * 2001-08-21 2006-04-04 Microsoft Corporation Method and apparatus for robust efficient parsing
US20030065942A1 (en) * 2001-09-28 2003-04-03 Lineman David J. Method and apparatus for actively managing security policies for users and computers in a network
JP2003203140A (en) * 2001-10-30 2003-07-18 Asgent Inc Method for grasping situation of information system and device used in the same
US8316051B1 (en) * 2001-11-30 2012-11-20 Oralce International Corporation Techniques for adding multiple security policies to a database system
US7921288B1 (en) * 2001-12-12 2011-04-05 Hildebrand Hal S System and method for providing different levels of key security for controlling access to secured items
US7574734B2 (en) * 2002-08-15 2009-08-11 Dominique Louis Joseph Fedronic System and method for sequentially processing a biometric sample
US7665125B2 (en) * 2002-09-23 2010-02-16 Heard Robert W System and method for distribution of security policies for mobile devices
US7426642B2 (en) * 2002-11-14 2008-09-16 International Business Machines Corporation Integrating legacy application/data access with single sign-on in a distributed computing environment
US7743158B2 (en) * 2002-12-04 2010-06-22 Ntt Docomo, Inc. Access network dynamic firewall
US7353533B2 (en) * 2002-12-18 2008-04-01 Novell, Inc. Administration of protection of data accessible by a mobile device
US7907935B2 (en) * 2003-12-22 2011-03-15 Activcard Ireland, Limited Intelligent remote device
US7360237B2 (en) * 2004-07-30 2008-04-15 Lehman Brothers Inc. System and method for secure network connectivity

Patent Citations (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4945468A (en) * 1988-02-01 1990-07-31 International Business Machines Corporation Trusted path mechanism for virtual terminal environments
US4993068A (en) * 1989-11-27 1991-02-12 Motorola, Inc. Unforgeable personal identification system
US5491752A (en) * 1993-03-18 1996-02-13 Digital Equipment Corporation, Patent Law Group System for increasing the difficulty of password guessing attacks in a distributed authentication scheme employing authentication tokens
US5655148A (en) * 1994-05-27 1997-08-05 Microsoft Corporation Method for automatically configuring devices including a network adapter without manual intervention and without prior configuration information
US5577121A (en) * 1994-06-09 1996-11-19 Electronic Payment Services, Inc. Transaction system for integrated circuit cards
US5878142A (en) * 1994-07-12 1999-03-02 Information Resource Engineering, Inc. Pocket encrypting and authenticating communications device
US6076075A (en) * 1995-09-25 2000-06-13 Cardis Enterprise International N.V. Retail unit and a payment unit for serving a customer on a purchase and method for executing the same
US6657956B1 (en) * 1996-03-07 2003-12-02 Bull Cp8 Method enabling secure access by a station to at least one server, and device using same
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US5887065A (en) * 1996-03-22 1999-03-23 Activcard System and method for user authentication having clock synchronization
US5937068A (en) * 1996-03-22 1999-08-10 Activcard System and method for user authentication employing dynamic encryption variables
US5802176A (en) * 1996-03-22 1998-09-01 Activcard System for controlling access to a function, using a plurality of dynamic encryption variables
US6308317B1 (en) * 1996-10-25 2001-10-23 Schlumberger Technologies, Inc. Using a high level programming language with a microcontroller
US6169804B1 (en) * 1996-11-21 2001-01-02 Pitney Bowes Inc. Method for verifying the expected postage security device and its status
US6397328B1 (en) * 1996-11-21 2002-05-28 Pitney Bowes Inc. Method for verifying the expected postage security device and an authorized host system
US6175922B1 (en) * 1996-12-04 2001-01-16 Esign, Inc. Electronic transaction systems and methods therefor
US6005942A (en) * 1997-03-24 1999-12-21 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6233683B1 (en) * 1997-03-24 2001-05-15 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US6016476A (en) * 1997-08-11 2000-01-18 International Business Machines Corporation Portable information and transaction processing system and method utilizing biometric authorization and digital certificate security
US6178504B1 (en) * 1998-03-12 2001-01-23 Cheyenne Property Trust C/O Data Securities International, Inc. Host system elements for an international cryptography framework
US20020002684A1 (en) * 1998-05-01 2002-01-03 Barbara L. Fox Intelligent trust management method and system
US6108789A (en) * 1998-05-05 2000-08-22 Liberate Technologies Mechanism for users with internet service provider smart cards to roam among geographically disparate authorized network computer client devices without mediation of a central authority
US6609199B1 (en) * 1998-10-26 2003-08-19 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
US20020040936A1 (en) * 1998-10-27 2002-04-11 David C. Wentker Delegated management of smart card applications
US6547150B1 (en) * 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method
US6748532B1 (en) * 1999-10-29 2004-06-08 Sun Microsystems, Inc. Universal smart card access system
US6788956B2 (en) * 1999-12-06 2004-09-07 Alcatel Terminal to execute a terminal application
US6738901B1 (en) * 1999-12-15 2004-05-18 3M Innovative Properties Company Smart card controlled internet access
US20010024066A1 (en) * 2000-01-20 2001-09-27 International Business Machines Corporation Handheld device, smart card interface device (IFD) and data transmission method
US7152230B2 (en) * 2000-11-09 2006-12-19 Hitachi, Ltd. Storage media storing data related to smart card, smart card system and smart card application loading method
US20020089410A1 (en) * 2000-11-13 2002-07-11 Janiak Martin J. Biometric authentication device for use with a personal digital assistant
US20020095587A1 (en) * 2001-01-17 2002-07-18 International Business Machines Corporation Smart card with integrated biometric sensor
US20030154375A1 (en) * 2002-02-08 2003-08-14 Weimin Yang Universal crypto-adaptor system for supporting multiple APIs and multiple smart cards
US7024689B2 (en) * 2002-12-13 2006-04-04 Intuit, Inc. Granting access rights to unattended software

Cited By (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7712128B2 (en) 2001-07-24 2010-05-04 Fiberlink Communication Corporation Wireless access system, method, signal, and computer program product
US20050254651A1 (en) * 2001-07-24 2005-11-17 Porozni Baryy I Wireless access system, method, signal, and computer program product
US8200773B2 (en) 2001-09-28 2012-06-12 Fiberlink Communications Corporation Client-side network access policies and management applications
US20050022012A1 (en) * 2001-09-28 2005-01-27 Derek Bluestone Client-side network access polices and management applications
US8942429B2 (en) * 2003-04-29 2015-01-27 Assa Abloy Ab Method for improving false acceptance rate discrimination for biometric authentication systems
US20110205020A1 (en) * 2003-04-29 2011-08-25 Le Saint Eric F Method for improving false acceptance rate discrimination for biometric authentication systems
US7395341B2 (en) 2003-08-15 2008-07-01 Fiberlink Communications Corporation System, method, apparatus and computer program product for facilitating digital communications
US20050081045A1 (en) * 2003-08-15 2005-04-14 Fiberlink Communications Corporation System, method, apparatus and computer program product for facilitating digital communications
US20050086510A1 (en) * 2003-08-15 2005-04-21 Fiberlink Communications Corporation System, method, apparatus and computer program product for facilitating digital communications
US20050086492A1 (en) * 2003-08-15 2005-04-21 Fiberlink Communications Corporation System, method, apparatus and computer program product for facilitating digital communications
US7636844B2 (en) * 2003-11-17 2009-12-22 Intel Corporation Method and system to provide a trusted channel within a computer system for a SIM device
US20130326581A1 (en) * 2003-12-18 2013-12-05 Casey S. Bahr Client Side Security Management for an Operations, Administrations and Maintenance System for Wireless Clients
EP1551149A2 (en) 2003-12-22 2005-07-06 Activcard Inc. Universal secure messaging for remote security tokens
US20050138421A1 (en) * 2003-12-23 2005-06-23 Fedronic Dominique L.J. Server mediated security token access
US20050188224A1 (en) * 2004-01-05 2005-08-25 Betts-Lacroix Jonathan Connector including electronic device
WO2005069530A1 (en) * 2004-01-05 2005-07-28 Oqo Incorporated Connector including electronic device
US7725589B2 (en) 2004-08-16 2010-05-25 Fiberlink Communications Corporation System, method, apparatus, and computer program product for facilitating digital communications
US20080222696A1 (en) * 2004-08-16 2008-09-11 Fiberlink Communications Corporation System, Method, Apparatus, and Computer Program Product for Facilitating Digital Communications
US8014570B2 (en) 2004-11-16 2011-09-06 Activcard, Inc. Method for improving false acceptance rate discriminating for biometric authentication systems
US20060168653A1 (en) * 2005-01-27 2006-07-27 Contrera Suzanne H Personal network security token
US20120124643A1 (en) * 2005-02-23 2012-05-17 Mark Moriconi Systems and Methods for Analyzing Application Security Policies
US9077724B2 (en) * 2005-02-23 2015-07-07 Mark Moriconi Systems and methods for analyzing application security policies
US9678727B1 (en) * 2005-03-15 2017-06-13 Open Invention Network, Llc Code generator tool for building software applications with reusable components
US10235142B1 (en) * 2005-03-15 2019-03-19 Open Invention Network Llc Code generator tool for building software applications with reusable components
US20070055752A1 (en) * 2005-09-08 2007-03-08 Fiberlink Dynamic network connection based on compliance
US8955038B2 (en) 2005-12-21 2015-02-10 Fiberlink Communications Corporation Methods and systems for controlling access to computing resources based on known security vulnerabilities
US20070143827A1 (en) * 2005-12-21 2007-06-21 Fiberlink Methods and systems for intelligently controlling access to computing resources
US20070143851A1 (en) * 2005-12-21 2007-06-21 Fiberlink Method and systems for controlling access to computing resources based on known security vulnerabilities
US9923918B2 (en) 2005-12-21 2018-03-20 International Business Machines Corporation Methods and systems for controlling access to computing resources based on known security vulnerabilities
US9608997B2 (en) 2005-12-21 2017-03-28 International Business Machines Corporation Methods and systems for controlling access to computing resources based on known security vulnerabilities
US20080066159A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Controlling the Delegation of Rights
US8095969B2 (en) 2006-09-08 2012-01-10 Microsoft Corporation Security assertion revocation
US8060931B2 (en) * 2006-09-08 2011-11-15 Microsoft Corporation Security authorization queries
US20080066175A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Security Authorization Queries
US8201215B2 (en) 2006-09-08 2012-06-12 Microsoft Corporation Controlling the delegation of rights
US8225378B2 (en) 2006-09-08 2012-07-17 Microsoft Corporation Auditing authorization decisions
US20080065899A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Variable Expressions in Security Assertions
US8584230B2 (en) 2006-09-08 2013-11-12 Microsoft Corporation Security authorization queries
US20080066170A1 (en) * 2006-09-08 2008-03-13 Microsoft Corporation Security Assertion Revocation
US9282121B2 (en) 2006-09-11 2016-03-08 Microsoft Technology Licensing, Llc Security language translations with logic resolution
US20080066147A1 (en) * 2006-09-11 2008-03-13 Microsoft Corporation Composable Security Policies
US8938783B2 (en) 2006-09-11 2015-01-20 Microsoft Corporation Security language expressions for logic resolution
US8656503B2 (en) 2006-09-11 2014-02-18 Microsoft Corporation Security language translations with logic resolution
US20080066171A1 (en) * 2006-09-11 2008-03-13 Microsoft Corporation Security Language Translations with Logic Resolution
US20080066160A1 (en) * 2006-09-11 2008-03-13 Microsoft Corporation Security Language Expressions for Logic Resolution
US20090222879A1 (en) * 2008-03-03 2009-09-03 Microsoft Corporation Super policy in information protection systems
US20090260071A1 (en) * 2008-04-14 2009-10-15 Microsoft Corporation Smart module provisioning of local network devices
US7690032B1 (en) * 2009-05-22 2010-03-30 Daon Holdings Limited Method and system for confirming the identity of a user
US9003544B2 (en) * 2011-07-26 2015-04-07 Kaspersky Lab Zao Efficient securing of data on mobile devices
US20130031595A1 (en) * 2011-07-26 2013-01-31 Nevstruev Sergey V Efficient securing of data on mobile devices
US9369493B2 (en) * 2011-08-09 2016-06-14 CloudPassage, Inc. Systems and methods for implementing security
US20150288722A1 (en) * 2011-08-09 2015-10-08 CloudPassage, Inc. Systems and methods for implementing security
US10027650B2 (en) 2011-08-09 2018-07-17 CloudPassage, Inc. Systems and methods for implementing security
US10454916B2 (en) 2011-08-09 2019-10-22 CloudPassage, Inc. Systems and methods for implementing security
US10601807B2 (en) 2011-08-09 2020-03-24 CloudPassage, Inc. Systems and methods for providing container security
US9867043B2 (en) * 2012-08-28 2018-01-09 Visa International Service Association Secure device service enrollment
US20140066015A1 (en) * 2012-08-28 2014-03-06 Selim Aissi Secure device service enrollment

Also Published As

Publication number Publication date
EP1473618A2 (en) 2004-11-03
US20140359301A1 (en) 2014-12-04
US7921298B2 (en) 2011-04-05
US20170195368A1 (en) 2017-07-06
US20120036551A1 (en) 2012-02-09
US8732478B2 (en) 2014-05-20
EP1473618B1 (en) 2017-03-22
US20090025074A1 (en) 2009-01-22
US9576111B2 (en) 2017-02-21
EP1473618A3 (en) 2005-03-16

Similar Documents

Publication Publication Date Title
US7921298B2 (en) Uniform modular framework for a host computer system
US20080022381A1 (en) Uniform framework for security tokens
US7669235B2 (en) Secure domain join for computing devices
US8560857B2 (en) Information processing apparatus, a server apparatus, a method of an information processing apparatus, a method of a server apparatus, and an apparatus executable program
US8909940B2 (en) Extensible pre-boot authentication
RU2342693C2 (en) Method and device for presenting gifts on data transfer network
RU2506632C2 (en) Information processing device, driving method therefor and computer-readable data medium
EP1549021A1 (en) Access controlled by security token and mediated by sever
US20070204166A1 (en) Trusted host platform
EP1645984A1 (en) Information processing apparatus, information processing method, and program
US7357313B2 (en) Information processor-based service providing system and method
EP1318488A2 (en) IC card with capability of having plurality of card managers installed
US20090138699A1 (en) Software module management device and program
EP2037385B1 (en) Information processing apparatus, authentication control method, and authentication control program
US6816965B1 (en) Method and system for a policy enforcing module
US9253173B2 (en) System and method for supporting security administration
CN101196974A (en) Method and system for auto-configuratoin of software application program
US9838379B1 (en) Security tiering in a mobile communication device application framework
US20040123138A1 (en) Uniform security token authentication, authorization and accounting framework
KR20130006257A (en) Method for managing key of embedded sim, embedded sim and recording medium for the same
JP4523196B2 (en) Management server for exchanging data with IC card and method executed by management server
CN116521296A (en) Multi-system application integration method and platform
JP2000207357A (en) Security-mounted agent system
Magic Remote Method Invocation for Android Platform

Legal Events

Date Code Title Description
AS Assignment

Owner name: ACTIVCARD IRELAND, LIMITED, IRELAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LE SAINT, ERIC;BOYER, JOHN;REEL/FRAME:014249/0801

Effective date: 20030605

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: ACTIVCARD IRELAND, LIMITED, IRELAND

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ACTIVIDENTITY, INC.;REEL/FRAME:029444/0562

Effective date: 20120726

AS Assignment

Owner name: ACTIVIDENTITY, INC., CALIFORNIA

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNOR AND ASSIGNEE NAMES PREVIOUSLY RECORDED ON REEL 029444 FRAME 0562. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ACTIVCARD IRELAND LIMITED;REEL/FRAME:029565/0770

Effective date: 20120726