US20020112156A1 - System and method for secure smartcard issuance - Google Patents
System and method for secure smartcard issuance Download PDFInfo
- Publication number
- US20020112156A1 US20020112156A1 US09/928,999 US92899901A US2002112156A1 US 20020112156 A1 US20020112156 A1 US 20020112156A1 US 92899901 A US92899901 A US 92899901A US 2002112156 A1 US2002112156 A1 US 2002112156A1
- Authority
- US
- United States
- Prior art keywords
- smartcard
- hardware token
- private key
- token
- security
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
- G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/355—Personalisation of cards for use
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/355—Personalisation of cards for use
- G06Q20/3558—Preliminary personalisation for transfer to user
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3825—Use of electronic signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2119—Authenticating web pages, e.g. with suspicious links
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
Definitions
- One remedy for this problem is to provide each contracting party with a private key for signing transmitted messages with a digital signature.
- the signing party makes available an associated public key that decrypts messages signed with the party's private key, and thus enables a receiving party to confirm the identity of the sender.
- the digital signature is typically created by a smartcard subsystem resident on the signing party's computer.
- This subsystem comprises a hardware token that stores the signing party's private key and any necessary software for executing the digital signature.
- a system and method are disclosed for ensuring the security and integrity of a party's private key stored on a smartcard or other hardware token.
- a set of security requirements are defined for the smartcard that ensure that the card is manufactured and initialized in a secure environment and that it can withstand certain types of cryptographic and other attacks. The requirements further ensure that, at the conclusion of the initiation process, there exists only a single instance of the private key which may never leave the smartcard.
- the unique existence of the private key in the smartcard allows the key to be treated as physical property and differentiates the key from other computer data which can be copied and allowed to proliferate.
- the smartcard and private key are intended for use within the context of a four-corner trust model.
- This four-corner model preferably comprises a buyer, also referred to as the subscribing customer, and a seller, also referred to as the relying customer, who engage in an on-line transaction.
- the four-corner model also preferably comprises a first financial institution, referred to as the issuing participant.
- the issuing participant acts as a certificate authority for the buyer and issues the buyer a hardware token including a private key and a digital certificate signed by the issuing participant.
- the four-corner model also preferably comprises a second financial institution, referred to as the relying participant.
- the seller is a customer of the relying participant and accesses system services via systems maintained by the relying participant.
- the system also includes a root certificate authority that issues digital certificates to the issuing and relying participants.
- the root entity is also preferably responsible for establishing the security requirements for smartcards issued by the issuing participant described above as well as interoperability requirements that ensure the interoperability of the hardware tokens with other system components.
- FIG. 1 is a block diagram of a preferred embodiment of the four-corner model employed by the present system
- FIG. 2 illustrates certain components provided at relying customer 108 and subscribing customer 106 in a preferred embodiment of the present system
- FIG. 3 illustrates the components of a smartcard subsystem in a preferred embodiment of the present system
- FIG. 4A schematically illustrates the components of a smartcard token in a preferred embodiment of the present system
- FIG. 4B schematically illustrates the functional modules of a smartcard token in a preferred embodiment of the present system
- FIG. 5 illustrates a set of security requirements in a preferred embodiment of the present system
- FIG. 6 illustrates the relationship between a set of high-level security objectives and a set of low-level security requirements in a preferred embodiment of the present system
- FIG. 7 illustrates the relationship between a set of security-threat categories and a set of low-level security requirements in a preferred embodiment of the present system
- FIG. 8 illustrates a preferred embodiment of a process for generating an identity private key
- FIG. 9 illustrates a second preferred embodiment of a process for generating an identity private key
- FIG. 10 illustrates a preferred embodiment for using a smartcard to sign a digital message
- FIG. 11 illustrates a preferred embodiment of weights assigned to requirements specified by root entity 110 .
- the present disclosure relates to a system and method for manufacturing and initializing smartcards and other hardware tokens in a manner that ensures the security and integrity of information stored on the card.
- the smartcard is used by a signing party to sign digital messages relating to transactions conducted within the context of a four-corner trust model. A preferred embodiment of this four-corner model is shown in FIG. 1.
- the four-corner model preferably comprises a first institution 102 and a second institution 104 .
- First institution 102 is referred to as the “issuing participant” because it is a participant in the present system and issues smartcards to its customers, as described below.
- Second institution 104 is referred to as the “relying participant” because it is a participant in the present system and its customers rely on representations made by issuing participant 102 and issuing participant 102 's customers, as described below.
- Participants 102 , 104 may preferably be banks or other financial institutions.
- First customer 106 and second customer 108 are preferably customers of issuing participant 102 and relying participant 104 , respectively.
- First customer 106 is referred to as the “subscribing customer” because this customer subscribes to services provided by issuing participant 102 .
- First customer 106 is also referred to as the “buyer” because it typically fills that role in transactions with second customer 108 .
- Second customer 108 is referred to as the “relying customer” because it relies on representations made by both issuing participant 102 and subscribing customer 106 . Second customer 108 is also referred to as the “seller” because it typically fills that role in transactions with first customer 106 . It should be recognized, however, that although the description below speaks primarily in terms of a buyer 106 and a seller 108 , first customer 106 and second customer 108 may instead have different roles in a given transaction. For example, first customer 106 may be a borrower repaying a loan to second customer 108 .
- Root entity 110 is typically an organization that establishes and enforces a common set of operating rules for facilitating electronic commerce and electronic communications. Root entity 110 may be owned jointly by a plurality of banks and/or other financial institutions that have agreed to adhere to these operating rules.
- One exemplary embodiment of such a root entity is described in copending U.S. patent application Ser. No. 09/502,450, filed Feb. 11, 2000, entitled System and Method for Providing Certification Related and Other Services and in copending U.S. patent application Ser. No. 09/657,623, filed Sep. 8, 2000, entitled System and Method for Providing Certificate-Related and Other Services, which are hereby incorporated by reference.
- the smartcard issued to subscribing customer 106 is provided with two private keys and corresponding digital certificates: an identity private key and corresponding certificate, and a utility private key and corresponding certificate.
- the identity private key is used to produce digital signatures that are required by root entity 110 as evidence of an entity's contractual commitment to the contents of an electronic transaction, such as a purchase order or a warranty request such as the warranty request described in U.S. provisional application Ser. No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure and U.S. application Ser. No. ______, filed Aug. 14, 2001, entitled System and Method for Providing Warranties in Electronic Commerce, which are hereby incorporated by reference.
- the utility private key is preferably used to produce digital signatures that allow additional transactional security.
- utility certificates are used to support SSL, to sign S/MIME messages, and for other utility applications. Any reference in this document to a “certificate” refers to an identity certificate unless otherwise stated.
- FIG. 2 illustrates components preferably provided at relying customer 108 and subscribing customer 106 in the present system.
- relying customer 108 is preferably provided with a Web server 220 adapted to serve Web pages and other Web content via the Internet.
- Relying customer 108 is further preferably provided with a bank interface 222 for accessing services from relying participant 104 .
- An exemplary bank interface is described in copending application Ser. No. 09/657,604, filed on Sep. 8, 2000, entitled System and Method for Facilitating Access by Sellers to Certificate-Related and Other Services.
- Relying customer 108 is further preferably provided with a hardware security module 250 for executing and verifying digital signatures.
- subscribing customer 106 is preferably provided with a Web browser 224 adapted to transmit requests for Web pages and other Web content via the Internet, and to receive responses to those requests.
- Issuing participant 102 is further preferably provided with a smartcard subsystem 226 for signing transaction data, described in further detail below.
- the components that make up smartcard subsystem 226 are provided to buyer 106 by its issuing participant 102 .
- subscribing customer 106 may also be provided with a signing interface (not shown).
- a preferred signing interface is described in U.S. provisional application Ser. No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure and U.S. application Ser. No. ______, filed Aug. 14, 2001, entitled System and Method for Facilitating Signing by Buyers in Electronic Commerce, which are hereby incorporated by reference.
- the signing interface provides a mechanism by which a seller's Web applications may invoke the buyer's smartcard subsystem or other signing module to execute a digital signature.
- FIG. 3 illustrates a preferred embodiment of components included in smartcard subsystem 226 .
- smartcard subsystem 226 preferably comprises smartcard drivers and other software 310 (“drivers 310 ”), a smartcard reader 320 (“reader 320 ”), and a smartcard token 400 .
- Reader 320 and drivers 310 facilitate communication between smartcard token 400 and other software running on subscribing customer 106 's computer system.
- Smartcard token 400 preferably comprises an integrated circuit card, such as an International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 7816 integrated circuit card.
- ISO International Organization for Standardization
- IEC International Electrotechnical Commission
- a personal security token such as a Personal Computer Memory Card International Association (PCMCIA) device, or other comparable devices may be used.
- PCMCIA Personal Computer Memory Card International Association
- smartcard token 400 is preferably owned by issuing participant 102 and made available for use to subscribing customer 106 under terms of a contract between subscribing customer 106 and issuing participant 102 .
- the physical manifestation of the identity private key on smartcard token 400 shares an important characteristic of physical property (i.e., its uniqueness) that differentiates it from other computer data that may be copied and allowed to proliferate. Consequently, in a preferred embodiment, the contract with subscribing customer 106 further specifies that the physical manifestation of the private key is owned by issuing participant 102 .
- smartcard token 400 and/or the physical manifestation of the identity private key may be owned by root entity 110 .
- smartcard token 400 and/or the physical manifestation of the identity private key may be owned by subscribing customer 106 .
- FIG. 4A illustrates a preferred embodiment of smartcard token 400 .
- smartcard token 400 preferably comprises a chip 401 that comprises a processor 405 , a memory 410 , and an I/O module 415 .
- Processor 405 preferably runs a high-security multi-application operating system, such as MULTOS.
- processor 405 is programmed to perform various functions including those shown as functional modules in FIG. 4B. As shown in FIG. 4B, one such module is a signature generator 424 .
- Signature generator 424 is adapted to generate a digital signature using either the identity private key or utility private key, depending on the nature of the message to be signed.
- Signature generator 424 preferably generates RSA-based digital signatures using 1024 bit keys based on the RSASSA-PKCS-v 1 — 5 signature scheme and the SHA-1 with RSA encryption method.
- Counter 422 monotonically increases each time smartcard token 400 generates a signature using the identity private key.
- Counter 423 keeps track of the number of consecutive failed attempts to enter subscribing customer 106 's personal identification number (PIN)/passphrase before the identity private key is blocked, as discussed below.
- PIN personal identification number
- CSSD generator 426 generates card and signature security data (CSSD) that may be included in signed transaction data to provide additional security, such as protection against duplicate message submission.
- CSSD card and signature security data
- root entity 110 does not impose any requirements concerning CSSD. Rather, issuing participant 102 determines whether and what type of CSSD to require as part of its risk management process.
- CSSD is preferably generated using an authentication algorithm and a key. If the key used is the subscriber's identity private key, CSSD generator 426 preferably uses a different algorithm to generate the CSSD cryptogram than the algorithm used to sign the transaction data itself in order to avoid potential attacks on smartcard token 400 . Thus, for example, if the algorithm used by smartcard subsystem 226 to generate signatures with the subscriber's identity private key is SHA-1 with RSA signature, then CSSD generator 426 preferably uses a different algorithm to generate CSSD cryptograms. This different algorithm preferably has a strength greater than or equal to 1024 bit RSA.
- a hash of the transaction data to be signed is included as part of the authenticated data within the CSSD data block.
- Smartcard token 400 may also comprise additional applications 425 , i.e., applications that provide functionality not required to conduct transactions or obtain services within the four-corner model. In a preferred embodiment, such applications must nevertheless comply with security requirements for smartcard token 400 specified by root entity 110 , as described below. In addition, such applications preferably do not use or have access to secure data on smartcard token 400 , such as subscribing customer's 106 identity private key and PIN/passphrase.
- smartcard token 400 may also comprise a key generator 421 adapted to generate private/public key pairs, as described below.
- a preferred set of functionality requirements for smartcard token 400 is now described. These functionality requirements are preferably specified by root entity 110 to facilitate interoperability of the subscribing customer's smartcard with other system components.
- Smartcard token 400 must be adapted to create signatures using SHA-1 and RSA with 160-bit HASH Keys (as described in PKCS #1 v 1.5)
- Smartcard token 400 must be adapted to use signature scheme RSASSA-PKCS-v1 — 5.
- Smartcard token 400 must be adapted to store securely the subscriber's utility private key and identity private key in accordance with PKCS #1 v 2.0.
- Smartcard token 400 must be adapted to store securely a cardholder PIN of at least six numeric characters, although a passphrase of at least 8 ASCII characters is recommended.
- smartcard token 400 must be adapted to store securely a security officer PIN/passphrase of at least six numeric characters, although a passphrase of at least 8 alphanumeric characters is recommended.
- smartcard token 400 must be adapted to store securely CSSD specified by the issuing participant.
- CSSD is a mechanism used to provide additional security (such as protection against duplicate message submission) for digital messages.
- CSSD is implemented on smartcard token 400 , then the card must be adapted to implement an internal counter value that monotonically increases each time the identity key is used to generate a signature.
- CSSD is implemented on smartcard token 400 , then the card must be adapted to use an authentication algorithm and key to generate the CSSD cryptogram. If the Key used is the identity private key, then the signature algorithm must not be SHA-1 with RSA signature. Other algorithms may be used, but must have strength equivalent to or greater than 1024 bit RSA. In other words, the algorithm used to generate the CSSD signature must be different than the one used to sign digital messages in order to avoid potential attacks.
- CSSD is implemented on smartcard token 400 , then the card must be adapted to implement a mechanism for ensuring that the transaction hash (i.e., the data sent to the buyer for signature) is part of the authenticated data within the CSSD block.
- Smartcard token 400 must be adapted to generate RSA-based digital signatures using 1024 bit keys based on the following signature scheme and method:
- root entity 110 establishes security requirements for smartcard token 400 to ensure that the card functions properly and that the confidentiality and integrity of sensitive information that it stores are maintained.
- the security requirements preferably include functional security requirements, hardware security requirements, and compliance requirements.
- a preferred embodiment of the functional security requirements is as follows:
- Smartcard token 400 must support the functionality necessary to comply with requirements established by root entity 110 .
- Smartcard token 400 must be adapted to ensure the proper functionality of all applications approved by root entity 110 for system use.
- the life-cycle status of smartcard token 400 must be irreversible, i.e., it must not be possible to erase the card and start the personalization again, unless all private-key material from a first personalization can be completely erased so that it cannot be recovered before, during, or after the second personalization.
- Sensitive data including the identity and utility private keys, generated outside smartcard token 400 must be loaded in smartcard token 400 using 2-Key 3-DES encryption or alternative of equal strength.
- the card personalizer must implement a key management scheme that ensures the confidentiality of sensitive data during the personalization process of smartcard token 400 .
- the personalization process includes key generation, key loading, and loading of applications, including confidential data.
- the card personalizer must verify the integrity of smartcard token 400 before personalization.
- Smartcard token 400 must not support the export of any private key in any form whatsoever. Consequently, private keys, once injected into smartcard token 400 , will exist only on that smartcard and will not be stored in any other location.
- PINs or passphrases must be stored on smartcard token 400 .
- Smartcard token 400 must not support the export of secret data (PIN/Passphrase) in any form whatsoever.
- Smartcard token 400 must require an eight character minimum PIN/passphrase for a user to access the identity private key.
- Initial user PIN/passphrase selection must be based upon a random character selection algorithm to reduce the likelihood of similar initial user PIN/passphrases in multiple smartcards.
- the card issuer must be required to use a different initial user PIN/passphrase for each card. To support the use of secure PIN pads it is acceptable for all eight characters to have numeric values.
- smartcard token 400 must check that the user-supplied value is different from that set by the issuing participant. If the two values are the same, smartcard token 400 must reject the attempted change.
- Smartcard token 400 must provide an unambiguous association between the PIN/passphrase and the creation of an identity signature. Therefore:
- the PIN/passphrase must be provided by the user each time the identity private key is used.
- An identity private key can only be unlocked to generate a single identity signature.
- Smartcard token 400 must enforce a six numeric-character minimum for the security officer PIN/passphrase. An eight character alphanumeric passphrase is recommended. (In an alternative preferred embodiment, an eight character alphanumeric passphrase may be required.)
- Smartcard token 400 must not allow itself to be unblocked more than six times (see section 6 below re: card blocking/unblocking).
- Security officer PIN/passphrase selection must be based upon a random character selection algorithm to reduce the likelihood of similar security officer PIN/passphrases in multiple smartcard tokens.
- the card issuer must use different security officer PIN/passphrases for each card.
- a smartcard token must contain no more than six security officer PIN/passphrases.
- the PIN/passphrases must be adapted to allow no more than six unblocking operations.
- smartcard token 400 may store one security officer PIN/passphrase which may be used up to six times or at most six security officer PIN/passphrases which must each be used at most once, i.e., for one unblocking operation.
- the security officer must not have access to user PINs/passphrases.
- the security officer's role and the user's role must not be performed by the same person.
- Smartcard token 400 must enforce a limit on the number of consecutive incorrect PINs/passphrases that it will allow before blocking the card (reversibly, if card unblocking is supported). This limit must be no greater than five. Note: If a correct PIN/passphrase is entered before the limit is exceeded, counter 423 a which enforces this limit is reset.
- smartcard token 400 When smartcard token 400 is in a “reversibly blocked” state, it must render inaccessible all applications that call for use of the identity private key. It is acceptable although not required—for the utility private key to remain useable.
- a secure mechanism under the control of the issuing participant.
- This secure mechanism may be a security officer PIN/passphrase, but others (such as secure messaging as used in EMV) are also acceptable if implemented in accordance with this requirement.
- Smartcard token 400 shall enforce a limit of six unblocks. Once a card has hit that limit, the operational data and functions on the card must be permanently inaccessible (i.e. the card must be rendered irreversibly blocked).
- Private key generation must only be performed during personalization of smartcard token 400 .
- key generation occurs before personalization.
- personalization is taken to mean the whole process of key generation and binding of user to card.
- key generation can take place as a separate activity before binding the user to the card.
- smartcard token 400 If smartcard token 400 supports key generation, it shall use a built-in hardware random number generator that passes either the statistical random number generator tests defined in FIPS 140-1, section 4.11.1, or alternative tests that provide equivalent or superior randomness checking.
- smartcard token 400 must support the functionality necessary to comply with requirements established by root entity 110 .
- root entity 110 may establish as a requirement that the smartcard operating system must check the appropriateness of private key usage before using a private key in a cryptographic operation and that (1) the identity private key must not be used for encryption/decryption, and (2) the utility private key must not be used for executing digital signatures.
- smartcard token 400 and its operating system must be adapted to enforce these requirements in order for the smartcard token to comply with functional security requirement 1.1 above.
- the hardware security requirements are defined in terms of security levels specified by root entity 110 .
- FIG. 5 illustrates a preferred set of security levels that may be specified by root entity 110 .
- root entity 110 preferably specifies two security levels: a “high” security level and a “beyond practicality” security level. These security levels are further defined in terms of the amount of time it would take to (a) prepare and (b) conduct an attack on smartcard token 400 under a variety of scenarios. Each scenario is defined in terms of an attacker and the equipment used by the attacker, as described below.
- Proficient persons are also knowledgeable in that they are familiar with the security behavior of smartcard token 400 . They are capable of effectively using domestic equipment and professional equipment, but not specialized equipment.
- domestic equipment is equipment that is readily available within the end user's operational environment, is a part of the smartcard subsystem itself, or can readily be purchased. Domestic equipment includes basic electronic equipment, standard personal computers, and simple and readily available analysis equipment (e.g. voltage meters).
- Professional equipment is equipment that is not readily available to the public because (1) the equipment is expensive to the point that only facilities such as universities, reverse engineering labs, and chip fabricators typically have this equipment, and (2) the use of the equipment requires special skills or resources. Professional equipment includes logic analyzers, workstations, and probe stations.
- Specialized equipment is equipment that is not readily available to the public because (1) the equipment is very expensive and, (2) the equipment is so specialized that its distribution is controlled or restricted. Specialized equipment includes special code breakers, focused ion beam systems, and scanning electron microscopes.
- An attack is an attempt by an adversary to obtain or modify sensitive information or services for which the attacker is not authorized.
- An attack comprises two phases:
- root entity 110 for a system component to satisfy a “beyond practicality” security level established by root entity 110 , it must be infeasible for either an expert or proficient person to prepare an attack against the component using domestic equipment, it must take at least six months for an expert and 12 months for a proficient person to prepare such an attack using professional equipment, and it must take an expert at least three months to prepare such an attack using specialized equipment. In addition, it must be infeasible for either an expert or proficient person to mount a previously prepared attack against the component using domestic equipment, it must take at least one month for an expert and three months for a proficient person to mount such an attack using professional equipment, and it must take an expert at least one week to mount such an attack using specialized equipment.
- root entity 110 first establishes a set of high-level security objectives for ensuring the security and integrity of smartcard token 400 . Low-level requirements are then defined that specify the particular steps that will be taken to satisfy the high-level objectives. In addition, root entity preferably identifies known threats to the security and integrity of smartcard token 400 and ensures that these threats are adequately addressed by the low-level requirements. As new threats develop, root entity 110 may revise the low-level requirements; the high-level objectives, however, preferably do not change.
- a preferred set of high-level security objectives for smartcard token 400 are as follows:
- root entity 110 has defined an appropriate set of high-level objectives, it defines a set of low-level security requirements to address them.
- a preferred set of low-level security requirements for smartcard token 400 is as follows:
- ROM read only memory
- EEPROM electrically erasable programmable read only memory
- Root entity 110 preferably creates a matrix, such as that shown in FIG. 6, to demonstrate that each high-level security objective is addressed by at least one low-level security requirement. As will be recognized, alternative low-level objectives and matrixes may be established.
- Root entity 110 also preferably identifies a set of potential security threats to smartcard token 400 and ensures that the low-level requirements described above adequately address the identified threats. In a preferred embodiment, root entity identifies the following potential security threats to smartcard token 400 .
- Chip modification may be accomplished by devices such as focused ion beam (FIB) systems that expose the surface of chip 401 and allow an attacker to view and modify the contents of memory cells on smartcard token 400 .
- FIB systems may also be used to make chip modifications in order to aid other attacks or to change the functionality of chip 401 .
- Reverse engineering may also be accomplished using FIB systems. If any of smartcard token 400 's components are reverse engineered, it may be possible to derive the functionality of those components. Knowing the functionality, an attacker may be able to retrieve sensitive information from smartcard token 400 .
- testing hardware and software Before smartcard token 400 leaves the manufacturer, the testing hardware and software is preferably irreversibly deactivated. But if an attacker succeeds in restoring these test features by reactivating hardware fuses on chip 401 , the attacker may be able to gain access to the smartcard's sensitive information.
- An internal attack involves placing small probing needles on certain, critical nodes on the surface of the smartcard's chip.
- probing attacks There are two types of probing attacks: a passive probing attack and an active probing attack.
- a passive probing attack involves tapping sensitive information from the chip's nodes.
- An active probing attack involves changing the information on these nodes.
- an active probing attack may be used to change the status of memory 410 , change the programming of memory 410 , or change the functionality of smartcard token 400 .
- External attack techniques include, without limitation, (a) simple power analysis (SPA), (b) differential power analysis (DPA), and (c) manipulation of the smartcard environment.
- SPA simple power analysis
- DPA differential power analysis
- c manipulation of the smartcard environment.
- SPA involves measuring the power consumption over time of smartcard token 400 while it is performing a cryptographic calculation. This measurement is called the power profile and can serve as a fingerprint of the processes running on smartcard token 400 . In some cases, it may be possible to discover from this profile the algorithms used on smartcard token 400 as well as sensitive information generated by those algorithms.
- DPA involves recording a relatively large number of power traces on smartcard token 400 . By statistically analyzing these traces, an attacker may be able to reverse engineer the algorithms running on the smartcard and hence determine a subscriber's private key.
- Root entity 110 preferably creates a matrix to demonstrate that each identified potential threat is addressed by at least one low-level objective. In doing so, it may generalize the above-identified threats into categories.
- a preferred set of threat categories are as follows: (1) direct reading of memory contents; (2) ability to retrieve hardware functionality; (3) changing hardware functionality; (4) tapping or reading internal information; (5) changing internal information; (6) changing logical functionality; and (7) information leakage.
- FIG. 7 graphically illustrates a preferred matrix between the low-level security requirements and security threat categories listed above. As will be recognized, other alternative threat categories and matrixes may be established.
- Root entity 110 preferably requires an independent third-party security evaluation of smartcard token 400 .
- the security evaluation ensures that smartcard token 400 conforms with the security requirements established by root entity 110 and that it does not have hidden vulnerabilities.
- this evaluation may be conducted in accordance with one or more of the following standards: the Information Technology Security Evaluation Criteria (ITSEC), the Common Criteria for Information Technology Security Evaluation (CC), the Federal Information Processing Standard (FIPS), the European Electronic Signature Standardization Initiative (EESSI), and the Visa Open Platform Certification.
- ITSEC Information Technology Security Evaluation Criteria
- CC Common Criteria for Information Technology Security Evaluation
- FIPS Federal Information Processing Standard
- EESSI European Electronic Signature Standardization Initiative
- Visa Open Platform Certification the Visa Open Platform Certification.
- root entity 110 may develop its own standards.
- ITSEC ITSEC assurance level E 4 with strength of mechanism “high.” If CC is used, then smartcard token 400 preferably meets or exceeds CC assurance level EAL 4 + with strength of function “high.” If FIPS is used, then smartcard token 400 preferably meets or exceeds FIPS assurance level 2 . If EESSI is used, then smartcard token 400 preferably meets or exceeds a level of compliance equivalent to CC EAL4+. If Visa Open Platform certification is used, then smartcard token 400 preferably meets or exceeds an assurance level comparable to those identified above. Regardless of the standard used, however, if there is a conflict between the standard and a policy or procedure established by root entity 110 , then root entity 110 's policies and procedures preferably control.
- Root entity 110 may require a statement from issuing participant 102 certifying that each smartcard token 400 it issues complies with one of the above-listed standards.
- root entity 110 may require that issuing participant 102 issue a statement that its card issuance procedures, personalization procedures, and smartcard tokens ensure non-repudiable signatures. Issuing participant 102 typically satisfies this requirement by supplying documentation from accredited testing laboratories. Equivalent statements from smartcard vendors may also be used.
- smartcard tokens that are not certified may not be used in any transactions conducted within the four-corner model.
- the degree of rigor required for the testing of smartcard token 400 may differ if the smartcard subsystem implements only applications used to conduct transactions or obtain services within the four-corner model, as opposed to a case where other applications are supported. In the latter case, it must be shown that the smartcard's operating system (such as MULTOS) is isolated from such other applications to such an extent that the applications can be evaluated independently of the operating system. If this is not the case, then additional evaluation and testing may preferably be required.
- Smartcard token 400 As a further measure of security, the integrity of smartcard token 400 is preferably ensured during all phases of the token's life-cycle. Smartcard token 400 's life cycle includes chip fabrication, module fabrication, card manufacturing, card personalization, card distribution, card activation, and card termination. The manufacturing phase of the hardware token 400 's life-cycle is preferably documented by the manufacturer. Manufacturers may be required to supply issuing participant 102 with proof that all reasonable precautions have been taken to ensure the integrity of smartcard token 400 .
- smartcard token 400 may be accessed by a security officer employed or authorized by issuing participant 102 .
- the security officer verifies proper functionality and security of the components at smartcard token 400 but preferably is not given access to sensitive data stored on hardware token 400 , such as subscriber 106 's identity private key and PIN/passphrase.
- the security officer is preferably provided with a PIN/passphrase for unblocking smartcard token 400 , as described above.
- Smartcard token 400 may store as many as six security officer PIN/passphrases.
- issuing participant 102 is responsible for personalizing each smartcard token that it issues for a particular issuing participant 106 .
- Issuing participant 102 preferably ensures that smartcard token 400 is personalized in an environment that prevents the identity private key from being compromised during personalization.
- the personalization environment also preferably prevents incorrect or illegal personalization, unauthorized software or data from being loaded onto the token, unauthorized personnel from having access to the personalization area and equipment, and tokens from being lost or stolen before or after personalization.
- FIG. 8 illustrates a preferred embodiment of a smartcard token personalization process in which an identity private key is generated on smartcard token 400 .
- step 801 issuing participant 102 verifies the integrity of smartcard token 400 .
- This step may include, for example, examining appropriate documentation from the vendor that manufactured smartcard token 400 that confirms that the token was manufactured in accordance with suitable security standards.
- step 802 key generator 421 generates an identity private key and its corresponding public key.
- the identity private key is stored in memory 410 .
- key generator 421 generates a utility private key and its corresponding public key.
- step 805 the utility private key is stored in memory 410 .
- Smartcard token 400 is preferably adapted to prevent any export of either private key from smartcard token 400 .
- step 806 any desired additional software and data are loaded onto smartcard token 400 .
- step 807 issuing participant 102 binds subscribing customer 106 to smartcard token 400 by verifying subscribing customer 106 's identity and creating a digital certificate for the subscribing customer that includes the customer's identity public key.
- step 808 issuing participant 102 physically issues the smartcard containing the subscribing customer 106 's private key to the subscribing customer.
- step 809 issuing participant 102 provides subscribing customer 106 a copy of the customer's digital certificate.
- the certificate is not stored on the subscriber's smartcard token 400 . This increases system security because if the smartcard token is lost or stolen, the finder will not be able to determine the subscriber's identity from the smartcard and will therefore find it difficult or impossible to forge digital signatures in the subscriber's name.
- the subscriber's certificate is preferably delivered to the subscriber on some other medium or by electronic transmission and then stored in a personal security environment (PSE) outside the token.
- PSE personal security environment
- the subscriber's certificate may be stored on smartcard token 400 .
- FIG. 9 illustrates a preferred embodiment of a smartcard token personalization process in which the identity private key is generated outside the card.
- issuing participant 102 verifies the integrity of smartcard token 400 , as described above.
- issuing participant 102 generates an identity private key and a corresponding public key.
- issuing participant 102 generates a utility private key and a corresponding public key.
- these private keys are preferably generated using a hardware security module that complies with requirements specified by root entity 110 .
- An exemplary set of hardware security module requirements are set forth in U.S. provisional application Ser. No. 60/153,203, filed Sep.
- the private keys are loaded onto smartcard token 400 .
- the private keys are preferably loaded onto the token with at least 2-Key 3-DES encryption via a key management system which ensures the confidentiality and integrity of the private keys during the personalization of smartcard token 400 .
- step 905 the private keys are stored in memory 410 .
- step 906 any instance of the private key at the hardware security module or elsewhere in the initialization system is destroyed. This ensures that the only instance of the subscriber's private key is securely stored on smartcard token 400 .
- Smartcard token 400 is preferably adapted to prevent any export of either private key from smartcard token 400 .
- step 907 any desired additional software and data are loaded onto smartcard token 400 .
- step 908 issuing participant 102 binds subscribing customer 106 to smartcard token 400 , as described above.
- step 909 issuing participant physically issues smartcard token 400 and subscribing customer 106 's digital certificate to subscribing customer 106 , as described above.
- FIG. 10 illustrates a preferred embodiment of a process for signing a message using the subscribing customer's smartcard token 400 .
- step 1001 subscribing customer 106 visits relying customer 108 's Web site. The parties preferably authenticate themselves over an SSL session using their utility keys.
- step 1002 relying customer 108 , via its Web server 220 , sends subscribing customer 106 a message requesting that the subscribing customer digitally sign certain data (e.g., a purchase order for an agreed-to transaction).
- step 1003 subscribing customer 106 's Web browser 224 transmits the data to be signed to smartcard subsystem 226 .
- smartcard subsystem 226 prompts subscribing customer 106 for his or her PIN/passphrase. As discussed above, subscribing customer 106 preferably must enter his or her PIN/passphrase each time a signature is to be executed using the identity private key.
- step 1005 subscribing customer 106 submits his or her PIN/passphrase to smartcard subsystem 226 .
- step 1006 if subscribing customer 106 enters the correct PIN/passphrase, smartcard token 400 unlocks the identity private key.
- smartcard token 400 is preferably blocked, as described above.
- step 1007 if the identity private key is unlocked, signature generator 424 uses the identity private key to sign the data to be signed. If CSSD is implemented, then CSSD generator 426 generates CSSD. In a preferred embodiment, subscribing customer 106 need not provide a PIN/passphrase in order to generate CSSD. CSSD is preferably automatically generated and included in the signed data by smartcard token 400 .
- smartcard subsystem 226 transmits the signed data to Web browser 224 .
- step 1009 Web browser 224 transmits the signed data to Web server 220 for further four-corner processing.
- subscribing customer may be provided with a signing interface to facilitate digital signing of messages by smartcard subsystem 226 .
- An exemplary signing interface is described in U.S. provisional application serial No. 60/224,994, entitled Signing Interface Requirements, Hardware Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure, filed Aug. 14, 2000, which is hereby incorporated by reference.
- some or all of the requirements described above may be weighted to enable an issuing participant to formulate a matrix to aid in evaluating the ability of potential vendors to meet the requirements.
- each weighted requirement to be satisfied by the vendor is scored by the issuing participant.
- the score assigned to a vendor for a given requirement is preferably based on their ability to satisfy the requirement functionally, technically, and with good quality.
- the score assigned by the issuing participant is multiplied by the requirement's weight and entered in the matrix. For example, if an issuing participant gave a vendor a score of eight for a given requirement, and the weight assigned the requirement was 10 , then the number entered in the matrix would be 80 . Totals for all requirements may be calculated and used in choosing an appropriate vendor. A preferred embodiment of weights assigned to particular requirements described above is shown in FIG. 11.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Signal Processing (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Software Systems (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
- This application claims priority from U.S. provisional application serial No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure, which is hereby incorporated by reference.
- The world of electronic commerce has created new challenges to establishing relationships between contracting parties. One of those challenges springs from the fact that the parties to the transaction cannot see or hear each other, and cannot otherwise easily confirm each other's identity and authority to act.
- One remedy for this problem is to provide each contracting party with a private key for signing transmitted messages with a digital signature. The signing party makes available an associated public key that decrypts messages signed with the party's private key, and thus enables a receiving party to confirm the identity of the sender.
- The digital signature is typically created by a smartcard subsystem resident on the signing party's computer. This subsystem comprises a hardware token that stores the signing party's private key and any necessary software for executing the digital signature.
- But the signature created by the smartcard is only as secure as the card's private key. It is therefore critical that the private key be protected from compromise by cryptographic or other attacks.
- Many prior art electronic commerce systems, however, fail to adequately protect the private key from compromise. For example, some systems maintain more than one copy of the private key including one or more copies of the private key that may be maintained outside the card. If an unauthorized party gains access to one such copy, he or she can masquerade as the buyer. As a result, the buying parties cannot be assured that their signatures will not be affixed to unauthorized transactions and selling parties cannot be assured that a completed transaction will not later be refuted by the buying party. The failure to assure the security of a party's private key on the party's smartcard may thus compromise the ability of parties to conduct secure electronic commerce.
- A system and method are disclosed for ensuring the security and integrity of a party's private key stored on a smartcard or other hardware token. A set of security requirements are defined for the smartcard that ensure that the card is manufactured and initialized in a secure environment and that it can withstand certain types of cryptographic and other attacks. The requirements further ensure that, at the conclusion of the initiation process, there exists only a single instance of the private key which may never leave the smartcard. The unique existence of the private key in the smartcard allows the key to be treated as physical property and differentiates the key from other computer data which can be copied and allowed to proliferate.
- In a preferred embodiment, the smartcard and private key are intended for use within the context of a four-corner trust model. This four-corner model preferably comprises a buyer, also referred to as the subscribing customer, and a seller, also referred to as the relying customer, who engage in an on-line transaction.
- The four-corner model also preferably comprises a first financial institution, referred to as the issuing participant. The issuing participant acts as a certificate authority for the buyer and issues the buyer a hardware token including a private key and a digital certificate signed by the issuing participant.
- The four-corner model also preferably comprises a second financial institution, referred to as the relying participant. The seller is a customer of the relying participant and accesses system services via systems maintained by the relying participant.
- The system also includes a root certificate authority that issues digital certificates to the issuing and relying participants. The root entity is also preferably responsible for establishing the security requirements for smartcards issued by the issuing participant described above as well as interoperability requirements that ensure the interoperability of the hardware tokens with other system components.
- The features and advantages described in the specification are not all inclusive, and many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof.
- The above summary of the invention will be better understood when taken in conjunction with the following detailed description and accompanying drawings, in which:
- FIG. 1 is a block diagram of a preferred embodiment of the four-corner model employed by the present system;
- FIG. 2 illustrates certain components provided at relying
customer 108 and subscribingcustomer 106 in a preferred embodiment of the present system; - FIG. 3 illustrates the components of a smartcard subsystem in a preferred embodiment of the present system;
- FIG. 4A schematically illustrates the components of a smartcard token in a preferred embodiment of the present system;
- FIG. 4B schematically illustrates the functional modules of a smartcard token in a preferred embodiment of the present system;
- FIG. 5 illustrates a set of security requirements in a preferred embodiment of the present system;
- FIG. 6 illustrates the relationship between a set of high-level security objectives and a set of low-level security requirements in a preferred embodiment of the present system;
- FIG. 7 illustrates the relationship between a set of security-threat categories and a set of low-level security requirements in a preferred embodiment of the present system;
- FIG. 8 illustrates a preferred embodiment of a process for generating an identity private key;
- FIG. 9 illustrates a second preferred embodiment of a process for generating an identity private key;
- FIG. 10 illustrates a preferred embodiment for using a smartcard to sign a digital message; and
- FIG. 11 illustrates a preferred embodiment of weights assigned to requirements specified by
root entity 110. - The present disclosure relates to a system and method for manufacturing and initializing smartcards and other hardware tokens in a manner that ensures the security and integrity of information stored on the card. In a preferred embodiment, the smartcard is used by a signing party to sign digital messages relating to transactions conducted within the context of a four-corner trust model. A preferred embodiment of this four-corner model is shown in FIG. 1.
- As shown in FIG. 1, the four-corner model preferably comprises a
first institution 102 and asecond institution 104.First institution 102 is referred to as the “issuing participant” because it is a participant in the present system and issues smartcards to its customers, as described below.Second institution 104 is referred to as the “relying participant” because it is a participant in the present system and its customers rely on representations made by issuingparticipant 102 and issuingparticipant 102's customers, as described below.Participants - Also shown in FIG. 1 are a
first customer 106 and asecond customer 108.First customer 106 andsecond customer 108 are preferably customers of issuingparticipant 102 and relyingparticipant 104, respectively.First customer 106 is referred to as the “subscribing customer” because this customer subscribes to services provided by issuingparticipant 102.First customer 106 is also referred to as the “buyer” because it typically fills that role in transactions withsecond customer 108. -
Second customer 108 is referred to as the “relying customer” because it relies on representations made by both issuingparticipant 102 and subscribingcustomer 106.Second customer 108 is also referred to as the “seller” because it typically fills that role in transactions withfirst customer 106. It should be recognized, however, that although the description below speaks primarily in terms of abuyer 106 and aseller 108,first customer 106 andsecond customer 108 may instead have different roles in a given transaction. For example,first customer 106 may be a borrower repaying a loan tosecond customer 108. - Also shown in FIG. 1 is a
root entity 110.Root entity 110 is typically an organization that establishes and enforces a common set of operating rules for facilitating electronic commerce and electronic communications.Root entity 110 may be owned jointly by a plurality of banks and/or other financial institutions that have agreed to adhere to these operating rules. One exemplary embodiment of such a root entity is described in copending U.S. patent application Ser. No. 09/502,450, filed Feb. 11, 2000, entitled System and Method for Providing Certification Related and Other Services and in copending U.S. patent application Ser. No. 09/657,623, filed Sep. 8, 2000, entitled System and Method for Providing Certificate-Related and Other Services, which are hereby incorporated by reference. - In a preferred embodiment, the smartcard issued to subscribing
customer 106 is provided with two private keys and corresponding digital certificates: an identity private key and corresponding certificate, and a utility private key and corresponding certificate. - The identity private key is used to produce digital signatures that are required by
root entity 110 as evidence of an entity's contractual commitment to the contents of an electronic transaction, such as a purchase order or a warranty request such as the warranty request described in U.S. provisional application Ser. No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure and U.S. application Ser. No. ______, filed Aug. 14, 2001, entitled System and Method for Providing Warranties in Electronic Commerce, which are hereby incorporated by reference. - The utility private key is preferably used to produce digital signatures that allow additional transactional security. Typically, utility certificates are used to support SSL, to sign S/MIME messages, and for other utility applications. Any reference in this document to a “certificate” refers to an identity certificate unless otherwise stated.
- FIG. 2 illustrates components preferably provided at relying
customer 108 and subscribingcustomer 106 in the present system. As shown in FIG. 2, relyingcustomer 108 is preferably provided with aWeb server 220 adapted to serve Web pages and other Web content via the Internet. Relyingcustomer 108 is further preferably provided with a bank interface 222 for accessing services from relyingparticipant 104. An exemplary bank interface is described in copending application Ser. No. 09/657,604, filed on Sep. 8, 2000, entitled System and Method for Facilitating Access by Sellers to Certificate-Related and Other Services. Relyingcustomer 108 is further preferably provided with ahardware security module 250 for executing and verifying digital signatures. - As further shown in FIG. 2, subscribing
customer 106 is preferably provided with aWeb browser 224 adapted to transmit requests for Web pages and other Web content via the Internet, and to receive responses to those requests. Issuingparticipant 102 is further preferably provided with asmartcard subsystem 226 for signing transaction data, described in further detail below. In a preferred embodiment, the components that make upsmartcard subsystem 226 are provided tobuyer 106 by its issuingparticipant 102. - In a preferred embodiment, subscribing
customer 106 may also be provided with a signing interface (not shown). A preferred signing interface is described in U.S. provisional application Ser. No. 60/224,994, filed Aug. 14, 2000, entitled Signing Interface Requirements, Smart Card Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure and U.S. application Ser. No. ______, filed Aug. 14, 2001, entitled System and Method for Facilitating Signing by Buyers in Electronic Commerce, which are hereby incorporated by reference. As described in that application, the signing interface provides a mechanism by which a seller's Web applications may invoke the buyer's smartcard subsystem or other signing module to execute a digital signature. - FIG. 3 illustrates a preferred embodiment of components included in
smartcard subsystem 226. As shown in FIG. 3,smartcard subsystem 226 preferably comprises smartcard drivers and other software 310 (“drivers 310”), a smartcard reader 320 (“reader 320”), and asmartcard token 400. -
Reader 320 anddrivers 310 facilitate communication betweensmartcard token 400 and other software running on subscribingcustomer 106's computer system.Smartcard token 400 preferably comprises an integrated circuit card, such as an International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 7816 integrated circuit card. Alternatively, a personal security token, such as a Personal Computer Memory Card International Association (PCMCIA) device, or other comparable devices may be used. - In a preferred embodiment,
smartcard token 400 is preferably owned by issuingparticipant 102 and made available for use to subscribingcustomer 106 under terms of a contract between subscribingcustomer 106 and issuingparticipant 102. In addition, as noted below, only a single instance of the subscribing customer's identity private key is permitted to exist once card-initialization is completed, and this instance of the key must be stored onsmartcard token 400 and must never leave the card. Accordingly, the physical manifestation of the identity private key onsmartcard token 400 shares an important characteristic of physical property (i.e., its uniqueness) that differentiates it from other computer data that may be copied and allowed to proliferate. Consequently, in a preferred embodiment, the contract with subscribingcustomer 106 further specifies that the physical manifestation of the private key is owned by issuingparticipant 102. - In an alternative embodiment,
smartcard token 400 and/or the physical manifestation of the identity private key may be owned byroot entity 110. In a second alternative embodiment,smartcard token 400 and/or the physical manifestation of the identity private key may be owned by subscribingcustomer 106. - FIG. 4A illustrates a preferred embodiment of
smartcard token 400. As shown in FIG. 4A,smartcard token 400 preferably comprises achip 401 that comprises aprocessor 405, amemory 410, and an I/O module 415.Processor 405 preferably runs a high-security multi-application operating system, such as MULTOS. - In a preferred embodiment,
processor 405 is programmed to perform various functions including those shown as functional modules in FIG. 4B. As shown in FIG. 4B, one such module is asignature generator 424.Signature generator 424 is adapted to generate a digital signature using either the identity private key or utility private key, depending on the nature of the message to be signed.Signature generator 424 preferably generates RSA-based digital signatures using 1024 bit keys based on the RSASSA-PKCS-v 1—5 signature scheme and the SHA-1 with RSA encryption method. - Also shown in FIG. 4B are two
counters Counter 422 monotonically increases eachtime smartcard token 400 generates a signature using the identity private key.Counter 423 keeps track of the number of consecutive failed attempts to enter subscribingcustomer 106's personal identification number (PIN)/passphrase before the identity private key is blocked, as discussed below. -
CSSD generator 426 generates card and signature security data (CSSD) that may be included in signed transaction data to provide additional security, such as protection against duplicate message submission. In a preferred embodiment,root entity 110 does not impose any requirements concerning CSSD. Rather, issuingparticipant 102 determines whether and what type of CSSD to require as part of its risk management process. - CSSD is preferably generated using an authentication algorithm and a key. If the key used is the subscriber's identity private key,
CSSD generator 426 preferably uses a different algorithm to generate the CSSD cryptogram than the algorithm used to sign the transaction data itself in order to avoid potential attacks onsmartcard token 400. Thus, for example, if the algorithm used bysmartcard subsystem 226 to generate signatures with the subscriber's identity private key is SHA-1 with RSA signature, thenCSSD generator 426 preferably uses a different algorithm to generate CSSD cryptograms. This different algorithm preferably has a strength greater than or equal to 1024 bit RSA. - In a preferred embodiment, a hash of the transaction data to be signed is included as part of the authenticated data within the CSSD data block.
- Smartcard
token 400 may also compriseadditional applications 425, i.e., applications that provide functionality not required to conduct transactions or obtain services within the four-corner model. In a preferred embodiment, such applications must nevertheless comply with security requirements forsmartcard token 400 specified byroot entity 110, as described below. In addition, such applications preferably do not use or have access to secure data onsmartcard token 400, such as subscribing customer's 106 identity private key and PIN/passphrase. - In some embodiments,
smartcard token 400 may also comprise akey generator 421 adapted to generate private/public key pairs, as described below. - A preferred set of functionality requirements for
smartcard token 400 is now described. These functionality requirements are preferably specified byroot entity 110 to facilitate interoperability of the subscribing customer's smartcard with other system components. - 1.
Smartcard token 400 must be adapted to create signatures using SHA-1 and RSA with 160-bit HASH Keys (as described in PKCS #1 v 1.5) - 2.
Smartcard token 400 must be adapted to use signature scheme RSASSA-PKCS-v1 —5. - 3.
Smartcard token 400 must be adapted to store securely the subscriber's utility private key and identity private key in accordance with PKCS #1 v 2.0. - 4.
Smartcard token 400 must be adapted to store securely a cardholder PIN of at least six numeric characters, although a passphrase of at least 8 ASCII characters is recommended. - 5. If implementing the security officer functionality (described below),
smartcard token 400 must be adapted to store securely a security officer PIN/passphrase of at least six numeric characters, although a passphrase of at least 8 alphanumeric characters is recommended. - 6. If required by issuing
participant 102,smartcard token 400 must be adapted to store securely CSSD specified by the issuing participant. CSSD is a mechanism used to provide additional security (such as protection against duplicate message submission) for digital messages. - 7. If CSSD is implemented on
smartcard token 400, then the card must be adapted to implement an internal counter value that monotonically increases each time the identity key is used to generate a signature. - 8. If CSSD is implemented on
smartcard token 400, then the card must be adapted to use an authentication algorithm and key to generate the CSSD cryptogram. If the Key used is the identity private key, then the signature algorithm must not be SHA-1 with RSA signature. Other algorithms may be used, but must have strength equivalent to or greater than 1024 bit RSA. In other words, the algorithm used to generate the CSSD signature must be different than the one used to sign digital messages in order to avoid potential attacks. - 9. If CSSD is implemented on
smartcard token 400, then the card must be adapted to implement a mechanism for ensuring that the transaction hash (i.e., the data sent to the buyer for signature) is part of the authenticated data within the CSSD block. - 10.
Smartcard token 400 must be adapted to generate RSA-based digital signatures using 1024 bit keys based on the following signature scheme and method: - Signature scheme: RSASSA-PKCS-v1j (Reference PKCS #1 v 2.0).
- Method:
SHA 1 with RSA encryption (Reference PKCS #1 v 2.0). - In a preferred embodiment,
root entity 110 establishes security requirements forsmartcard token 400 to ensure that the card functions properly and that the confidentiality and integrity of sensitive information that it stores are maintained. The security requirements preferably include functional security requirements, hardware security requirements, and compliance requirements. - Functional Security Requirements
- A preferred embodiment of the functional security requirements is as follows:
- 1 General
- 1.
Smartcard token 400 must support the functionality necessary to comply with requirements established byroot entity 110. - 2.
Smartcard token 400 must be adapted to ensure the proper functionality of all applications approved byroot entity 110 for system use. - 2 Manufacturing
- 1. The integrity of
smartcard token 400 must be ensured during all manufacturing phases. The manufacturer must supply necessary information to prove that all reasonable precautions to ensure the integrity of smartcard tokens during all manufacturing phases have been taken. - 2. The life-cycle data of
smartcard token 400 must be documented by the manufacturer. - 3. The life-cycle status of
smartcard token 400 must be irreversible, i.e., it must not be possible to erase the card and start the personalization again, unless all private-key material from a first personalization can be completely erased so that it cannot be recovered before, during, or after the second personalization. - 4. Sensitive data, including the identity and utility private keys, generated outside
smartcard token 400 must be loaded insmartcard token 400 using 2-Key 3-DES encryption or alternative of equal strength. - 5. The card personalizer must implement a key management scheme that ensures the confidentiality of sensitive data during the personalization process of
smartcard token 400. The personalization process includes key generation, key loading, and loading of applications, including confidential data. - 6. The card personalizer must verify the integrity of
smartcard token 400 before personalization. - 7. The manufacturing and personalization (initial private key loading or issuer specific data) of
smartcard token 400 must take place in a production environment, that must prevent that: - a. secret data are compromised during the personalization process,
- b. the personalization process is carried out incorrectly or illegally,
- c. unauthorized software or data is loaded in
smartcard token 400, - d. unauthorized personnel have access to the personalization area and equipment,
- e. smartcard tokens are lost or stolen before and after personalization.
- 8. Trusted personnel must be appointed for personalization of
smartcard token 400, esponsible for: - a. key generation
- b. key loading
- c. loading software and confidential data
- 9. Dual control must be maintained during personalization for:
- a. key generation
- b. key loading
- c. software and data loading
- 3 Private Keys
- 1. Both the identity private key and the utility private key must be stored on
smartcard token 400. - 2. All operations involving private keys must be performed on
smartcard token 400.Smartcard token 400 must not support the export of any private key in any form whatsoever. Consequently, private keys, once injected intosmartcard token 400, will exist only on that smartcard and will not be stored in any other location. - 4 User PIN/Pass phrase
- 1. PINs or passphrases must be stored on
smartcard token 400. - 2. All operations involving a PIN or passphrase must be performed on
smartcard token 400.Smartcard token 400 must not support the export of secret data (PIN/Passphrase) in any form whatsoever. - 3.
Smartcard token 400 must require an eight character minimum PIN/passphrase for a user to access the identity private key. - 4. Initial user PIN/passphrase selection must be based upon a random character selection algorithm to reduce the likelihood of similar initial user PIN/passphrases in multiple smartcards. The card issuer must be required to use a different initial user PIN/passphrase for each card. To support the use of secure PIN pads it is acceptable for all eight characters to have numeric values.
- 5. The user must be required to set his or her PIN/passphrase before performing any operations using the identity private key.
- 6. If the issuing participant has set an initial PIN/passphrase for
smartcard token 400,smartcard token 400 must check that the user-supplied value is different from that set by the issuing participant. If the two values are the same,smartcard token 400 must reject the attempted change. - 7.
Smartcard token 400 must provide an unambiguous association between the PIN/passphrase and the creation of an identity signature. Therefore: - a. the PIN/passphrase used to unlock the identity private key for purposes of applying an identity signature must not be used for any other purpose.
- b. the PIN/passphrase must be provided by the user each time the identity private key is used. An identity private key can only be unlocked to generate a single identity signature.
- 5 Security Officer's PIN/Passphrase (optional, but if not implemented, card unblocking must be disabled)
- 1.
Smartcard token 400 must enforce a six numeric-character minimum for the security officer PIN/passphrase. An eight character alphanumeric passphrase is recommended. (In an alternative preferred embodiment, an eight character alphanumeric passphrase may be required.) - 2.
Smartcard token 400 must not allow itself to be unblocked more than six times (seesection 6 below re: card blocking/unblocking). - 3. Security officer PIN/passphrase selection must be based upon a random character selection algorithm to reduce the likelihood of similar security officer PIN/passphrases in multiple smartcard tokens. The card issuer must use different security officer PIN/passphrases for each card. A smartcard token must contain no more than six security officer PIN/passphrases. Collectively, the PIN/passphrases must be adapted to allow no more than six unblocking operations. Thus, for example,
smartcard token 400 may store one security officer PIN/passphrase which may be used up to six times or at most six security officer PIN/passphrases which must each be used at most once, i.e., for one unblocking operation. - 4. It must not be possible to change the security officer PIN/passphrases once
smartcard token 400 has been personalized. If a security officer changes or leaves, a new card must be issued, unless it can be demonstrated that the security officer does not know the unblock PIN. - 5. The security officer must not have access to user PINs/passphrases. The security officer's role and the user's role must not be performed by the same person.
- 6. If a
smartcard token 400 has been blocked due to a suspected or actual compromise of the PIN/passphrase, then new user PIN/passphrase assigned when unblocking the card must be different from the old user PIN/passphrase. - 6 Blocking/unblocking
- 1.
Smartcard token 400 must enforce a limit on the number of consecutive incorrect PINs/passphrases that it will allow before blocking the card (reversibly, if card unblocking is supported). This limit must be no greater than five. Note: If a correct PIN/passphrase is entered before the limit is exceeded, counter 423 a which enforces this limit is reset. - 2. When
smartcard token 400 is in a “reversibly blocked” state, it must render inaccessible all applications that call for use of the identity private key. It is acceptable although not required—for the utility private key to remain useable. - 3. Once a card is reversibly blocked, it must be unblocked only by a secure mechanism under the control of the issuing participant. This secure mechanism may be a security officer PIN/passphrase, but others (such as secure messaging as used in EMV) are also acceptable if implemented in accordance with this requirement.
- 4.
Smartcard token 400 shall enforce a limit of six unblocks. Once a card has hit that limit, the operational data and functions on the card must be permanently inaccessible (i.e. the card must be rendered irreversibly blocked). - 7 Multi Application
- 1. All applications residing on
smartcard token 400 must comply with the security requirements established byroot entity 110. - 2. Any applications residing on
smartcard token 400 must not influence the correct behavior of any other application onsmartcard token 400. - 3. The identity private key, the utility private key, and any PIN/passphrases shall only be used by applications used to conduct transactions or obtain services within the four-corner model.
- 4. Every application that resides on
smartcard token 400 must be certified against potential security flaws either through the underlying operating system (MULTOS) certification or by other means. - 8 Key generation
- 1. Private key generation must only be performed during personalization of
smartcard token 400. In many cases, key generation occurs before personalization. In this context personalization is taken to mean the whole process of key generation and binding of user to card. In particular, key generation can take place as a separate activity before binding the user to the card. - 2. If
smartcard token 400 supports key generation, it shall use a built-in hardware random number generator that passes either the statistical random number generator tests defined in FIPS 140-1, section 4.11.1, or alternative tests that provide equivalent or superior randomness checking. - 3. If
smartcard token 400 does not support key generation, then keys generated outsidesmartcard token 400 must be loaded onsmartcard token 400 using 2Key 3-DES encryption alternative of equivalent strength. Only Utility keys may be escrowed by a trusted agent. The identity private key must not be escrowed or retained. It must be destroyed after personalization and may only exist in one unique smartcard token. - 4. Keys generated outside
smartcard token 400 must be generated by a hardware security module, complying with the specifications set forth in U.S. provisional application serial No. 60/153,203, filed Sep. 10, 1999, entitled System and Process for Certification in Electronic Commerce, which was converted into co-pending U.S. patent application Ser. No. 09/657,605, filed Sep. 8, 2000, entitled System and Method for Providing Certificate Validation and Other Services, both of which are hereby incorporated by reference. - As noted in functional security requirement 1.1 above,
smartcard token 400 must support the functionality necessary to comply with requirements established byroot entity 110. For example,root entity 110 may establish as a requirement that the smartcard operating system must check the appropriateness of private key usage before using a private key in a cryptographic operation and that (1) the identity private key must not be used for encryption/decryption, and (2) the utility private key must not be used for executing digital signatures. In that event,smartcard token 400 and its operating system must be adapted to enforce these requirements in order for the smartcard token to comply with functional security requirement 1.1 above. - Hardware Security Requirements
- In a preferred embodiment, the hardware security requirements are defined in terms of security levels specified by
root entity 110. FIG. 5 illustrates a preferred set of security levels that may be specified byroot entity 110. As shown in FIG. 5,root entity 110 preferably specifies two security levels: a “high” security level and a “beyond practicality” security level. These security levels are further defined in terms of the amount of time it would take to (a) prepare and (b) conduct an attack onsmartcard token 400 under a variety of scenarios. Each scenario is defined in terms of an attacker and the equipment used by the attacker, as described below. - One potential attacker is called an “expert.” Experts are persons who are familiar with the underlying algorithms, protocols, hardware, structures, and security principles and concepts implemented in
smartcard token 400, and are capable of effectively using professional and specialized equipment (defined below). - Another potential attacker is a “proficient person.” Proficient persons are also knowledgeable in that they are familiar with the security behavior of
smartcard token 400. They are capable of effectively using domestic equipment and professional equipment, but not specialized equipment. - One class of equipment that may be used in conducting an attack is “domestic equipment.” Domestic equipment is equipment that is readily available within the end user's operational environment, is a part of the smartcard subsystem itself, or can readily be purchased. Domestic equipment includes basic electronic equipment, standard personal computers, and simple and readily available analysis equipment (e.g. voltage meters).
- Another class of equipment that may be used in conducting an attack is “professional equipment.” Professional equipment is equipment that is not readily available to the public because (1) the equipment is expensive to the point that only facilities such as universities, reverse engineering labs, and chip fabricators typically have this equipment, and (2) the use of the equipment requires special skills or resources. Professional equipment includes logic analyzers, workstations, and probe stations.
- Another class of equipment that may be used in conducting an attack is “specialized equipment.” Specialized equipment is equipment that is not readily available to the public because (1) the equipment is very expensive and, (2) the equipment is so specialized that its distribution is controlled or restricted. Specialized equipment includes special code breakers, focused ion beam systems, and scanning electron microscopes.
- An attack is an attempt by an adversary to obtain or modify sensitive information or services for which the attacker is not authorized. An attack comprises two phases:
- A. the preparation phase during which the attack is developed such that the attack can be performed as efficiently as possible, and
- B. the repeat attack phase during which the previously developed attack is performed on one device.
- Returning to FIG. 5, for a system component to satisfy a “beyond practicality” security level established by
root entity 110, it must be infeasible for either an expert or proficient person to prepare an attack against the component using domestic equipment, it must take at least six months for an expert and 12 months for a proficient person to prepare such an attack using professional equipment, and it must take an expert at least three months to prepare such an attack using specialized equipment. In addition, it must be infeasible for either an expert or proficient person to mount a previously prepared attack against the component using domestic equipment, it must take at least one month for an expert and three months for a proficient person to mount such an attack using professional equipment, and it must take an expert at least one week to mount such an attack using specialized equipment. - As further shown in FIG. 5, for a system component to satisfy a “high” security level established by
root entity 110, it must take at least six months for an expert and 12 months for a proficient person to prepare an attack against the component using domestic equipment, it must take at least one month for an expert and six months for a proficient person to prepare such an attack using professional equipment, and it must take an expert at least one week to prepare such an attack using specialized equipment. In addition, it must take an expert one month and a proficient person three months to mount a previously prepared attack against the component using domestic equipment, it must take at least one week for an expert and one month for a proficient person to mount such an attack using professional equipment, and it must take an expert at least one day to mount such an attack using specialized equipment. As will be recognized, alternative security levels and corresponding definitions may be established. - In a preferred embodiment,
root entity 110 first establishes a set of high-level security objectives for ensuring the security and integrity ofsmartcard token 400. Low-level requirements are then defined that specify the particular steps that will be taken to satisfy the high-level objectives. In addition, root entity preferably identifies known threats to the security and integrity ofsmartcard token 400 and ensures that these threats are adequately addressed by the low-level requirements. As new threats develop,root entity 110 may revise the low-level requirements; the high-level objectives, however, preferably do not change. - A preferred set of high-level security objectives for
smartcard token 400 are as follows: - 1. It is beyond practicality to breach the confidentiality of the identity private key and the utility private key.
- 2. It is beyond practicality to breach the confidentiality of the PIN/passphrase stored on
smartcard token 400. - 3. It is beyond practicality to change the life-cycle status of
smartcard token 400. - 4. It is beyond practicality to breach the integrity of the counters associated to smartcard token400's blocking and unblocking mechanisms.
- 5. It requires a high security level attack to breach the confidentiality and/or integrity of
smartcard token 400's data and program structures. - 6. It requires a high security level attack to breach the integrity of the bond between the identity of the cardholder and
smartcard token 400. - 7. It requires a high security level attack to breach the integrity of root entity applications present at
smartcard token 400. - 8. It requires a high security level attack to breach the integrity of
smartcard subsystem 226. - As noted, once
root entity 110 has defined an appropriate set of high-level objectives, it defines a set of low-level security requirements to address them. A preferred set of low-level security requirements forsmartcard token 400 is as follows: - Reverse Engineering and Chip Modifications
- 1. It is beyond practicality to remove layers on top of the smartcard chip surface without damaging the chip.
- 2. It requires a high security level attack to visualize the contents of read only memory (ROM) memory cells, including electrically erasable programmable read only memory (EEPROM) cells.
- 3. It is beyond practicality to reverse engineer the functionality of
smartcard token 400. - 4. It is beyond practicality to modify chip structures by means of an FIB system.
- 5. It is beyond practicality to modify individual memory cells.
- 6. It requires a high security level of attack to misuse the smartcard chip's test features.
- 7. It requires a high-level security attack to modify the smarcard chip's fuses.
- 8. It requires a high-level security attack of attack to modify or disable
chip 401's security sensors. - Internal Attacks (probing)
- 9. It is beyond practicality to use a probing attack to retrieve information from
smartcard token 400. - 10. It requires a high security level of attack to change the status of the memory of
smartcard token 400 via active probing techniques. - 11. It requires a high security level attack to influence the correct functionality of logical building blocks at
smartcard token 400 by means of active probing techniques. - 12. It requires a high security level attack to influence the correct execution of applications approved by
root entity 110 atsmartcard 400 by means of active probing techniques. - 13. It requires a high security level of attack to influence the correct programming of memory cells by means of active probing attacks.
- 14. It requires a high security level attack to obtain information from
smartcard token 400 via voltage contrast. - External Attacks
- 15. It is beyond practicality to obtain sensitive information from
smartcard token 400 by analyzing externally available information, such as the power consumption profile or timing analysis of critical processes onsmartcard token 400. - 16. It is beyond practicality to influence the correct execution of applications approved by
root entity 110 onsmartcard token 400 by disturbing external parameters such as the clock input, the temperature, or the power supply. - 17. It is beyond practicality to obtain sensitive information by disturbing external parameters of
smartcard token 400. - 18. It requires a high security level attack to change the status of
memory 410 by means of disturbing external parameters ofsmartcard token 400. -
Root entity 110 preferably creates a matrix, such as that shown in FIG. 6, to demonstrate that each high-level security objective is addressed by at least one low-level security requirement. As will be recognized, alternative low-level objectives and matrixes may be established. -
Root entity 110 also preferably identifies a set of potential security threats tosmartcard token 400 and ensures that the low-level requirements described above adequately address the identified threats. In a preferred embodiment, root entity identifies the following potential security threats tosmartcard token 400. - 1. Chip modification. Chip modification may be accomplished by devices such as focused ion beam (FIB) systems that expose the surface of
chip 401 and allow an attacker to view and modify the contents of memory cells onsmartcard token 400. FIB systems may also be used to make chip modifications in order to aid other attacks or to change the functionality ofchip 401. - 2. Reverse engineering. Reverse engineering may also be accomplished using FIB systems. If any of
smartcard token 400's components are reverse engineered, it may be possible to derive the functionality of those components. Knowing the functionality, an attacker may be able to retrieve sensitive information fromsmartcard token 400. - 3. Restoration of testing hardware and software. Before
smartcard token 400 leaves the manufacturer, the testing hardware and software is preferably irreversibly deactivated. But if an attacker succeeds in restoring these test features by reactivating hardware fuses onchip 401, the attacker may be able to gain access to the smartcard's sensitive information. - 4. Internal attack. An internal attack involves placing small probing needles on certain, critical nodes on the surface of the smartcard's chip. There are two types of probing attacks: a passive probing attack and an active probing attack. A passive probing attack involves tapping sensitive information from the chip's nodes. An active probing attack involves changing the information on these nodes. Thus, an active probing attack may be used to change the status of
memory 410, change the programming ofmemory 410, or change the functionality ofsmartcard token 400. - 5. External attack. External attack techniques include, without limitation, (a) simple power analysis (SPA), (b) differential power analysis (DPA), and (c) manipulation of the smartcard environment.
- (a) SPA involves measuring the power consumption over time of
smartcard token 400 while it is performing a cryptographic calculation. This measurement is called the power profile and can serve as a fingerprint of the processes running onsmartcard token 400. In some cases, it may be possible to discover from this profile the algorithms used onsmartcard token 400 as well as sensitive information generated by those algorithms. - (b) DPA involves recording a relatively large number of power traces on
smartcard token 400. By statistically analyzing these traces, an attacker may be able to reverse engineer the algorithms running on the smartcard and hence determine a subscriber's private key. - (c) Manipulation of the smartcard environment involves suddenly varying some aspect of the smartcard's environment to affect the card's operation. For example, sudden variations in the token's voltage supply may slow the response of the token's internal reference signals, and may cause these signals to be misinterpreted by the token's internal busses which transport instructions and data during card operation and thus change the functionality of applications running on the smartcard. Sudden variations in the token's clock signal or temperature extremes may also cause erratic behavior. These variations may change the correct execution of applications on the token, expose sensitive information, or change the token's memory status.
-
Root entity 110 preferably creates a matrix to demonstrate that each identified potential threat is addressed by at least one low-level objective. In doing so, it may generalize the above-identified threats into categories. A preferred set of threat categories are as follows: (1) direct reading of memory contents; (2) ability to retrieve hardware functionality; (3) changing hardware functionality; (4) tapping or reading internal information; (5) changing internal information; (6) changing logical functionality; and (7) information leakage. FIG. 7 graphically illustrates a preferred matrix between the low-level security requirements and security threat categories listed above. As will be recognized, other alternative threat categories and matrixes may be established. - Compliance Requirements
-
Root entity 110 preferably requires an independent third-party security evaluation ofsmartcard token 400. The security evaluation ensures thatsmartcard token 400 conforms with the security requirements established byroot entity 110 and that it does not have hidden vulnerabilities. - In a preferred embodiment, this evaluation may be conducted in accordance with one or more of the following standards: the Information Technology Security Evaluation Criteria (ITSEC), the Common Criteria for Information Technology Security Evaluation (CC), the Federal Information Processing Standard (FIPS), the European Electronic Signature Standardization Initiative (EESSI), and the Visa Open Platform Certification. Alternatively,
root entity 110 may develop its own standards. - If ITSEC is used to conduct the security evaluation, then smartcard token400 preferably meets or exceeds ITSEC assurance level E4 with strength of mechanism “high.” If CC is used, then smartcard token 400 preferably meets or exceeds CC assurance level EAL4+ with strength of function “high.” If FIPS is used, then smartcard token 400 preferably meets or exceeds
FIPS assurance level 2. If EESSI is used, then smartcard token 400 preferably meets or exceeds a level of compliance equivalent to CC EAL4+. If Visa Open Platform certification is used, then smartcard token 400 preferably meets or exceeds an assurance level comparable to those identified above. Regardless of the standard used, however, if there is a conflict between the standard and a policy or procedure established byroot entity 110, thenroot entity 110's policies and procedures preferably control. -
Root entity 110 may require a statement from issuingparticipant 102 certifying that eachsmartcard token 400 it issues complies with one of the above-listed standards. In addition,root entity 110 may require that issuingparticipant 102 issue a statement that its card issuance procedures, personalization procedures, and smartcard tokens ensure non-repudiable signatures. Issuingparticipant 102 typically satisfies this requirement by supplying documentation from accredited testing laboratories. Equivalent statements from smartcard vendors may also be used. In a preferred embodiment, smartcard tokens that are not certified may not be used in any transactions conducted within the four-corner model. - In a preferred embodiment, the degree of rigor required for the testing of
smartcard token 400 may differ if the smartcard subsystem implements only applications used to conduct transactions or obtain services within the four-corner model, as opposed to a case where other applications are supported. In the latter case, it must be shown that the smartcard's operating system (such as MULTOS) is isolated from such other applications to such an extent that the applications can be evaluated independently of the operating system. If this is not the case, then additional evaluation and testing may preferably be required. - As a further measure of security, the integrity of
smartcard token 400 is preferably ensured during all phases of the token's life-cycle. Smartcard token 400's life cycle includes chip fabrication, module fabrication, card manufacturing, card personalization, card distribution, card activation, and card termination. The manufacturing phase of thehardware token 400's life-cycle is preferably documented by the manufacturer. Manufacturers may be required to supply issuingparticipant 102 with proof that all reasonable precautions have been taken to ensure the integrity ofsmartcard token 400. - As noted, in a preferred embodiment,
smartcard token 400 may be accessed by a security officer employed or authorized by issuingparticipant 102. The security officer verifies proper functionality and security of the components atsmartcard token 400 but preferably is not given access to sensitive data stored onhardware token 400, such assubscriber 106's identity private key and PIN/passphrase. The security officer is preferably provided with a PIN/passphrase for unblockingsmartcard token 400, as described above.Smartcard token 400 may store as many as six security officer PIN/passphrases. - In a preferred embodiment, issuing
participant 102 is responsible for personalizing each smartcard token that it issues for aparticular issuing participant 106. Issuingparticipant 102 preferably ensures thatsmartcard token 400 is personalized in an environment that prevents the identity private key from being compromised during personalization. The personalization environment also preferably prevents incorrect or illegal personalization, unauthorized software or data from being loaded onto the token, unauthorized personnel from having access to the personalization area and equipment, and tokens from being lost or stolen before or after personalization. - FIG. 8 illustrates a preferred embodiment of a smartcard token personalization process in which an identity private key is generated on
smartcard token 400. As shown in FIG. 8, instep 801, issuingparticipant 102 verifies the integrity ofsmartcard token 400. This step may include, for example, examining appropriate documentation from the vendor that manufacturedsmartcard token 400 that confirms that the token was manufactured in accordance with suitable security standards. Instep 802,key generator 421 generates an identity private key and its corresponding public key. Instep 803, the identity private key is stored inmemory 410. Instep 804,key generator 421 generates a utility private key and its corresponding public key. Instep 805, the utility private key is stored inmemory 410.Smartcard token 400 is preferably adapted to prevent any export of either private key fromsmartcard token 400. - In
step 806, any desired additional software and data are loaded ontosmartcard token 400. In step 807, issuingparticipant 102 binds subscribingcustomer 106 tosmartcard token 400 by verifying subscribingcustomer 106's identity and creating a digital certificate for the subscribing customer that includes the customer's identity public key. In step 808, issuingparticipant 102 physically issues the smartcard containing the subscribingcustomer 106's private key to the subscribing customer. - In step809, issuing
participant 102 provides subscribing customer 106 a copy of the customer's digital certificate. In a preferred embodiment, the certificate is not stored on the subscriber'ssmartcard token 400. This increases system security because if the smartcard token is lost or stolen, the finder will not be able to determine the subscriber's identity from the smartcard and will therefore find it difficult or impossible to forge digital signatures in the subscriber's name. In this preferred embodiment, the subscriber's certificate is preferably delivered to the subscriber on some other medium or by electronic transmission and then stored in a personal security environment (PSE) outside the token. In an alternative embodiment, the subscriber's certificate may be stored onsmartcard token 400. - FIG. 9 illustrates a preferred embodiment of a smartcard token personalization process in which the identity private key is generated outside the card. As shown in FIG. 9, in
step 901, issuingparticipant 102 verifies the integrity ofsmartcard token 400, as described above. Instep 902, issuingparticipant 102 generates an identity private key and a corresponding public key. Instep 903, issuingparticipant 102 generates a utility private key and a corresponding public key. As noted, these private keys are preferably generated using a hardware security module that complies with requirements specified byroot entity 110. An exemplary set of hardware security module requirements are set forth in U.S. provisional application Ser. No. 60/153,203, filed Sep. 10, 1999, entitled System and Process for Certification in Electronic Commerce, which was converted into co-pending U.S. patent application Ser. No. 09/657,605, filed Sep. 8, 2000, entitled System and Method for Providing Certificate Validation and Other Services, both of which are hereby incorporated by reference. - In
step 904, the private keys are loaded ontosmartcard token 400. As noted, the private keys are preferably loaded onto the token with at least 2-Key 3-DES encryption via a key management system which ensures the confidentiality and integrity of the private keys during the personalization ofsmartcard token 400. - In
step 905, the private keys are stored inmemory 410. Instep 906, any instance of the private key at the hardware security module or elsewhere in the initialization system is destroyed. This ensures that the only instance of the subscriber's private key is securely stored onsmartcard token 400.Smartcard token 400 is preferably adapted to prevent any export of either private key fromsmartcard token 400. - In
step 907, any desired additional software and data are loaded ontosmartcard token 400. Instep 908, issuingparticipant 102 binds subscribingcustomer 106 tosmartcard token 400, as described above. Instep 909, issuing participant physically issuessmartcard token 400 and subscribingcustomer 106's digital certificate to subscribingcustomer 106, as described above. - FIG. 10 illustrates a preferred embodiment of a process for signing a message using the subscribing customer's
smartcard token 400. As shown in FIG. 10, instep 1001, subscribingcustomer 106visits relying customer 108's Web site. The parties preferably authenticate themselves over an SSL session using their utility keys. Instep 1002, relyingcustomer 108, via itsWeb server 220, sends subscribing customer 106 a message requesting that the subscribing customer digitally sign certain data (e.g., a purchase order for an agreed-to transaction). - In
step 1003, subscribingcustomer 106'sWeb browser 224 transmits the data to be signed tosmartcard subsystem 226. Instep 1004,smartcard subsystem 226prompts subscribing customer 106 for his or her PIN/passphrase. As discussed above, subscribingcustomer 106 preferably must enter his or her PIN/passphrase each time a signature is to be executed using the identity private key. Instep 1005, subscribingcustomer 106 submits his or her PIN/passphrase tosmartcard subsystem 226. Instep 1006, if subscribingcustomer 106 enters the correct PIN/passphrase,smartcard token 400 unlocks the identity private key. If subscribingcustomer 106 enters an incorrect PIN/passphrase, he or she is prompted to re-enter that information. If subscribingcustomer 106 exceeds the limit on the number of incorrect attempts to enter his or her PIN/passphrase, then smartcard token 400 is preferably blocked, as described above. - In
step 1007, if the identity private key is unlocked,signature generator 424 uses the identity private key to sign the data to be signed. If CSSD is implemented, thenCSSD generator 426 generates CSSD. In a preferred embodiment, subscribingcustomer 106 need not provide a PIN/passphrase in order to generate CSSD. CSSD is preferably automatically generated and included in the signed data bysmartcard token 400. Instep 1008,smartcard subsystem 226 transmits the signed data toWeb browser 224. Instep 1009,Web browser 224 transmits the signed data toWeb server 220 for further four-corner processing. - In an alternative embodiment, subscribing customer may be provided with a signing interface to facilitate digital signing of messages by
smartcard subsystem 226. An exemplary signing interface is described in U.S. provisional application serial No. 60/224,994, entitled Signing Interface Requirements, Hardware Compliance Requirements, Warranty Service Functional Requirements, and Additional Disclosure, filed Aug. 14, 2000, which is hereby incorporated by reference. - In a preferred embodiment, some or all of the requirements described above may be weighted to enable an issuing participant to formulate a matrix to aid in evaluating the ability of potential vendors to meet the requirements. In this preferred embodiment, each weighted requirement to be satisfied by the vendor is scored by the issuing participant. The score assigned to a vendor for a given requirement is preferably based on their ability to satisfy the requirement functionally, technically, and with good quality.
- Next, the score assigned by the issuing participant is multiplied by the requirement's weight and entered in the matrix. For example, if an issuing participant gave a vendor a score of eight for a given requirement, and the weight assigned the requirement was10, then the number entered in the matrix would be 80. Totals for all requirements may be calculated and used in choosing an appropriate vendor. A preferred embodiment of weights assigned to particular requirements described above is shown in FIG. 11.
- While the invention has been described in conjunction with specific embodiments, it is evident that numerous alternatives, modifications, and variations will be apparent to those skilled in the art in light of the foregoing description.
Claims (24)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/928,999 US20020112156A1 (en) | 2000-08-14 | 2001-08-14 | System and method for secure smartcard issuance |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US22499400P | 2000-08-14 | 2000-08-14 | |
US09/928,999 US20020112156A1 (en) | 2000-08-14 | 2001-08-14 | System and method for secure smartcard issuance |
Publications (1)
Publication Number | Publication Date |
---|---|
US20020112156A1 true US20020112156A1 (en) | 2002-08-15 |
Family
ID=22843101
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/928,999 Abandoned US20020112156A1 (en) | 2000-08-14 | 2001-08-14 | System and method for secure smartcard issuance |
US09/929,035 Expired - Lifetime US7165178B2 (en) | 2000-08-14 | 2001-08-14 | System and method for facilitating signing by buyers in electronic commerce |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/929,035 Expired - Lifetime US7165178B2 (en) | 2000-08-14 | 2001-08-14 | System and method for facilitating signing by buyers in electronic commerce |
Country Status (4)
Country | Link |
---|---|
US (2) | US20020112156A1 (en) |
EP (1) | EP1323061A1 (en) |
AU (2) | AU2001284882A1 (en) |
WO (2) | WO2002015037A1 (en) |
Cited By (60)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030037259A1 (en) * | 2001-08-20 | 2003-02-20 | Koistinen Martin J. | Remote unblocking with a security agent |
US20030046542A1 (en) * | 2001-09-04 | 2003-03-06 | Hewlett-Packard Company | Method and apparatus for using a secret in a distributed computing system |
US20030115455A1 (en) * | 2001-12-19 | 2003-06-19 | Aull Kenneth W. | Method and apparatus for centralized processing of hardware tokens for PKI solutions |
US20060095963A1 (en) * | 2004-10-29 | 2006-05-04 | Simon Crosby | Collaborative attack detection in networks |
US20060242711A1 (en) * | 2005-04-25 | 2006-10-26 | Kousuke Anzai | Tool, method, and program for supporting system security design/evaluation |
US20070050840A1 (en) * | 2005-07-29 | 2007-03-01 | Michael Grandcolas | Methods and systems for secure user authentication |
US20070055872A1 (en) * | 2003-11-10 | 2007-03-08 | Japan Science And Technology Agency | Secure processor |
US20070239988A1 (en) * | 2006-03-31 | 2007-10-11 | Yedidia Atzmony | Accessing data storage devices |
US20070280483A1 (en) * | 2006-06-06 | 2007-12-06 | Red Hat, Inc. | Methods and systems for key recovery for a token |
US20070288745A1 (en) * | 2006-06-07 | 2007-12-13 | Nang Kon Kwan | Profile framework for token processing system |
US20080016565A1 (en) * | 2004-08-17 | 2008-01-17 | Alan Mushing | Compliance Assessment And Security Testing Of Smart Cards |
US20080022088A1 (en) * | 2006-06-06 | 2008-01-24 | Red Hat, Inc. | Methods and systems for key escrow |
US20080019526A1 (en) * | 2006-06-06 | 2008-01-24 | Red Hat, Inc. | Methods and systems for secure key delivery |
WO2008022086A2 (en) * | 2006-08-11 | 2008-02-21 | Visa International Service Association | Compliance assessment reporting service |
US20080320315A1 (en) * | 2005-12-23 | 2008-12-25 | Trusted Logic | Method for Creating a Secure Counter on an On-Board Computer System Comprising a Chip Card |
US7484089B1 (en) * | 2002-09-06 | 2009-01-27 | Citicorp Developmemt Center, Inc. | Method and system for certificate delivery and management |
US20100027798A1 (en) * | 2007-02-08 | 2010-02-04 | Smartmachine International Holding Gmbh | Method and apparatus for storage of secure information, which is required for short-range communication, on a communication terminal |
US7734924B2 (en) | 2000-09-08 | 2010-06-08 | Identrust, Inc. | System and method for transparently providing certificate validation and other services within an electronic transaction |
US7765161B2 (en) | 1999-09-24 | 2010-07-27 | Identrust, Inc. | System and method for providing payment services in electronic commerce |
US20100299748A1 (en) * | 2007-12-10 | 2010-11-25 | Telefonaktiebolaget L M Ericsson (Publ) | Method for alteration of integrity protected data in a device, computer program product and device implementing the method |
US20100325039A1 (en) * | 2009-04-28 | 2010-12-23 | Mastercard International Incorporated | Apparatus, method, and computer program product for encoding enhanced issuer information in a card |
US20110035813A1 (en) * | 2009-08-04 | 2011-02-10 | Seagate Technology Llc | Encrypted data storage device |
US7904946B1 (en) | 2005-12-09 | 2011-03-08 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US7992203B2 (en) | 2006-05-24 | 2011-08-02 | Red Hat, Inc. | Methods and systems for secure shared smartcard access |
US20110197266A1 (en) * | 2005-12-09 | 2011-08-11 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US8074265B2 (en) | 2006-08-31 | 2011-12-06 | Red Hat, Inc. | Methods and systems for verifying a location factor associated with a token |
US8099765B2 (en) | 2006-06-07 | 2012-01-17 | Red Hat, Inc. | Methods and systems for remote password reset using an authentication credential managed by a third party |
US8180741B2 (en) | 2006-06-06 | 2012-05-15 | Red Hat, Inc. | Methods and systems for providing data objects on a token |
US8190906B1 (en) * | 2008-12-16 | 2012-05-29 | Emc Corporation | Method and apparatus for testing authentication tokens |
US8332637B2 (en) | 2006-06-06 | 2012-12-11 | Red Hat, Inc. | Methods and systems for nonce generation in a token |
US8356342B2 (en) | 2006-08-31 | 2013-01-15 | Red Hat, Inc. | Method and system for issuing a kill sequence for a token |
US8364952B2 (en) | 2006-06-06 | 2013-01-29 | Red Hat, Inc. | Methods and system for a key recovery plan |
US8495380B2 (en) | 2006-06-06 | 2013-07-23 | Red Hat, Inc. | Methods and systems for server-side key generation |
US8589695B2 (en) | 2006-06-07 | 2013-11-19 | Red Hat, Inc. | Methods and systems for entropy collection for server-side key generation |
US8639940B2 (en) | 2007-02-28 | 2014-01-28 | Red Hat, Inc. | Methods and systems for assigning roles on a token |
US20140092424A1 (en) * | 2012-09-28 | 2014-04-03 | Interactive Memories, Inc. | Methods for Real Time Discovery, Selection, and Engagement of Most Economically Feasible Printing Service Vendors among Multiple Known Vendors |
US8693690B2 (en) | 2006-12-04 | 2014-04-08 | Red Hat, Inc. | Organizing an extensible table for storing cryptographic objects |
US8707024B2 (en) | 2006-06-07 | 2014-04-22 | Red Hat, Inc. | Methods and systems for managing identity management security domains |
WO2014081494A1 (en) * | 2012-11-20 | 2014-05-30 | Ebay Inc. | Systems and methods for generating and using a token for use in a transaction |
US8787566B2 (en) | 2006-08-23 | 2014-07-22 | Red Hat, Inc. | Strong encryption |
US8793487B2 (en) | 2008-01-18 | 2014-07-29 | Identrust, Inc. | Binding a digital certificate to multiple trust domains |
US8806219B2 (en) | 2006-08-23 | 2014-08-12 | Red Hat, Inc. | Time-based function back-off |
US8813243B2 (en) | 2007-02-02 | 2014-08-19 | Red Hat, Inc. | Reducing a size of a security-related data object stored on a token |
US8818903B2 (en) | 1999-09-10 | 2014-08-26 | Charles Dulin | Transaction coordinator for digital certificate validation and other services |
US8832453B2 (en) | 2007-02-28 | 2014-09-09 | Red Hat, Inc. | Token recycling |
US8892475B2 (en) | 2000-09-08 | 2014-11-18 | Identrust, Inc. | Provision of authorization and other services |
US20150012428A1 (en) * | 2000-01-05 | 2015-01-08 | Iii Holdings 1, Llc | Smartcard internet authorization system |
US8977844B2 (en) | 2006-08-31 | 2015-03-10 | Red Hat, Inc. | Smartcard formation with authentication keys |
US9002750B1 (en) | 2005-12-09 | 2015-04-07 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
US9038154B2 (en) | 2006-08-31 | 2015-05-19 | Red Hat, Inc. | Token Registration |
US9037866B1 (en) * | 2001-09-21 | 2015-05-19 | Open Invention Network, Llc | System and method for enrolling in a biometric system |
US9081948B2 (en) | 2007-03-13 | 2015-07-14 | Red Hat, Inc. | Configurable smartcard |
US20160105798A1 (en) * | 2013-05-24 | 2016-04-14 | Prashant Govind PAIMA | Process for authenticating an identity of a user |
US20160132681A1 (en) * | 2013-06-14 | 2016-05-12 | Nec Europe Ltd. | Method for performing a secure boot of a computing system and computing system |
US9684889B2 (en) | 1999-02-12 | 2017-06-20 | Identrust, Inc. | System and method for providing certification-related and other services |
US20170220808A1 (en) * | 2014-10-31 | 2017-08-03 | Hewlett Packard Enterprise Development Lp | System and method for vulnerability remediation verification |
US9769158B2 (en) | 2006-06-07 | 2017-09-19 | Red Hat, Inc. | Guided enrollment and login for token users |
US20190173900A1 (en) * | 2014-09-15 | 2019-06-06 | PerimeterX, Inc. | Analyzing client application behavior to detect anomalies and prevent access |
RU191690U1 (en) * | 2019-05-20 | 2019-08-15 | Закрытое акционерное общество "Особое Конструкторское Бюро Систем Автоматизированного Проектирования" | SPECIALIZED COMPUTER WITH HARDWARE DATA PROTECTION |
US12101409B1 (en) | 2024-02-21 | 2024-09-24 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
Families Citing this family (131)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7243853B1 (en) | 2001-12-04 | 2007-07-17 | Visa U.S.A. Inc. | Method and system for facilitating memory and application management on a secured token |
US8010405B1 (en) | 2002-07-26 | 2011-08-30 | Visa Usa Inc. | Multi-application smart card device software solution for smart cardholder reward selection and redemption |
US8626577B2 (en) | 2002-09-13 | 2014-01-07 | Visa U.S.A | Network centric loyalty system |
US9852437B2 (en) | 2002-09-13 | 2017-12-26 | Visa U.S.A. Inc. | Opt-in/opt-out in loyalty system |
US8015060B2 (en) | 2002-09-13 | 2011-09-06 | Visa Usa, Inc. | Method and system for managing limited use coupon and coupon prioritization |
US20040139021A1 (en) | 2002-10-07 | 2004-07-15 | Visa International Service Association | Method and system for facilitating data access and management on a secure token |
US7437562B2 (en) * | 2003-04-01 | 2008-10-14 | Oracle International Corporation | Method and apparatus for digitally signing electronic mail that originates from a browser |
US7827077B2 (en) | 2003-05-02 | 2010-11-02 | Visa U.S.A. Inc. | Method and apparatus for management of electronic receipts on portable devices |
US8554610B1 (en) | 2003-08-29 | 2013-10-08 | Visa U.S.A. Inc. | Method and system for providing reward status |
US7051923B2 (en) | 2003-09-12 | 2006-05-30 | Visa U.S.A., Inc. | Method and system for providing interactive cardholder rewards image replacement |
US8005763B2 (en) | 2003-09-30 | 2011-08-23 | Visa U.S.A. Inc. | Method and system for providing a distributed adaptive rules based dynamic pricing system |
US8407083B2 (en) | 2003-09-30 | 2013-03-26 | Visa U.S.A., Inc. | Method and system for managing reward reversal after posting |
US7653602B2 (en) | 2003-11-06 | 2010-01-26 | Visa U.S.A. Inc. | Centralized electronic commerce card transactions |
US7917761B2 (en) * | 2005-03-21 | 2011-03-29 | Microsoft Corporation | Digitally signing an electronic document with a user-entered signature image |
US20070162478A1 (en) * | 2006-01-06 | 2007-07-12 | Samsung Electronics Co., Ltd. | Method of achieving service configurability within telecommunication devices |
US8312497B2 (en) * | 2006-03-29 | 2012-11-13 | At&T Intellectual Property I, L.P. | Closed-captioning universal resource locator (URL) capture system and method |
US8082341B2 (en) * | 2006-03-30 | 2011-12-20 | Dell Products L.P. | ActiveX detection and handling in mozilla-based browsers |
US20080162362A1 (en) * | 2006-12-28 | 2008-07-03 | Microsoft Corporation | Increasing transaction authenticity with product license keys |
US9130974B2 (en) * | 2007-04-18 | 2015-09-08 | Mcafee, Inc. | System and method for limiting spyware activity |
US20080301055A1 (en) * | 2007-05-31 | 2008-12-04 | Microsoft Corporation | unified platform for reputation and secure transactions |
US9990439B2 (en) * | 2007-08-14 | 2018-06-05 | Nbcuniversal Media, Llc | Flexible method and system for providing digital content |
MX2010010150A (en) * | 2008-03-21 | 2010-10-25 | Koninkl Philips Electronics Nv | Method for displaying information generated by a client. |
US7992781B2 (en) | 2009-12-16 | 2011-08-09 | Visa International Service Association | Merchant alerts incorporating receipt data |
US8429048B2 (en) | 2009-12-28 | 2013-04-23 | Visa International Service Association | System and method for processing payment transaction receipts |
US20140207911A1 (en) * | 2013-01-22 | 2014-07-24 | James Kosmach | System and method for embedding multimedia controls and indications in a webpage |
CN103516687B (en) * | 2012-06-27 | 2016-08-17 | 中国银联股份有限公司 | Security information interaction system, Apparatus and method for |
US9354764B2 (en) | 2012-06-29 | 2016-05-31 | Dell Products L.P. | Playback of flash content at a client by redirecting execution of a script by a flash redirection plugin at a server to a flash redirection browser at the client |
US9626450B2 (en) * | 2012-06-29 | 2017-04-18 | Dell Products L.P. | Flash redirection with browser calls caching |
US9603015B2 (en) * | 2014-02-03 | 2017-03-21 | Empire Technology Development Llc | Encrypted communication between paired devices |
CN105323654B (en) * | 2014-08-05 | 2019-02-15 | 优视科技有限公司 | The method and apparatus for carrying out the content-data of automatic network is presented |
CN108829380B (en) * | 2018-05-31 | 2021-08-31 | 郑州云海信息技术有限公司 | Method and device for realizing consistency of plug-in acquired information |
US10546444B2 (en) | 2018-06-21 | 2020-01-28 | Capital One Services, Llc | Systems and methods for secure read-only authentication |
US10909527B2 (en) | 2018-10-02 | 2021-02-02 | Capital One Services, Llc | Systems and methods for performing a reissue of a contactless card |
US10505738B1 (en) | 2018-10-02 | 2019-12-10 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
KR20210065109A (en) | 2018-10-02 | 2021-06-03 | 캐피탈 원 서비시즈, 엘엘씨 | System and method for cryptographic authentication of contactless card |
US10582386B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072687A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072583A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for establishing identity for order pick up |
US10579998B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10771254B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for email-based card activation |
KR20210065961A (en) | 2018-10-02 | 2021-06-04 | 캐피탈 원 서비시즈, 엘엘씨 | System and method for cryptographic authentication of contactless card |
CA3115084A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10565587B1 (en) | 2018-10-02 | 2020-02-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10554411B1 (en) | 2018-10-02 | 2020-02-04 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
SG11202101874SA (en) | 2018-10-02 | 2021-03-30 | Capital One Services Llc | Systems and methods for cryptographic authentication of contactless cards |
US10771253B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10542036B1 (en) | 2018-10-02 | 2020-01-21 | Capital One Services, Llc | Systems and methods for signaling an attack on contactless cards |
US10489781B1 (en) | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
AU2019351911A1 (en) | 2018-10-02 | 2021-02-25 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10949520B2 (en) | 2018-10-02 | 2021-03-16 | Capital One Services, Llc | Systems and methods for cross coupling risk analytics and one-time-passcodes |
US10748138B2 (en) | 2018-10-02 | 2020-08-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10581611B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10607214B1 (en) | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10511443B1 (en) | 2018-10-02 | 2019-12-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
SG11202101171VA (en) | 2018-10-02 | 2021-03-30 | Capital One Services Llc | Systems and methods for cryptographic authentication of contactless cards |
WO2020072552A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US11210664B2 (en) | 2018-10-02 | 2021-12-28 | Capital One Services, Llc | Systems and methods for amplifying the strength of cryptographic algorithms |
JP2022502901A (en) | 2018-10-02 | 2022-01-11 | キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニーCapital One Services, LLC | Systems and methods for cryptographic authentication of non-contact cards |
US10592710B1 (en) | 2018-10-02 | 2020-03-17 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
CA3115107A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
CA3115142A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US10783519B2 (en) | 2018-10-02 | 2020-09-22 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
US20200226581A1 (en) | 2019-01-11 | 2020-07-16 | Capital One Services, Llc | Systems and methods for touch screen interface interaction using a card overlay |
US11037136B2 (en) | 2019-01-24 | 2021-06-15 | Capital One Services, Llc | Tap to autofill card data |
US10510074B1 (en) | 2019-02-01 | 2019-12-17 | Capital One Services, Llc | One-tap payment using a contactless card |
US11120453B2 (en) | 2019-02-01 | 2021-09-14 | Capital One Services, Llc | Tap card to securely generate card data to copy to clipboard |
US11082229B2 (en) | 2019-03-18 | 2021-08-03 | Capital One Services, Llc | System and method for pre-authentication of customer support calls |
US10643420B1 (en) | 2019-03-20 | 2020-05-05 | Capital One Services, Llc | Contextual tapping engine |
US10535062B1 (en) | 2019-03-20 | 2020-01-14 | Capital One Services, Llc | Using a contactless card to securely share personal data stored in a blockchain |
US10984416B2 (en) | 2019-03-20 | 2021-04-20 | Capital One Services, Llc | NFC mobile currency transfer |
US10970712B2 (en) | 2019-03-21 | 2021-04-06 | Capital One Services, Llc | Delegated administration of permissions using a contactless card |
US11521262B2 (en) | 2019-05-28 | 2022-12-06 | Capital One Services, Llc | NFC enhanced augmented reality information overlays |
US10516447B1 (en) | 2019-06-17 | 2019-12-24 | Capital One Services, Llc | Dynamic power levels in NFC card communications |
US11392933B2 (en) | 2019-07-03 | 2022-07-19 | Capital One Services, Llc | Systems and methods for providing online and hybridcard interactions |
US10871958B1 (en) | 2019-07-03 | 2020-12-22 | Capital One Services, Llc | Techniques to perform applet programming |
US11694187B2 (en) | 2019-07-03 | 2023-07-04 | Capital One Services, Llc | Constraining transactional capabilities for contactless cards |
US12086852B2 (en) | 2019-07-08 | 2024-09-10 | Capital One Services, Llc | Authenticating voice transactions with payment card |
US10713649B1 (en) | 2019-07-09 | 2020-07-14 | Capital One Services, Llc | System and method enabling mobile near-field communication to update display on a payment card |
US10885514B1 (en) | 2019-07-15 | 2021-01-05 | Capital One Services, Llc | System and method for using image data to trigger contactless card transactions |
US10733601B1 (en) | 2019-07-17 | 2020-08-04 | Capital One Services, Llc | Body area network facilitated authentication or payment authorization |
US10832271B1 (en) | 2019-07-17 | 2020-11-10 | Capital One Services, Llc | Verified reviews using a contactless card |
US11182771B2 (en) | 2019-07-17 | 2021-11-23 | Capital One Services, Llc | System for value loading onto in-vehicle device |
US11521213B2 (en) | 2019-07-18 | 2022-12-06 | Capital One Services, Llc | Continuous authentication for digital services based on contactless card positioning |
US10506426B1 (en) | 2019-07-19 | 2019-12-10 | Capital One Services, Llc | Techniques for call authentication |
US10541995B1 (en) | 2019-07-23 | 2020-01-21 | Capital One Services, Llc | First factor contactless card authentication system and method |
JP2023503795A (en) | 2019-10-02 | 2023-02-01 | キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー | Client Device Authentication Using Contactless Legacy Magnetic Stripe Data |
US11113685B2 (en) | 2019-12-23 | 2021-09-07 | Capital One Services, Llc | Card issuing with restricted virtual numbers |
US10733283B1 (en) | 2019-12-23 | 2020-08-04 | Capital One Services, Llc | Secure password generation and management using NFC and contactless smart cards |
US10885410B1 (en) | 2019-12-23 | 2021-01-05 | Capital One Services, Llc | Generating barcodes utilizing cryptographic techniques |
US11615395B2 (en) | 2019-12-23 | 2023-03-28 | Capital One Services, Llc | Authentication for third party digital wallet provisioning |
US10657754B1 (en) | 2019-12-23 | 2020-05-19 | Capital One Services, Llc | Contactless card and personal identification system |
US11651361B2 (en) | 2019-12-23 | 2023-05-16 | Capital One Services, Llc | Secure authentication based on passport data stored in a contactless card |
US10862540B1 (en) | 2019-12-23 | 2020-12-08 | Capital One Services, Llc | Method for mapping NFC field strength and location on mobile devices |
US10853795B1 (en) | 2019-12-24 | 2020-12-01 | Capital One Services, Llc | Secure authentication based on identity data stored in a contactless card |
US10664941B1 (en) | 2019-12-24 | 2020-05-26 | Capital One Services, Llc | Steganographic image encoding of biometric template information on a card |
US11200563B2 (en) | 2019-12-24 | 2021-12-14 | Capital One Services, Llc | Account registration using a contactless card |
US10757574B1 (en) | 2019-12-26 | 2020-08-25 | Capital One Services, Llc | Multi-factor authentication providing a credential via a contactless card for secure messaging |
US10909544B1 (en) | 2019-12-26 | 2021-02-02 | Capital One Services, Llc | Accessing and utilizing multiple loyalty point accounts |
US11038688B1 (en) | 2019-12-30 | 2021-06-15 | Capital One Services, Llc | Techniques to control applets for contactless cards |
US11455620B2 (en) | 2019-12-31 | 2022-09-27 | Capital One Services, Llc | Tapping a contactless card to a computing device to provision a virtual number |
US10860914B1 (en) | 2019-12-31 | 2020-12-08 | Capital One Services, Llc | Contactless card and method of assembly |
US11210656B2 (en) | 2020-04-13 | 2021-12-28 | Capital One Services, Llc | Determining specific terms for contactless card activation |
US10861006B1 (en) | 2020-04-30 | 2020-12-08 | Capital One Services, Llc | Systems and methods for data access control using a short-range transceiver |
US11222342B2 (en) | 2020-04-30 | 2022-01-11 | Capital One Services, Llc | Accurate images in graphical user interfaces to enable data transfer |
US11030339B1 (en) | 2020-04-30 | 2021-06-08 | Capital One Services, Llc | Systems and methods for data access control of personal user data using a short-range transceiver |
US11823175B2 (en) | 2020-04-30 | 2023-11-21 | Capital One Services, Llc | Intelligent card unlock |
US10915888B1 (en) | 2020-04-30 | 2021-02-09 | Capital One Services, Llc | Contactless card with multiple rotating security keys |
US10963865B1 (en) | 2020-05-12 | 2021-03-30 | Capital One Services, Llc | Augmented reality card activation experience |
US11063979B1 (en) | 2020-05-18 | 2021-07-13 | Capital One Services, Llc | Enabling communications between applications in a mobile operating system |
US11100511B1 (en) | 2020-05-18 | 2021-08-24 | Capital One Services, Llc | Application-based point of sale system in mobile operating systems |
US11062098B1 (en) | 2020-08-11 | 2021-07-13 | Capital One Services, Llc | Augmented reality information display and interaction via NFC based authentication |
US11165586B1 (en) | 2020-10-30 | 2021-11-02 | Capital One Services, Llc | Call center web-based authentication using a contactless card |
US11482312B2 (en) | 2020-10-30 | 2022-10-25 | Capital One Services, Llc | Secure verification of medical status using a contactless card |
US11373169B2 (en) | 2020-11-03 | 2022-06-28 | Capital One Services, Llc | Web-based activation of contactless cards |
US11216799B1 (en) | 2021-01-04 | 2022-01-04 | Capital One Services, Llc | Secure generation of one-time passcodes using a contactless card |
US11682012B2 (en) | 2021-01-27 | 2023-06-20 | Capital One Services, Llc | Contactless delivery systems and methods |
US11792001B2 (en) | 2021-01-28 | 2023-10-17 | Capital One Services, Llc | Systems and methods for secure reprovisioning |
US11562358B2 (en) | 2021-01-28 | 2023-01-24 | Capital One Services, Llc | Systems and methods for near field contactless card communication and cryptographic authentication |
US11687930B2 (en) | 2021-01-28 | 2023-06-27 | Capital One Services, Llc | Systems and methods for authentication of access tokens |
US11438329B2 (en) | 2021-01-29 | 2022-09-06 | Capital One Services, Llc | Systems and methods for authenticated peer-to-peer data transfer using resource locators |
US11777933B2 (en) | 2021-02-03 | 2023-10-03 | Capital One Services, Llc | URL-based authentication for payment cards |
US11637826B2 (en) | 2021-02-24 | 2023-04-25 | Capital One Services, Llc | Establishing authentication persistence |
US11245438B1 (en) | 2021-03-26 | 2022-02-08 | Capital One Services, Llc | Network-enabled smart apparatus and systems and methods for activating and provisioning same |
US11935035B2 (en) | 2021-04-20 | 2024-03-19 | Capital One Services, Llc | Techniques to utilize resource locators by a contactless card to perform a sequence of operations |
US11961089B2 (en) | 2021-04-20 | 2024-04-16 | Capital One Services, Llc | On-demand applications to extend web services |
US11902442B2 (en) | 2021-04-22 | 2024-02-13 | Capital One Services, Llc | Secure management of accounts on display devices using a contactless card |
US11354555B1 (en) | 2021-05-04 | 2022-06-07 | Capital One Services, Llc | Methods, mediums, and systems for applying a display to a transaction card |
US12041172B2 (en) | 2021-06-25 | 2024-07-16 | Capital One Services, Llc | Cryptographic authentication to control access to storage devices |
US12061682B2 (en) | 2021-07-19 | 2024-08-13 | Capital One Services, Llc | System and method to perform digital authentication using multiple channels of communication |
US12062258B2 (en) | 2021-09-16 | 2024-08-13 | Capital One Services, Llc | Use of a payment card to unlock a lock |
US12069173B2 (en) | 2021-12-15 | 2024-08-20 | Capital One Services, Llc | Key recovery based on contactless card authentication |
Citations (29)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4304990A (en) * | 1979-12-11 | 1981-12-08 | Atalla Technovations | Multilevel security apparatus and method |
US5048085A (en) * | 1989-10-06 | 1991-09-10 | International Business Machines Corporation | Transaction system security method and apparatus |
US5191193A (en) * | 1989-10-13 | 1993-03-02 | Gemplus Card International | System of payment or information transfer by money card with electronic memory |
US5353350A (en) * | 1989-10-03 | 1994-10-04 | University Of Technology | Electro-active cradle circuits for the detection of access or penetration |
US5389738A (en) * | 1992-05-04 | 1995-02-14 | Motorola, Inc. | Tamperproof arrangement for an integrated circuit device |
US5448045A (en) * | 1992-02-26 | 1995-09-05 | Clark; Paul C. | System for protecting computers via intelligent tokens or smart cards |
US5604801A (en) * | 1995-02-03 | 1997-02-18 | International Business Machines Corporation | Public key data communications system under control of a portable security device |
US5623637A (en) * | 1993-12-06 | 1997-04-22 | Telequip Corporation | Encrypted data storage card including smartcard integrated circuit for storing an access password and encryption keys |
US5659616A (en) * | 1994-07-19 | 1997-08-19 | Certco, Llc | Method for securely using digital signatures in a commercial cryptographic system |
US5668878A (en) * | 1994-02-28 | 1997-09-16 | Brands; Stefanus Alfonsus | Secure cryptographic methods for electronic transfer of information |
US5680455A (en) * | 1994-08-17 | 1997-10-21 | International Business Machines Corporation | Digital signature generator /verifier/ recorder (DS-GVR) for analog transmissions |
US5694471A (en) * | 1994-08-03 | 1997-12-02 | V-One Corporation | Counterfeit-proof identification card |
US5717989A (en) * | 1994-10-13 | 1998-02-10 | Full Service Trade System Ltd. | Full service trade system |
US5721781A (en) * | 1995-09-13 | 1998-02-24 | Microsoft Corporation | Authentication system and method for smart card transactions |
US5745571A (en) * | 1992-03-30 | 1998-04-28 | Telstra Corporation Limited | Cryptographic communications method and system |
US5841866A (en) * | 1994-09-30 | 1998-11-24 | Microchip Technology Incorporated | Secure token integrated circuit and method of performing a secure authentication function or transaction |
US5847374A (en) * | 1995-04-26 | 1998-12-08 | France Telecom | Smart card having a plurality of data fields with reference zones and validation bits |
US5850442A (en) * | 1996-03-26 | 1998-12-15 | Entegrity Solutions Corporation | Secure world wide electronic commerce over an open network |
US5861662A (en) * | 1997-02-24 | 1999-01-19 | General Instrument Corporation | Anti-tamper bond wire shield for an integrated circuit |
US5937068A (en) * | 1996-03-22 | 1999-08-10 | Activcard | System and method for user authentication employing dynamic encryption variables |
US5956404A (en) * | 1996-09-30 | 1999-09-21 | Schneier; Bruce | Digital signature with auditing bits |
US5987440A (en) * | 1996-07-22 | 1999-11-16 | Cyva Research Corporation | Personal information security and exchange tool |
US6035402A (en) * | 1996-12-20 | 2000-03-07 | Gte Cybertrust Solutions Incorporated | Virtual certificate authority |
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 |
US6067621A (en) * | 1996-10-05 | 2000-05-23 | Samsung Electronics Co., Ltd. | User authentication system for authenticating an authorized user of an IC card |
US6170058B1 (en) * | 1997-12-23 | 2001-01-02 | Arcot Systems, Inc. | Method and apparatus for cryptographically camouflaged cryptographic key storage, certification and use |
US6233339B1 (en) * | 1996-10-25 | 2001-05-15 | Fuji Xerox Co., Ltd. | Physical property based cryptographics |
US6304658B1 (en) * | 1998-01-02 | 2001-10-16 | Cryptography Research, Inc. | Leak-resistant cryptographic method and apparatus |
US6510518B1 (en) * | 1998-06-03 | 2003-01-21 | Cryptography Research, Inc. | Balanced cryptographic computational method and apparatus for leak minimizational in smartcards and other cryptosystems |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH08214281A (en) * | 1995-02-06 | 1996-08-20 | Sony Corp | Charging method and system |
US5842211A (en) * | 1996-03-15 | 1998-11-24 | Microsoft Corporation | Method and system for transferring a bank file to an application program |
US5944789A (en) * | 1996-08-14 | 1999-08-31 | Emc Corporation | Network file server maintaining local caches of file directory information in data mover computers |
US6385651B2 (en) * | 1998-05-05 | 2002-05-07 | Liberate Technologies | Internet service provider preliminary user registration mechanism provided by centralized authority |
US6363479B1 (en) * | 1998-07-22 | 2002-03-26 | Entrust Technologies Limited | System and method for signing markup language data |
US6085321A (en) * | 1998-08-14 | 2000-07-04 | Omnipoint Corporation | Unique digital signature |
-
2001
- 2001-08-14 AU AU2001284882A patent/AU2001284882A1/en not_active Abandoned
- 2001-08-14 AU AU2001286464A patent/AU2001286464A1/en not_active Abandoned
- 2001-08-14 US US09/928,999 patent/US20020112156A1/en not_active Abandoned
- 2001-08-14 EP EP01963973A patent/EP1323061A1/en not_active Withdrawn
- 2001-08-14 US US09/929,035 patent/US7165178B2/en not_active Expired - Lifetime
- 2001-08-14 WO PCT/US2001/025389 patent/WO2002015037A1/en active Application Filing
- 2001-08-14 WO PCT/US2001/025385 patent/WO2002015464A1/en active Application Filing
Patent Citations (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4304990A (en) * | 1979-12-11 | 1981-12-08 | Atalla Technovations | Multilevel security apparatus and method |
US5353350A (en) * | 1989-10-03 | 1994-10-04 | University Of Technology | Electro-active cradle circuits for the detection of access or penetration |
US5048085A (en) * | 1989-10-06 | 1991-09-10 | International Business Machines Corporation | Transaction system security method and apparatus |
US5191193A (en) * | 1989-10-13 | 1993-03-02 | Gemplus Card International | System of payment or information transfer by money card with electronic memory |
US5448045A (en) * | 1992-02-26 | 1995-09-05 | Clark; Paul C. | System for protecting computers via intelligent tokens or smart cards |
US5745571A (en) * | 1992-03-30 | 1998-04-28 | Telstra Corporation Limited | Cryptographic communications method and system |
US5389738A (en) * | 1992-05-04 | 1995-02-14 | Motorola, Inc. | Tamperproof arrangement for an integrated circuit device |
US5406630A (en) * | 1992-05-04 | 1995-04-11 | Motorola, Inc. | Tamperproof arrangement for an integrated circuit device |
US5623637A (en) * | 1993-12-06 | 1997-04-22 | Telequip Corporation | Encrypted data storage card including smartcard integrated circuit for storing an access password and encryption keys |
US5668878A (en) * | 1994-02-28 | 1997-09-16 | Brands; Stefanus Alfonsus | Secure cryptographic methods for electronic transfer of information |
US5659616A (en) * | 1994-07-19 | 1997-08-19 | Certco, Llc | Method for securely using digital signatures in a commercial cryptographic system |
US5694471A (en) * | 1994-08-03 | 1997-12-02 | V-One Corporation | Counterfeit-proof identification card |
US5680455A (en) * | 1994-08-17 | 1997-10-21 | International Business Machines Corporation | Digital signature generator /verifier/ recorder (DS-GVR) for analog transmissions |
US5841866A (en) * | 1994-09-30 | 1998-11-24 | Microchip Technology Incorporated | Secure token integrated circuit and method of performing a secure authentication function or transaction |
US5717989A (en) * | 1994-10-13 | 1998-02-10 | Full Service Trade System Ltd. | Full service trade system |
US5604801A (en) * | 1995-02-03 | 1997-02-18 | International Business Machines Corporation | Public key data communications system under control of a portable security device |
US5847374A (en) * | 1995-04-26 | 1998-12-08 | France Telecom | Smart card having a plurality of data fields with reference zones and validation bits |
US5721781A (en) * | 1995-09-13 | 1998-02-24 | Microsoft Corporation | Authentication system and method for smart card transactions |
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 |
US5937068A (en) * | 1996-03-22 | 1999-08-10 | Activcard | System and method for user authentication employing dynamic encryption variables |
US5850442A (en) * | 1996-03-26 | 1998-12-15 | Entegrity Solutions Corporation | Secure world wide electronic commerce over an open network |
US5987440A (en) * | 1996-07-22 | 1999-11-16 | Cyva Research Corporation | Personal information security and exchange tool |
US5956404A (en) * | 1996-09-30 | 1999-09-21 | Schneier; Bruce | Digital signature with auditing bits |
US6067621A (en) * | 1996-10-05 | 2000-05-23 | Samsung Electronics Co., Ltd. | User authentication system for authenticating an authorized user of an IC card |
US6233339B1 (en) * | 1996-10-25 | 2001-05-15 | Fuji Xerox Co., Ltd. | Physical property based cryptographics |
US6035402A (en) * | 1996-12-20 | 2000-03-07 | Gte Cybertrust Solutions Incorporated | Virtual certificate authority |
US5861662A (en) * | 1997-02-24 | 1999-01-19 | General Instrument Corporation | Anti-tamper bond wire shield for an integrated circuit |
US6170058B1 (en) * | 1997-12-23 | 2001-01-02 | Arcot Systems, Inc. | Method and apparatus for cryptographically camouflaged cryptographic key storage, certification and use |
US6304658B1 (en) * | 1998-01-02 | 2001-10-16 | Cryptography Research, Inc. | Leak-resistant cryptographic method and apparatus |
US6510518B1 (en) * | 1998-06-03 | 2003-01-21 | Cryptography Research, Inc. | Balanced cryptographic computational method and apparatus for leak minimizational in smartcards and other cryptosystems |
Cited By (88)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9684889B2 (en) | 1999-02-12 | 2017-06-20 | Identrust, Inc. | System and method for providing certification-related and other services |
US8818903B2 (en) | 1999-09-10 | 2014-08-26 | Charles Dulin | Transaction coordinator for digital certificate validation and other services |
US7765161B2 (en) | 1999-09-24 | 2010-07-27 | Identrust, Inc. | System and method for providing payment services in electronic commerce |
US20150012428A1 (en) * | 2000-01-05 | 2015-01-08 | Iii Holdings 1, Llc | Smartcard internet authorization system |
US8892475B2 (en) | 2000-09-08 | 2014-11-18 | Identrust, Inc. | Provision of authorization and other services |
US7734924B2 (en) | 2000-09-08 | 2010-06-08 | Identrust, Inc. | System and method for transparently providing certificate validation and other services within an electronic transaction |
US7162736B2 (en) * | 2001-08-20 | 2007-01-09 | Schlumberger Omnes, Inc. | Remote unblocking with a security agent |
US20030037259A1 (en) * | 2001-08-20 | 2003-02-20 | Koistinen Martin J. | Remote unblocking with a security agent |
US7779267B2 (en) * | 2001-09-04 | 2010-08-17 | Hewlett-Packard Development Company, L.P. | Method and apparatus for using a secret in a distributed computing system |
US20030046542A1 (en) * | 2001-09-04 | 2003-03-06 | Hewlett-Packard Company | Method and apparatus for using a secret in a distributed computing system |
US9037866B1 (en) * | 2001-09-21 | 2015-05-19 | Open Invention Network, Llc | System and method for enrolling in a biometric system |
US9544309B1 (en) * | 2001-09-21 | 2017-01-10 | Open Invention Network, Llc | System and method for enrolling in a biometric system |
US9864992B1 (en) * | 2001-09-21 | 2018-01-09 | Open Invention Network, Llc | System and method for enrolling in a biometric system |
US20030115455A1 (en) * | 2001-12-19 | 2003-06-19 | Aull Kenneth W. | Method and apparatus for centralized processing of hardware tokens for PKI solutions |
US7484089B1 (en) * | 2002-09-06 | 2009-01-27 | Citicorp Developmemt Center, Inc. | Method and system for certificate delivery and management |
US20070055872A1 (en) * | 2003-11-10 | 2007-03-08 | Japan Science And Technology Agency | Secure processor |
US20080016565A1 (en) * | 2004-08-17 | 2008-01-17 | Alan Mushing | Compliance Assessment And Security Testing Of Smart Cards |
US20060095963A1 (en) * | 2004-10-29 | 2006-05-04 | Simon Crosby | Collaborative attack detection in networks |
US20060242711A1 (en) * | 2005-04-25 | 2006-10-26 | Kousuke Anzai | Tool, method, and program for supporting system security design/evaluation |
US7748041B2 (en) * | 2005-04-25 | 2010-06-29 | Hitachi, Ltd. | Tool, method, and program for supporting system security design/evaluation |
US8181232B2 (en) | 2005-07-29 | 2012-05-15 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US20070050840A1 (en) * | 2005-07-29 | 2007-03-01 | Michael Grandcolas | Methods and systems for secure user authentication |
US11917069B1 (en) | 2005-12-09 | 2024-02-27 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
US11394553B1 (en) | 2005-12-09 | 2022-07-19 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
US9768963B2 (en) | 2005-12-09 | 2017-09-19 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
US7904946B1 (en) | 2005-12-09 | 2011-03-08 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US20110197266A1 (en) * | 2005-12-09 | 2011-08-11 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
US9002750B1 (en) | 2005-12-09 | 2015-04-07 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
US20080320315A1 (en) * | 2005-12-23 | 2008-12-25 | Trusted Logic | Method for Creating a Secure Counter on an On-Board Computer System Comprising a Chip Card |
US8082450B2 (en) * | 2005-12-23 | 2011-12-20 | Trusted Logic | Method for creating a secure counter on an on-board computer system comprising a chip card |
US7873835B2 (en) * | 2006-03-31 | 2011-01-18 | Emc Corporation | Accessing data storage devices |
US20070239988A1 (en) * | 2006-03-31 | 2007-10-11 | Yedidia Atzmony | Accessing data storage devices |
US7992203B2 (en) | 2006-05-24 | 2011-08-02 | Red Hat, Inc. | Methods and systems for secure shared smartcard access |
US8495380B2 (en) | 2006-06-06 | 2013-07-23 | Red Hat, Inc. | Methods and systems for server-side key generation |
US20070280483A1 (en) * | 2006-06-06 | 2007-12-06 | Red Hat, Inc. | Methods and systems for key recovery for a token |
US8098829B2 (en) * | 2006-06-06 | 2012-01-17 | Red Hat, Inc. | Methods and systems for secure key delivery |
US9450763B2 (en) | 2006-06-06 | 2016-09-20 | Red Hat, Inc. | Server-side key generation |
US8180741B2 (en) | 2006-06-06 | 2012-05-15 | Red Hat, Inc. | Methods and systems for providing data objects on a token |
US7822209B2 (en) * | 2006-06-06 | 2010-10-26 | Red Hat, Inc. | Methods and systems for key recovery for a token |
US8332637B2 (en) | 2006-06-06 | 2012-12-11 | Red Hat, Inc. | Methods and systems for nonce generation in a token |
US20080022088A1 (en) * | 2006-06-06 | 2008-01-24 | Red Hat, Inc. | Methods and systems for key escrow |
US8364952B2 (en) | 2006-06-06 | 2013-01-29 | Red Hat, Inc. | Methods and system for a key recovery plan |
US8762350B2 (en) | 2006-06-06 | 2014-06-24 | Red Hat, Inc. | Methods and systems for providing data objects on a token |
US20080019526A1 (en) * | 2006-06-06 | 2008-01-24 | Red Hat, Inc. | Methods and systems for secure key delivery |
US8412927B2 (en) | 2006-06-07 | 2013-04-02 | Red Hat, Inc. | Profile framework for token processing system |
US9769158B2 (en) | 2006-06-07 | 2017-09-19 | Red Hat, Inc. | Guided enrollment and login for token users |
US20070288745A1 (en) * | 2006-06-07 | 2007-12-13 | Nang Kon Kwan | Profile framework for token processing system |
US8099765B2 (en) | 2006-06-07 | 2012-01-17 | Red Hat, Inc. | Methods and systems for remote password reset using an authentication credential managed by a third party |
US8589695B2 (en) | 2006-06-07 | 2013-11-19 | Red Hat, Inc. | Methods and systems for entropy collection for server-side key generation |
US8707024B2 (en) | 2006-06-07 | 2014-04-22 | Red Hat, Inc. | Methods and systems for managing identity management security domains |
US20080082354A1 (en) * | 2006-08-11 | 2008-04-03 | Hurry Simon J | Compliance assessment reporting service |
WO2008022086A3 (en) * | 2006-08-11 | 2008-12-18 | Visa Int Service Ass | Compliance assessment reporting service |
WO2008022086A2 (en) * | 2006-08-11 | 2008-02-21 | Visa International Service Association | Compliance assessment reporting service |
US8787566B2 (en) | 2006-08-23 | 2014-07-22 | Red Hat, Inc. | Strong encryption |
US8806219B2 (en) | 2006-08-23 | 2014-08-12 | Red Hat, Inc. | Time-based function back-off |
US8977844B2 (en) | 2006-08-31 | 2015-03-10 | Red Hat, Inc. | Smartcard formation with authentication keys |
US8356342B2 (en) | 2006-08-31 | 2013-01-15 | Red Hat, Inc. | Method and system for issuing a kill sequence for a token |
US9762572B2 (en) | 2006-08-31 | 2017-09-12 | Red Hat, Inc. | Smartcard formation with authentication |
US9038154B2 (en) | 2006-08-31 | 2015-05-19 | Red Hat, Inc. | Token Registration |
US8074265B2 (en) | 2006-08-31 | 2011-12-06 | Red Hat, Inc. | Methods and systems for verifying a location factor associated with a token |
US8693690B2 (en) | 2006-12-04 | 2014-04-08 | Red Hat, Inc. | Organizing an extensible table for storing cryptographic objects |
US8813243B2 (en) | 2007-02-02 | 2014-08-19 | Red Hat, Inc. | Reducing a size of a security-related data object stored on a token |
US20100027798A1 (en) * | 2007-02-08 | 2010-02-04 | Smartmachine International Holding Gmbh | Method and apparatus for storage of secure information, which is required for short-range communication, on a communication terminal |
US8832453B2 (en) | 2007-02-28 | 2014-09-09 | Red Hat, Inc. | Token recycling |
US8639940B2 (en) | 2007-02-28 | 2014-01-28 | Red Hat, Inc. | Methods and systems for assigning roles on a token |
US9081948B2 (en) | 2007-03-13 | 2015-07-14 | Red Hat, Inc. | Configurable smartcard |
US20100299748A1 (en) * | 2007-12-10 | 2010-11-25 | Telefonaktiebolaget L M Ericsson (Publ) | Method for alteration of integrity protected data in a device, computer program product and device implementing the method |
US8793487B2 (en) | 2008-01-18 | 2014-07-29 | Identrust, Inc. | Binding a digital certificate to multiple trust domains |
US8190906B1 (en) * | 2008-12-16 | 2012-05-29 | Emc Corporation | Method and apparatus for testing authentication tokens |
US20100325039A1 (en) * | 2009-04-28 | 2010-12-23 | Mastercard International Incorporated | Apparatus, method, and computer program product for encoding enhanced issuer information in a card |
US8401964B2 (en) * | 2009-04-28 | 2013-03-19 | Mastercard International Incorporated | Apparatus, method, and computer program product for encoding enhanced issuer information in a card |
US9195858B2 (en) * | 2009-08-04 | 2015-11-24 | Seagate Technology Llc | Encrypted data storage device |
US20110035813A1 (en) * | 2009-08-04 | 2011-02-10 | Seagate Technology Llc | Encrypted data storage device |
US8861005B2 (en) * | 2012-09-28 | 2014-10-14 | Interactive Memories, Inc. | Methods for real time discovery, selection, and engagement of most economically feasible printing service vendors among multiple known vendors |
US20140092424A1 (en) * | 2012-09-28 | 2014-04-03 | Interactive Memories, Inc. | Methods for Real Time Discovery, Selection, and Engagement of Most Economically Feasible Printing Service Vendors among Multiple Known Vendors |
WO2014081494A1 (en) * | 2012-11-20 | 2014-05-30 | Ebay Inc. | Systems and methods for generating and using a token for use in a transaction |
US20160105798A1 (en) * | 2013-05-24 | 2016-04-14 | Prashant Govind PAIMA | Process for authenticating an identity of a user |
US10051468B2 (en) * | 2013-05-24 | 2018-08-14 | Prashant G. Paima | Process for authenticating an identity of a user |
US20160132681A1 (en) * | 2013-06-14 | 2016-05-12 | Nec Europe Ltd. | Method for performing a secure boot of a computing system and computing system |
US10708287B2 (en) * | 2014-09-15 | 2020-07-07 | PerimeterX, Inc. | Analyzing client application behavior to detect anomalies and prevent access |
US20190173900A1 (en) * | 2014-09-15 | 2019-06-06 | PerimeterX, Inc. | Analyzing client application behavior to detect anomalies and prevent access |
US11606374B2 (en) * | 2014-09-15 | 2023-03-14 | PerimeterX, Inc. | Analyzing client application behavior to detect anomalies and prevent access |
US20230188555A1 (en) * | 2014-09-15 | 2023-06-15 | PerimeterX, Inc. | Analyzing client application behavior to detect anomalies and prevent access |
US11924234B2 (en) * | 2014-09-15 | 2024-03-05 | PerimeterX, Inc. | Analyzing client application behavior to detect anomalies and prevent access |
US10503909B2 (en) * | 2014-10-31 | 2019-12-10 | Hewlett Packard Enterprise Development Lp | System and method for vulnerability remediation verification |
US20170220808A1 (en) * | 2014-10-31 | 2017-08-03 | Hewlett Packard Enterprise Development Lp | System and method for vulnerability remediation verification |
RU191690U1 (en) * | 2019-05-20 | 2019-08-15 | Закрытое акционерное общество "Особое Конструкторское Бюро Систем Автоматизированного Проектирования" | SPECIALIZED COMPUTER WITH HARDWARE DATA PROTECTION |
US12101409B1 (en) | 2024-02-21 | 2024-09-24 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
Also Published As
Publication number | Publication date |
---|---|
WO2002015464A1 (en) | 2002-02-21 |
WO2002015037A1 (en) | 2002-02-21 |
EP1323061A1 (en) | 2003-07-02 |
AU2001284882A1 (en) | 2002-02-25 |
US7165178B2 (en) | 2007-01-16 |
AU2001286464A1 (en) | 2002-02-25 |
US20020165827A1 (en) | 2002-11-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20020112156A1 (en) | System and method for secure smartcard issuance | |
ES2599985T3 (en) | Validation at any time for verification tokens | |
US7257708B2 (en) | Steganographic authentication | |
CA2838763C (en) | Credential authentication methods and systems | |
JP5608081B2 (en) | Apparatus and method for conducting secure financial transactions | |
US6950942B2 (en) | Integrated circuit device with data modifying capabilities and related methods | |
US20090198618A1 (en) | Device and method for loading managing and using smartcard authentication token and digital certificates in e-commerce | |
CN103051451A (en) | Encryption authentication of security service execution environment | |
WO2007010333A1 (en) | Host security module using a collection of smartcards | |
AU8545398A (en) | Method for managing a secure terminal | |
Petri | An introduction to smart cards | |
Infrastructure et al. | Common criteria for information technology security evaluation | |
AU2015200701B2 (en) | Anytime validation for verification tokens | |
KOMSCO | KOMSCO JK31 V1. 0 on M7892 (SLE78CLFX4000PM/SLE78CAFX4000PM) Security Target Lite | |
Giessmann | Specification of the Security Target TCOS Identity Card Version 1.0 Release 1/P5CD128/145-FSV02 Version: 1.0. 1/20110114 | |
Autor et al. | Specification of the Security Target TCOS Identity Card Version 1.0 Release 2/SLE78CLX1440P Version: 1.0. 2/20120712 | |
Gobio et al. | Smart Cards in Hostile Environments | |
Ayad et al. | An Authentication Method for Secure Internet Transaction Using Smart Card and Secure Coprocessor | |
Autor et al. | Specification of the Security Target TCOS Residence Permit Card Version 1.1 Release 1-PI/SLE78CLX1440P Version: 1.1. 1/20141124 | |
Autor et al. | Specification of the Security Target TCOS Residence Permit Card Version 1.0 Release 1/SLE78CLX1440P Version: 1.0. 1/20110816 | |
Karger et al. | Design of a Secure Smart Card Operating System for Pervasive Applications | |
Teo | Trusted Computing | |
Giessmann | Specification of the Security Target TCOS Passport Version 2.0 Release 2/P5CD080V0B Identity Card with Extended Access Control | |
Autor et al. | Specification of the Security Target TCOS Residence Permit Card Version 1.1 Release 1/SLE78CLX1440P Version: 1.1. 1/20130913 | |
PUB et al. | Federal Information Processing Standards Publication 190 1994 September 28 ANNOUNCING THE GUIDELINE FOR THE USE OF ADVANCED AUTHENTICATION TECHNOLOGY ALTERNATIVES |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SECUDE SICHERHEITS TECHNOLOGIE INFORMATIONS SYSTEM Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HETSCHOLD, THOMAS;REEL/FRAME:012917/0477 Effective date: 20020313 Owner name: IDENTRUS LLC, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GIEN, PETER H.;REEL/FRAME:012918/0251 Effective date: 20020317 |
|
AS | Assignment |
Owner name: ZIONS BANCORPORATION, UTAH Free format text: SECUIRTY AGREEMENT;ASSIGNOR:IDENTRUS, LLC;REEL/FRAME:015932/0591 Effective date: 20050314 |
|
AS | Assignment |
Owner name: IDENTRUS, LLC, NEW YORK Free format text: CHANGE OF NAME;ASSIGNOR:IDENTRUS, LLC;REEL/FRAME:016542/0732 Effective date: 20050708 |
|
AS | Assignment |
Owner name: IDENTRUS, INC. (SUCCESSOR-IN-INTEREST TO INDENTRUS Free format text: RELEASE OF SECURITY AGREEMENT;ASSIGNOR:ZIONS BANCORPORATION;REEL/FRAME:016890/0162 Effective date: 20050921 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |