Patent Grant
H2270
This application claims priority to: U.S. Provisional App. No. 61/349,396 filed May 28, 2010; U.S. Provisional App. No. 61/261,634 filed Nov. 16, 2009; U.S. Provisional App. No. 61/256,192 filed Oct. 29, 2009; and U.S. Provisional App. No. 61/224,379 filed Jul. 9, 2009, all of which are incorporated herein by reference.
This application is related to the field of secure communications and, more particularly, to cryptographic key management and the establishment of a protected communication channel between entities.
Secure communications technology, such as GlobalPlatform secure channel, IpSec, SSL/TLs etc., is available to allow two communicating systems equipped with cryptographic modules to exchange information with confidentiality and integrity. These methods rely generally on a first shared secret key establishment step and a second key derivation step whereby session keys are derived from the shared secret.
In the case of secure contact or contactless transactions between a personal device equipped with a secure Integrated Circuit Chip (ICC), such as a smart card or a mobile phone, and an access point, such as a contactless or Near Field Communication (NFC) door reader, sensitive identification information or secrets may be exchanged. However, increased security in protecting the access and exchange of the confidential information often results in reduced performance/increased user wait times. Traditionally, for contactless solutions with rapid transactions, performance has been favored over security. Such systems offer no protection or weak protection for the credential data that is communicated. A suitable comprise between performance and security is required.
In an open domain or multi-domain environment, the communicating systems may be mutually authenticated, be equipped with totally independent PKI key pairs that are either generated at the time of the transaction or generated or imported in advance. The public keys may be certified with independent but mutually trusted authorities so the communicating systems hosting the private key can be authenticated. Using zero, one or more key pairs on each side, a shared secret establishment process first derives a shared secret from a public key infrastructure (PKI) key agreement method such as Diffie-Heilman and/or Elliptic Curve Diffle Heilman (ECDH). A key transport method, such as RSA key transport, may also be used. PKI key agreement techniques are varied and extensively described, for example, in IpSec/IKE (Internet Key Exchange), the National Institute of Standards and Technology (NIST) Special Publication 800-56A entitled “Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography” by Elaine Barker et al. (revised, March 2007), which is incorporated herein by reference, and/or NIST Special Publication 800-56B “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography” by Elaine Barker et al. (August 2009), which is incorporated herein by reference. The session keys used to protect the transported data are generally derived from the resulting shared secret as a second step, which includes a key derivation and a mutual authentication step. An example of session key derivation function is provided in NIST SP 800-56A and/or NIST SP 800-108, “Recommendation for Key Derivation Using Pseudorandom Functions,” which is incorporated herein by reference.
A concern of such key establishment techniques is that the time for executing the cryptography of the first key establishment step inside the ICC of a personal security device with low computing power is prohibitive. This prevents the deployment of such technology with the desired key length or security protection level. Another concern is that the key establishment step involves sending multiple requests and response pairs to the ICC. These multiple requests may add overhead and latency to the transaction, particularly with remote systems. Also with multiple requests, the ICC includes additional functionality and resources to maintain the intermediate states between requests. In addition, in many instances, it may be desirable to efficiently authenticate a user/device without identifying the user/device to an entity that is not part of the transaction.
Accordingly, it would be desirable to provide a system that facilitates the widespread and efficient use of PKI key agreement techniques, and/or other similar key establishment techniques, in a way that still provides for appropriate security, limits the number of requests and responses and including the ability to authenticate without identifying a transaction participant to non-participants.
According to the system described herein, a method for authenticating a device includes generating authentication information at a host. A request may be sent to authenticate a device to the host, wherein the request includes at least a portion of the authentication information. A response to the request may be received at the host in which the response includes encrypted information and an anonymous identifier of the device that does not provide readable identification information to an entity other than the host. The device may be authenticated using the encrypted information and the anonymous identifier. The method may receiving only one response with the encrypted information and the anonymous identifier. The anonymous identifier and/or the encrypted information may be a one-time use identifier of the device. The request sent from the host to the device may be unencrypted. A portion of the encrypted information in the response may be encrypted using a portion of the authentication information. The encrypted information sent from the device to the host may be decipherable by only the host. Each of the host and the device may use a shared secret which may be one of: established by the device before sending back the response to the request to the host and established in advance before sending authentication information from the host. A portion of the encrypted information in the response may be encrypted using a key derived from the shared secret. The method may further include retrieving stored information corresponding to the authenticating of the device that is stored on at least one of: the device and the host. The method may further include deactivating the host, wherein reactivation of the host is performed using an administrator device. The device may include at least one of: a smart card and a mobile phone having a secure element. The host may be an access point of an access controlled system and, upon presentation of the device at the access point, the access point authenticates the device and establishes a shared secret with the device to obtain an access credential, and wherein the access point relies on the access control system to validate the access credential for authorization and granting access.
According further to the system described herein, a non-transitory computer readable medium stores computer software for authenticating a device. The computer software may include executable code that generates authentication information at a host. Executable code may be provided that sends a request to authenticate a device to the host, wherein the request includes at least a portion of the authentication information. Executable code may be provided that receives a response to the request from the device, wherein the response includes encrypted information and an anonymous identifier of the device that does not provide readable identification information to an entity other than the. Executable code may be provided that authenticates the device using the encrypted information and the anonymous identifier. The anonymous identifier and/or the encrypted information may be a one-time use identifier of the device. The request sent from the host to the device may be unencrypted. A portion of the encrypted information in the response may be encrypted using a portion of the authentication information. Each of the host and the device may use a shared secret which may be one of: established by the device before sending back the response to the request to the host and established in advance before sending authentication information from the host. A portion of the encrypted information in the response may be encrypted using a key derived from the shared secret. Executable code may be provided that deciphers the encrypted information and processes the anonymous identifier. Executable code may be provided that retrieves stored information corresponding to the authenticating of the device that is stored on the host. The host may be an access point of an access controlled system and upon presentation of the device at the access point, the access point may authenticate the device and establish a shared secret with the device to obtain an access credential, and the access point may rely on the access control system to validate the access credential for authorization and granting access.
According further to the system described herein, a method for authenticating a device includes receiving, at the device, a request to authenticate the device. The method further includes generating a response to the request. The method further includes sending the response to a host, where the response includes encrypted information and an anonymous identifier of the device that does not provide readable identification information to an entity other than the host, and where the response authenticates the device to the host. The anonymous identifier and/or the encrypted information may be a one-time use identifier of the device. The device may generate the encrypted information using information provided in the request and/or a key derived from a shared secret of the device and the host. The method may further include authenticating the host at the device. The method may further include retrieving stored information corresponding to the authenticating of the host that is stored on the device. The host may be an access point of an access controlled system and the device may request access to an access controlled terminal.
According further to the system described herein, a non-transitory computer readable medium stores computer software for authenticating a device. The computer software may include executable code that receives a request to authenticate a device. Executable code may be provided that generates a response to the request. Executable code may be provided that sends the response to the host wherein the response includes encrypted information and an anonymous identifier of the device that does not provide readable identification information to an entity other than the host and in which the response authenticates the device to the host. The anonymous identifier and/or the encrypted information may be a one-time use identifier of the device. The encrypted information may be generated using at least one of: information provided in the request and a key derived from a shared secret of the device and the host. Executable code may be provided that authenticates the host to the device. Executable code may be provided that retrieves stored information corresponding to the authenticating of the host that is stored on the device. The host may be an access point of an access controlled system and upon presentation of the device at the access point, the access point may authenticate the device and establish a shared secret with the device to obtain an access credential, and the access point may rely on the access control system to validate the access credential for authorization and granting access.
According further to the system described herein, a system for authenticating a device includes a host and a device that authenticates to the host. The host may include a non-transitory computer readable medium that includes: executable code that generates authentication information at the host; executable code that sends a request to authenticate the device, where the request includes at least a portion of the authentication information; executable code that receives a response to the request from the device, where the response includes encrypted information and an anonymous identifier of the device that does not provide readable identification information to an entity other than the host; and executable code that authenticates the device using the encrypted information and the anonymous identifier. The device may include a non-transitory computer readable that includes: executable code that receives the request; executable code that generates the response; and executable code that sends the response to the host, where the response authenticates the device to the host. The host may include a client application and a secure access module. The device may include at least one of: a smart card and a mobile phone including a secure element. The request sent from the host to the device may be unencrypted, and a portion of the encrypted information in the response may be encrypted using the portion of the authentication information. Each of the host and the device may use a shared secret which may be one of: established by the device before sending back the response to the request to the host and established in advance before sending authentication information from the host. A portion of the encrypted information in the response may be encrypted using a key derived from the shared secret. The host may be an access point of an access controlled system and upon presentation of the device at the access point, the access point may authenticate the device and establish a shared secret with the device to obtain an access credential, and the access point may rely on the access control system to validate the access credential for authorization and granting access.
Embodiments of the system described herein are explained with reference to the several figures of the drawings, which are briefly described as follows.
The system described herein provides an open protocol for access control identification and ticketing with privacy (hereinafter “OPACITY”) and is generally applicable for uses involving authentication and key establishment with privacy. According to various embodiments, OPACITY may provide a suite of authentication and key agreement protocols for contact or contactless interfaces that can secure physical access, logical access, transportation applications and/or implement other applications requiring secure communications.
An ICC 40, such provided on a smart card, mobile phone and/or other personal device, communicates with the SAM 30 via a contact or contactless interface 1. Operation of the protocols of the OPACITY system 100 provide secure contact or contactless communication between the ICC 40 and the SAM 30. For example, use of the system described herein may provide full protection from attacks including skimming, sniffing and man-in-the middle attacks and may provide forward secrecy, as further discussed elsewhere herein. An OPACITY protocol according to the system described herein may advantageously use a single command for robust transactions and full privacy in the response. Note that the host may be a computing system such as a terminal or remote server, and/or any other unit or collection of units capable of establishing a logical communication channel with the device (e.g., the ICC 40) as discussed herein.
The OPACITY system 100 may include a protocol suite including protocols for operations of the SAM 30, ICC 40 and/or client application 20 that may operate in compliance with NIST cryptographic mandates, including NIST SP 800-56A or 800-56B (as noted above and which is incorporated herein by reference), NIST SP 800-57 Part 1, entitled “Recommendation for Key Management” by Elaine Barker et al. (revised, March 2007), which is incorporated herein by reference, and Federal Information Processing Standards (FIPS) 140-2, entitled “Security Requirements for Cryptographic Modules,” May 25, 2001, with change notice 12-03-2002, which is incorporated herein by reference. The protocol suite may further include the ability to fulfill NSA recommendations on the choice of cryptography (SUITE-B). It should be noted that other appropriate standards may also be utilized in connection with the system described herein, as would be understood by one or ordinary skill in the art.
The OPACITY system 100, and protocols therefor as further discussed elsewhere herein, may offer multiple advantages in security, fast and robust operation, and integration. In connection with security, the system 100 may prevent identity leaks and privacy protection may be maximum, including that both Personally Identifiable Information and Unique Identifiers cannot be accessed by unauthorized parties. The system 100 may provide forward secrecy, including that previously transmitted secrets cannot be revealed in the clear even if the static host or ICC authentication key has been compromised. The system 100 may provide mutual authentication in which host authentication to the card is either implicit or explicit. In implicit mode, only the host with a trusted private key can decrypt the card output, so the card receives assurance that only an authentic and authorized host can use the card output. In explicit mode the host applies secure messaging on card commands, so the card receives assurance that an authentic and authorized host has effectively received the card output. The system 100 may support full secure messaging for application data or key exchange. The system 100 may be robust to Man-In-The-Middle attacks with proof of possession of both private and derived session keys. The system 100 may provide protection against theft with activation control mechanisms. The system may provide key revocation support with a configurable trusted public key list.
In connection with fast and robust operation, the system 100 may have zero or reduced overhead and in which there is one short command and one short response. The system 100 may be robust to power off in any situation and have the capability to resume. Extremely fast and scalable session key establishment may be provided when the protocol is executed a second time between a card and a host.
In connection with integration, integration specifications for both the SAM 30 and ICC 40 interfaces may be provided for the system described herein. From the client application perspective, the integration may be simple with the use of a single ICC command with a SAM-generated public key and identification data. An ICC response is directly forwarded to the host SAM 30 for processing. The SAM 30 returns authenticated ICC credentials. Session keys (e.g., symmetric session keys) are established on both sides. The system 100 may provide simple PKI key management and limited infrastructure implementation costs.
The protocol suites of the OPACITY system 100 may provide authentication, such as PM authentication, of a ICC of a smart card and/or mobile phone with a secure element 40′ that may be presented to one or more hosts 10′ . The hosts 10′ may include one or more hosts that are part of and/or otherwise incorporated into a door or door controller for controlling physical access and into desktops, laptops and/or kiosks for controlling logical access. Use of secure messaging provides an end-to-end protected path for document or transaction decryption and signatures using the secure element or smart card. The end-to-end secure messaging may provide for the transport of PIN or biometrics or physical access control system (PACS) credentials via contactless communication. The system described herein may also be used in connection with PM-based authentication and ticketing for transit applications. The system described herein may further be used to provide end-to-end post issuance management of the smart card or secure element in a contact or contactless environment.
In various embodiments, the protocol suite of the system described herein may include modes of different strengths that may be applied to various use cases or eco-systems (see FIG. 2). A first mode of the OPACITY protocol may be an OPACITY Forward Secrecy mode (OPACITY-FS) that may be optimized for contact or contactless authentication transactions such as for access to sensitive facilities but also when it is necessary that the identity of the cardholder never be compromised. An external third-party without privilege should not be able to associate the identity of the card holder to a transaction made with the card. Under the OPACITY-FS mode, the protocol of the system described herein also protects end-to-end sensitive information that may be transported to or from the card and which remains valuable after the transaction or the session is completed. For instances in key management use cases, information communicated may remain critical and need to be protected for a long period of time.
A second mode of the OPACITY protocol may include an OPACITY Zero Key Management (ZKM) mode (OPACITY-ZKM) that may be a lightweight option best suited to protect contact or contactless communications when terminals are not capable of supporting a security module, operating secrets and the corresponding key life cycle management, such as in legacy Physical Access Control or Logical Access Control deployment infrastructures. The OPACITY ZKM mode may have similar security properties as the ActivIdentity SMA (secure messaging anonymous) protocol suite. For further discussion of the standards for supporting zero key management mode, reference is made to the standard ISO 24727-3 “EC Key Agreement with ICC Authentication, Appendix A-1” which is incorporated herein by reference.
The OPACITY-FS mode provides for operation with advantageous privacy, authentication and forward secrecy features. The OPACITY protocol may not divulge any identifier that may be associated to a particular ICC or card holder during an OPACITY session and does not divulge any data that allows the correlation of two protocol executions with the same ICC during the OPACITY session. In an embodiment, the OPACITY protocol may explicitly authenticate the ICC 40 to the host using FIPS-approved BC-based authentication protocols described in NIST SP 800-56A. The ICC 40 may deliver the CVC 42 to the host 10/SAM 30, which allows the host 10 to verify the binding between the ICC identifier and the ICC BC private key 41. The ICC identifier may be chosen to be the same value registered in the access control system (for instance, GUID or FSC-N). The OPACITY protocol may either implicitly or explicitly authenticate the host to the ICC, for example, using FIPS-approved BC-based authentication protocols described in NIST SP 800-56A. Implicit authentication means that the ICC validates the CVC but does not expect a response from the host showing that the host actually owns the private key corresponding to that CVC. However, only an authentic host will be able to decipher the ICC response. Explicit authentication means that the ICC actually receives at least an additional command from the host that proves to the ICC that the host owning the private key is present. Forward secrecy provides assurance that the encrypted data that is transferred cannot be decrypted after the communication has ended and the session keys and the ephemeral EC key pairs are zeroized (destroyed). This mode is particularly useful when OPACITY is used for secure messaging (SM) encryption. Specifically, with forward secrecy, the SM session keys cannot be reproduced even if both the original persistent key material and the original communication data has been compromised or captured. In the OPACITY case, the original persistent key material may correspond to the private terminal authentication keys.
The protocol of the system described herein may be configured for use with multiple cipher suites. TABLE 1 shows configurations for three cipher suites: non-government cipher suite; enterprise or government unclassified cipher suite, and government classified cipher suite using encryption algorithms and standards such as: two key Triple Data Encryption Algorithm (2TDEA), Advanced Encryption Standard (AES) (e.g., AES 128/256), Elliptic Curve Diffie-Heilman (ECDH) (e.g., ECDH 160/256/384), Elliptic Curve Digital Signature Algorithm (ECDSA) (e.g., ECDSA 160/256/384) and Secure Hash Algorithm (SHA) (e.g., SHA 1/256/384). The system described herein may further be used with other suitable cipher suites and encryption standards beyond those described in TABLE 1.
It should be noted that the OPACITY system may provide for the resuming of interrupted communications between the ICC 40 and the host 10, such as when the smart card (and/or mobile phone with secure element) leaves the communications field prematurely and then returns. The host 10 may issue a new request as if a new card is presented, e.g., with a new nonce or ephemeral public key. When the smart card recognizes that the host certificate is identical to the one of the previous failed connection, the ICC 40 can resume the processing at the point where it failed.
It should be noted that the OPACITY protocol workflow may be advantageously simple from an integrator's perspective. From the integrator's perspective, the client application 20 calls the SAM 30 to generate an ephemeral EC key pair, sends an authentication command to the ICC 40 including the public ephemeral key and the SAM ECC (see, e.g., FIG. 6). Then, the client application 20 forwards directly the authentication response of the ICC 40 as a second authentication command to the SAM 30. If successful, then session keys are established on both sides. The client application 20 builds application protocol data unit (APDU) commands, calls the SAM 30 to wrap (encapsulate) the APDU commands, and then sends the wrapped commands to the ICC 40. In an embodiment, the APDU interface may be an ISO 7816-4 card edge interface that supports the OPACITY protocol and may be desirable for interoperability.
It should be noted that the protocol according to the system described herein may protect and authenticate data transported to and from the ICC in any environment. It may not be required that PKI authorization or revocation be enforced on behalf of access control systems using the protocol. In various embodiments, it may be assumed that the OPACITY keys are authentication keys generated on the ICC; these keys being never shared. However the ICCs may be stolen or operated in unauthorized contexts. Accordingly, the life cycle of the OPACITY authentication keys may be managed via the ICC post-issuance system in coordination with the life of the card. In particular, the ICC management system may be capable of regenerating the OPACITY static key pair, installing a corresponding CVC, and updating the list of authorized root domain public key. In case of theft, the security of the OPACITY-based system may rely on the prompt declaration of loss or theft to the Issuer, service provider or local IT. This may result in a) the actual revocation of the application credentials and associated rights (CHUID, PIV Auth Cert, etc.), which are not the OPACITY credentials, and b) may result in updates the corresponding access control backend. On the other hand the revocation of OPACITY CVCs and the use of CRLs or blacklist may not be required. Furthermore, the list of valid domain public keys may be regularly updated to phase out revoked cards.
The Administrator ICC 150 may be a smart card and/or a secure element of a mobile phone which communicates to the SAM 130 via the client application 120 as a regular OPACITY-enabled card. The SAM 130 stores the Administrator ICC root domain public key 151′ and the ICC root domain public key 141′ of the user ICC 140 requesting access. The Administrator ICC 150 may also be a secure element attached to an online connected service, allowing real-time control of SAMs. If the SAM 130 is in a deactivated state, user access is not permitted to the host terminal 110. A deactivated SAM requires a successful OPACITY transaction with the Administrator ICC 150 prior to allow any other OPACITY transaction with another ICC 140. To deactivate a SAM, the SAM 130 may be: powered off then on; reset; the SAM application may be deselected; and/or an internal OPACITY transaction counter may reach a maximum, among other appropriate deactivation techniques. The counter may be reset upon activation.
It should be noted that key agreement, derivation and confirmation functions used in connection with the system described herein may comply with the standards set forth in NIST SP 800-56A, as further discussed elsewhere herein. Key establishment prerequisites may be executed on both the host and ICC sides prior to executing the protocol according to the system described herein. Each side may have authentic copies of the same set of domain parameters and obtain assurance of the validity of the parameters. Other appropriate key derivation standards may also be used in connection with the system described herein (see, e.g., NIST SP 800-108).
For the initial state of a host, the protocol according to the system described herein may initially be enabled on the host side. A client application executes on the host (with a host identifier IDsH) that is equipped with a SAM (and/or HSM or TPM etc.) to implement the cryptographic functions and to communicate with a smart card or secure element (identifier IDsICC). The client application may have access to a unique static private EC authentication key (dsH) and the conesponding CVC (CH) may include the host identifier (IDsH) and the matching public key (QsH). The host may execute all key establishment preparations prior to launching the protocol according to the system described herein. The client application may have access to a registry of Host-ICC pairing records needed to support the persistent binding capability as further discussed elsewhere herein. Each record includes a ICC record identifier (OTIDICC), and a one-time shared secret (Z) valid for the next communication. The registry may be accessed with the ICC record identifier (OTIPICC). If the ICC authentication settings are variable, the client application may ensure that the ICC authentication method and parameters are set. The client application may have access to the root ICC public key (QrootICC) to validate ICC authentication certificates (CICC) and card authentication public key (QsICC).
For the initial state of an ICC, the protocol according to the system described herein may initially be enabled on the ICC side. A certificate root public key (QrootH), for on card verification of the client application certificate, may be determined with a client certificate issuer identification number. The ICC may have access to a registry of host pairing records needed for the persistent binding capability. Each record may include: the host identifier and index (IDsH), the one-time ICC identifier that was used during the last session (OTIDICC), the one- time shared secret valid only for the next communication (Z). The card application may have access to a card authentication key (dsICC) and a card authentication certificate (CICC) including the card authentication public key (QsICC). The ICC may execute all key establishment preparations prior to launching the protocol according to the system described herein.
After the step 212, processing proceeds to a step 214 where the client application forwards the ICC response to the SAM to authenticate the ICC. Only an authentic SAM can decipher the ICC response since the ephemeral private key (deH) is retained by the SAM. As further discussed elsewhere herein, the ICC response may include an ICC record identifier (OTIDICC) that may be an anonymous, one-time identifier of the ICC along with other encrypted information. In an embodiment herein, the ICC response may be encrypted in a way that so that the response is readable by the SAM/host but not by other entities (i.e., that are not part of the transaction). In addition, each time the ICC responds, the encrypted information may be different and may appear random to an entity other than the SAM/host. Thus, readable identification information is provided to the SAM/host, but not to other entities outside the transaction. After the step 214, processing proceeds to a step 216 where the client application waits to receive a response from the SAM. After the step 216, processing proceeds to a step 218 where the client application receives information from the SAM. Alter the step 218, processing proceeds to a test step 220 wherein the client application determines whether the information from the indicates authenticated communication may proceed with the ICC.
If at the test step 220 it is determined that communication may not proceed, e.g., the information from the SAM indicates an authorization error, then processing proceeds to a step 222 where access denial processing is performed. If, at the test step 220, the information indicates that authenticated communication may proceed, for example, by including an identifier of the ICC (ICCcred, such as a GUID), then processing proceeds to a step 224 where the client application coordinates the exchange of secure message information between the SAM and the ICC by coordinating the exchange of session-key protected commands. The client application may use the SAM to session protect the message (e.g., APDU wrapped) that are exchanged with the ICC. After the step 224, processing proceeds to a test step 226 where it is determined whether protected communication is to continue. If communication is to continue, then processing proceeds back to the step 224. If, at the test step 226, it is determined that processing is not to continue, then processing proceeds to a step 228 where the client application performs processing in connection with closing the communication channel with the ICC. After the step 228, processing is complete.
If, at the test step 206, it is determined that persistent binding processing is to occur, then processing proceeds to a step 240 where the client application challenges the ICC to authenticate by sending an authentication request to the ICC that may include the host certificate (CH), the host ephemeral public key (QeH) and information (CBH) that may indicate persistent binding processing. After the step 240, processing proceeds to a step 242 where the client application waits to receive a response from the ICC. After the step 242, processing proceeds to a step 244 where the client application receives a response from the ICC. As with the steps 208, 212 discussed above, the authentication challenge to the ICC may be unencrypted and the response from the ICC may be encrypted using the host ephemeral public key.
After the step 244, processing proceeds to a test step 246 where the client application determines whether persistent binding processing is to be used for the ICC. If not, then processing proceeds to the step 208, discussed above. If, at the test step 246, it is determined that persistent binding processing is to be used, then processing proceeds to a step 248 where the client application sends the ICC response and persistent binding information to the SAM to authenticate the ICC. In various embodiments, as further discussed elsewhere herein, in connection with persistent binding, and depending on the number of records involved, the information sent to the SAM may include the OTIDICC along with a flag or bit for the SAM to search a persistent binding table (fewer records) and/or the client application may sent persistent binding address information that may be used by the SAM to search a persistent binding table instead of searching the OTIDICC. After the step 248, processing proceeds to the step 216.
After the step 310, processing proceeds to a test step 312 where the SAM determines whether the ICC is authenticated. The SAM may authenticate the ICC by verifying that it also possesses one or more session keys as determined by the SAM in step 310, for example, by applying an encryption-based message authentication code (MAC) algorithm, such as an AES128 algorithm according to the NIST SP 800-38 B standards, to cryptogram information received from the ICC in the ICC response. If, at the test step 312, it is determined that the ICC is not authenticated, then processing proceeds to a step 314 where error processing occurs that may include sending an authorization, error message to the client application. If, at the test step 312, it is determined that the ICC is authenticated, then processing proceeds to a step 316 where the SAM sends the identifier of the ICC and/or other appropriate information to the client application indicating authentication of the ICC.
After the step 316, processing proceeds to a step 318 where the SAM waits to receive messages from the client application that are to be session key protected (e.g., APDU wrapped). After the step 318, processing proceeds to a step 320 where the SAM receives a message from the client application that is to be protected. After the step 320, processing proceeds to a step 322 where the SAM session key-protects the message. After the step 322, processing proceeds to a step 324 where the SAM returns the protected message to the client application. After the step 324, processing proceeds to a test step 326 where it is determined whether communication is to continue. If communication is to continue, then processing proceeds back to the step 318. If, at the test step 326, it is determined that communication is not to continue, then processing proceeds to a step 328 where end communication processing is performed. After the step 328, processing is complete.
After the step 366, processing proceeds to a step 368 where the shared secret (Z) is determined, for example by a concatenation process of Z1 and EC_DH(deH, QsICC) according to NIST SP 800-56A. After the step 368, processing proceeds to a step 370 where information no longer needed, such as Z1 and K1, are destroyed. After the step 370, processing proceeds to a step 372 where the session keys are determined as well as a shared secret and a one-time identifier for the next session based on applying the key derivation function (KDF) using Z, IDsH, OTIDICC, QeH among other appropriate information (such as an ICC nonce NICC, if applicable). It is also noted that if persistent binding is being used, the information for the next session may be registered in the persistent binding table of the SAM. After the step 372, processing proceeds to a step 374 where Z, deH and QeH and/or other unneeded information may be destroyed. It may also be noted that other steps consistent with appropriate cryptographic standards, for example NIST SP 800-56A, may be taken, including the destroying of information. After the step 374, processing is complete.
If, at the test step 352, it is determined that persistent binding processing is to proceed, then at a step 380 the SAM determines the shared secret (Z) and ICCcred and/or other appropriate information using the persistent binding registry. After the step 380, processing proceeds to the step 372, discussed above.
After the step 406, processing proceeds to a step 408 where the ICC determines secure communication information including the one-time anonymous identifier of the ICC (OTIDICC), sessions keys and other information for communicating with the SAM via the client application and/or other encrypted information, as further discussed elsewhere herein. After the step 408, processing proceeds to a step 410 where the ICC sends the one-time identifier (OTICICC) and other encrypted information to the client application. After the step 410, processing proceeds to a step 412 where the ICC waits to receive session protected commands from the client application. After the step 412, processing proceeds to a step 414 where the ICC receives and executes a session key-protected message. After the step 414 processing proceeds to a test step 416 where is determined whether communication is to continue. If communication is to continue, then processing proceeds back to the step 412. If, at the test step 416, it is determined that communication is not to continue, then processing proceeds to a step 418 where communication end processing is performed. After the step 418, processing is complete.
After the step 460, processing proceeds to a step 462 where the shared secret (Z) is determined by a concatenation process on Z1 and EC_DH(dsICC, QeH), for example according to NIST SP 800-56A. After the step 462, processing proceeds to a step 464 where Z1 and K1 are destroyed. After the step 464, processing proceeds to a step 466 where the session keys are computed as well as a shared secret and a one-time identifier for the next session based on applying the key derivation function (KDF) using Z, IDsH, OTIDICC, QeH among other appropriate information (such as an ICC nonce NICC, if applicable).
If, at the step 452, the host identifier is found in the persistent binding registry, then processing proceeds to a step 480 to use the registry to recover the previously stored shared secret. At the step 480, using IDsH as an index, the ICC obtains Z and OTICICC from the registry. After the step 480, processing proceeds to a step 482 where the ICC generates a secret nonce (NICC) that will be used in the computation of the session keys and information for the next session. After the step 482, processing proceeds to the step 466 discussed above.
After the step 466, processing proceeds to a step 468 where Z, deICC and QeICC are destroyed. After the step 468, processing proceeds to a step 470 where the ICC determines a return cryptogram allowing ICC authentication and showing to the client application that the ICC owns the required one or more session keys. The ICC may determine the cryptogram by applying an encryption-based message authentication code (MAC) algorithm, such as an AES128 based on algorithm according to the NIST SP 800-38B standards, to appropriate information, such as one of the session keys, OTIDICC, IDsH and QeH, among other information. It may also be noted that other steps consistent with appropriate cryptographic standards, for example NIST SP 800-56A, may be taken, including destroying one or more of the session keys. Furthermore, it is also noted that the ICC may store information in order to facilitate future communications with the host, including storing the host identifier and other information in the ICC's persistent binding registry, if applicable. After the step 470 processing is complete.
In connection with OPACITY-ZKM, processing may be similar to that described herein with respect to OPACITY-FS except for authentication and processing requirements concerning the SAM that may be not supported. Accordingly, under the OPACITY-ZKM mode, static terminal keys (except for the root public key) are not required and the mode provides for card authentication but not terminal authentication. OPACITY-ZKM is therefore suitable in environments where terminals are known and trusted. The basic ZKM authentication protocol is an ICC internal authentication protocol and key agreement using EC cryptography. The initiator generates an ephemeral key pair but has no static key pair; the responder has only a static key pair. For appropriate processing standards and operations consistent for use with OPACITY-ZKM, reference is made to ISO 24727-3, the section entitled “EC Key Agreement with ICC Authentication, Appendix A-1”.
Various embodiments discussed herein may be combined with each other in appropriate combinations in connection with the system described herein. Additionally, in some instances, the order of steps in the flowcharts or flow diagrams may be modified, where appropriate. Further, various aspects of the system described herein may be implemented using software, hardware, a combination of software and hardware and/or other computer-implemented modules or devices having the described features and performing the described functions. Software implementations of the system described herein may include executable code that is stored in a computer readable storage medium and executed by one or more processors. The computer readable storage medium may include a computer hard drive, ROM, RAM, flash memory, portable computer storage media such as a CD-ROM, a DVD-ROM, a flash drive and/or other drive with, for example, a universal serial bus (USB) interface, and/or any other appropriate tangible storage medium or computer memory on which executable code may be stored and executed by a processor. The system described herein may be used in connection with any appropriate operating system.
Other embodiments of the invention will be apparent to those skilled in the art from a consideration of the specification or practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with the true scope and spirit of the invention being indicated by the following claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7907935 | Le Saint et al. | Mar 2011 | B2 |
| 20050136964 | Le Saint et al. | Jun 2005 | A1 |
| 20110252466 | Le Saint et al. | Oct 2011 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 61349396 | May 2010 | US | |
| 61261634 | Nov 2009 | US | |
| 61256192 | Oct 2009 | US | |
| 61224379 | Jul 2009 | US |
