US20020016913A1 - Modifying message data and generating random number digital signature within computer chip - Google Patents
Modifying message data and generating random number digital signature within computer chip Download PDFInfo
- Publication number
- US20020016913A1 US20020016913A1 US09/923,075 US92307501A US2002016913A1 US 20020016913 A1 US20020016913 A1 US 20020016913A1 US 92307501 A US92307501 A US 92307501A US 2002016913 A1 US2002016913 A1 US 2002016913A1
- Authority
- US
- United States
- Prior art keywords
- data
- verification
- digital signature
- message
- indicator
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- 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/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
-
- 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/085—Payment architectures involving remote charge determination or related payment systems
- G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving 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
- 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
- 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/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/3676—Balancing accounts
-
- 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/3821—Electronic credentials
-
- 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/385—Payment protocols; Details thereof using an alias or single-use codes
-
- 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/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/403—Solvency checks
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/409—Device specific authentication in transaction processing
- G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
- G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
-
- 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
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/18—Legal services; Handling legal documents
- G06Q50/188—Electronic negotiation
-
- 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/0873—Details of the card reader
- G07F7/088—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself
- G07F7/0886—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself the card reader being portable for interacting with a POS or ECR in realizing a payment transaction
-
- 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
-
- 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/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
-
- 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- 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/2113—Multi-level security, e.g. mandatory access control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/42—Anonymization, e.g. involving pseudonyms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- the present invention generally relates to entity authentication and, in particular, to entity authentication in the field of electronic communications.
- an electronic communication is considered to be any communication in electronic form. ECs have become an integral part of transacting business today, especially with the growth of the Internet and e-commerce.
- An EC can represent, for example, a request for access to information or a physical area, a financial transaction, such as an instruction to a bank to transfer funds, or a legal action, such as the delivery of an executed contract.
- the origination of a digital signature generally comprises: (1) the calculation of a message digest—such as a hash value; and (2) the subsequent encryption of the message digest.
- the message digest is encrypted by an electronic device generally using a private key of a key pair used in public-private key cryptography (also known as asymmetric cryptography).
- the resulting ciphertext itself usually constitutes the digital signature, which typically is appended to the message to form the EC.
- digital signatures are important because any change whatsoever to the message in an EC is detectable from an analysis of the message and the digital signature. In this regard, the digital signature is used to “authenticate” a message contained within the EC (hereinafter referred to as “Message Authentication”).
- a message digest may be calculated by applying a hashing algorithm—such as the SHA-1 algorithm—to the message.
- the hashing algorithm may be applied either within the device or external to the device with the resulting hash value then being transmitted to the device for generation of the digital signature.
- the recipient of the EC must know or be able to obtain both the identity of the hashing algorithm applied to the message as well as the public key (“PuK”) corresponding to the private key used to encrypt the message digest. With this knowledge, the recipient applies the appropriate hashing algorithm to the message to calculate a hash value, and the recipient decrypts the digital signature using the public key. If the hash value calculated by the recipient equals the hash value of the decrypted digital signature, then the recipient determines that the content of the message contained in the EC was not altered in transmission, which necessarily would have changed the hash value.
- a hashing algorithm such as the SHA-1 algorithm
- the recipient In performing Message Authentication, the recipient also authenticates the sender of the EC, in so much as the recipient thereby confirms that the sender of the EC possessed the private key corresponding to the public key used successfully to authenticate the message.
- This is one type of entity authentication and is based on what the sender “has” (hereinafter referred to as “Factor A Entity Authentication”).
- Factor A Entity Authentication is useful when the recipient of the EC has trusted information regarding the identity of the owner of the private key. Such trusted information may arise from a digital certificate issued by a trusted third party that accompanies the EC and binds the identity of the private key owner with the public key.
- This trusted knowledge also may comprise actual knowledge of the identity of the private key owner, such as in the case where the recipient itself has issued the private key or device containing the private key to the owner.
- devices are manufactured with electronic shielding, zeroization, auditing, tamper evidence and tamper response, and other security features that safeguard the private key (and other protected data) contained therein.
- security features include hardware, software, and firmware and are well known in the art of manufacturing secure computer chips and other devices having cryptographic modules.
- FIPS PUB 140-1 and 140-2 also define security levels that may be met by a device based on the device's security features, with each of these defined security levels generally representing a various level of difficulty—in terms of time and money—that would be encountered in attempting to discern a private key of a device.
- security level 4 is the highest level of security available.
- a personal identification number PIN
- password password
- passphrase (collectively referred to herein as “Secret”)
- the Secret is typically prestored within the device and must be input into the device before it will operate to generate digital signatures.
- the Secret is shared with the recipient beforehand and, when the EC later is sent to the recipient, the Secret also is sent to the recipient in association with the message.
- Verification of the Secret authenticates the user of the device (hereinafter “User Authentication”)
- Sender Authentication verification of the Secret authenticates the sender of the EC
- confirmation of the Secret represents entity authentication based on what the user or sender “knows” (hereinafter “Factor B Entity Authentication”).
- Another countermeasure against fraudulent use of the device through physical theft includes the verification of a biometric characteristic—like a fingerprint—of the user of the device or sender of the EC. This type of authentication is based on what the user or sender “is” (hereinafter “Factor C Entity Authentication”). As with the Secret, a biometric value is either maintained within the device for User Authentication, or is shared with the recipient beforehand for Sender Authentication by the recipient.
- Factor B Entity Authentication and Factor C Entity Authentication both reduce the risk of a fraudulent use of a device to generate a digital signature for a message, both also include significant drawbacks. For instance, if the Secret or biometric value is communicated to the recipient in association with a message for sender authentication by the recipient, then the Secret or biometric value first must have been shared with the recipient beforehand and safeguarded by the recipient as part of an established relationship. This conventional paradigm therefore precludes both Factor B Entity Authentication and Factor C Entity Authentication between entities having no such preexisting relationship.
- This paradigm also exposes the Secret or biometric value itself to a greater risk of theft.
- the transmission of the Secret or biometric value for verification carries with it the risk of interception and discovery during transit.
- the Secret or biometric value must be safeguarded by the recipient, thereby exposing the Secret to theft from the recipient. This is especially significant in the corporate context where a rogue employee may steal the safeguarded Secret or biometric value (insider fraud historically has been the greatest risk).
- a drawback to this alternative paradigm is that because the device remains inoperable until the correct Secret or biometric value of the user is entered, the recipient is unable to monitor repeated attempts to guess the Secret or biometric value. Furthermore, when the device is enabled by the entry of the correct Secret or a biometric value resulting in a match, the device typically remains enabled for a predefined period of time thereafter, such as until it is powered off or resets. Under this alternative paradigm, a recipient is unable to determine whether a particular EC sent during such a time period includes a fraudulently generated digital signature, as the device may have been stolen after being enabled but before its deactivation. Accordingly, while there is User Authentication under this alternative paradigm, there is no provision per se for Sender Authentication.
- this alternative paradigm does not particularly accommodate the use of the device to send ECs to different recipients when a biometric value is prestored and maintained within—and Factor C Entity Authentication is performed by—the device.
- different recipients may have different requirements as to what constitutes a biometric “match” so as to be a successful verification; a biometric match is a determination of whether a biometric value input is sufficiently close to a stored biometric value so as to meet at least a minimum security threshold.
- a security threshold is subjectively set by each recipient and includes factors such as the nature of the communication and the extent of liability to the recipient for actions and responses based on a fraudulently sent EC.
- a first aspect of the present invention relates to the provision of a verification status of a device and includes the steps of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of verification data input into the device and data prestored within the device; and, independent of the verification status identified, transmitting the identified verification status to an electronic apparatus external to the device.
- One of the predefined verification statuses is representative of the verification data being the same as the prestored data, and at least one other verification status is representative of the verification data being different from the prestored data.
- An indicator of the identified verification status is output from the device.
- the verification status regards an entity authentication using a device.
- This variation includes the steps of receiving within the device input comprising verification data of an entity; identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of the verification data and data prestored within the device; and, independent of the verification status identified, outputting from the device an indicator of the identified verification status.
- one of the predefined verification statuses being representative of the verification data being the same as the prestored data, and at least one other verification status being representative of the verification data being different from the prestored data.
- a first entity is authenticated to a second entity.
- data of the first entity is stored within a verification component of a device during a personalization of the verification component. Later, verification data is input into the device and received within the verification component of the device, and a current verification status is identified as a function of the verification data and prestored data within the verification component of the device.
- the verification status identified is one out of a plurality of predefined verification statuses of the device that include a verification status representative of the verification data being the same as the prestored data, and at least one other verification status representative of the verification data being different from the prestored data. Independent of the verification status identified, such verification status is communicated to the second entity.
- the verification status is communicated to the second entity by outputting an indicator of the verification status from the verification component and transmitting the output indicator to the second entity.
- a verification status regarding an entity authentication wherein no verification data is yet received by a device.
- the method in this case includes the steps of maintaining within the device prestored data of an entity for identifying a verification status of the device as a function of the prestored data and verification data later input into the device; identifying within the device a current verification status of the device representing the lack of input of any verification data during a predefined period of time; and outputting from the device an indicator of the identified verification status for evaluation thereof.
- a current verification status is identified within the device out of a plurality of predefined verification statuses of the device by comparing the received verification data with the prestored data; and an indicator of the identified verification status is again output from the device for evaluation thereof, wherein the second indicator reveals the identified verification status based on the comparison.
- one verification status out of the plurality of predefined verification statuses of the device is representative of the verification data being the same as the prestored data, and at least one other predefined verification status is representative of the verification data being different from the prestored data.
- the prestored data represents either a Secret or biometric characteristic, or both;
- the verification status identified as the current verification status represents a relational correspondence between the verification data and the prestored data without revealing either of the verification data or the prestored data; and the device is capable of generating digital signatures. Additionally, a request is evaluated with business logic based on the identified verification status.
- a second aspect of the present invention relates to the provision of a verification status of a device and includes the steps of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of biometric verification data input into the device and biometric data prestored within the device; and, independent of the verification status identified, transmitting an indicator of the identified verification status to an electronic apparatus external to the device, the indicator revealing the identified verification status without revealing either of the verification data or the prestored data.
- the indicator of the identified verification status is output from the device.
- the verification status regards an entity authentication using the device.
- This variation includes the steps of receiving within the device input comprising biometric verification data of an entity; identifying within the device a current verification status out of a plurality of verification statuses of the device as a function of the verification data and biometric data prestored within the device; and, independent of the verification status identified, outputting from the device an indicator of the identified verification status, the indicator revealing the identified verification status without revealing either of the verification data or the prestored data.
- a first entity is authenticated to a second entity.
- biometric data of the first entity is stored within a verification component of a device during a personalization of the verification component. Later, biometric verification data is input into the device and received within the verification component of the device, and a current verification status is identified as a function of the verification data and prestored data within the verification component of the device. Independent of the verification status identified, such verification status is communicated to the second entity by outputting from the verification component an indicator of the identified verification status and transmitting the output indicator to the second entity. The indicator reveals the identified verification status without revealing either of the verification data or the prestored data.
- a verification status regarding an entity authentication wherein no verification data is yet received by a device.
- the method in this case includes the steps of maintaining within the device prestored biometric data of an entity for identifying a verification status of the device as a function of the prestored data and biometric verification data later input into the device; identifying within the device a current verification status of the device representing the lack of input of any verification data during a predefined period of time; and outputting from the device an indicator of the identified verification status for evaluation thereof.
- a current verification status is identified within the device out of a plurality of predefined verification statuses of the device by comparing the received verification data with the prestored data; and an indicator of the identified verification status is again output from the device for evaluation thereof, wherein the second indicator reveals the identified verification status based on the comparison without revealing either of the verification data or the prestored data.
- one verification status out of the plurality of predefined verification statuses of the device is representative of the verification data being the same as the prestored data, and at least one other predefined verification status is representative of the verification data being different from the prestored data; and the device is capable of generating digital signatures. Additionally, a request is evaluated with business logic based on the identified verification status.
- a third aspect of the present invention relates to the provision of a verification status of a device and includes the steps of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device; generating within the device a digital signature for a message as a function of the identified verification status, including modifying within the device data representing the message as a function of the identified verification status of the device such that the generated digital signature comprises an indicator of the identified verification status; and, transmitting the generated digital signature to an electronic apparatus external to the device.
- the identification of the current verification status is a function of verification data input into the device and data prestored within the device.
- the verification status regards an entity authentication.
- This variation includes the steps of receiving within the device input comprising verification data of an entity; identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of the verification data and data prestored within the device; generating within the device a digital signature for a message as a function of the identified verification status, including modifying within the device data representing the message as a function of the identified verification status of the device such that the generated digital signature comprises an indicator of the identified verification status; and outputting from the device the generated digital signature.
- a first entity is authenticated to a second entity.
- data of the first entity is stored within a verification component of a device during a personalization of the verification component. Later, verification data is input into and received within the verification component of the device, and a current verification status is identified as a function of the verification data and prestored data within the verification component of the device. The verification status identified is one out of a plurality of predefined verification statuses of the device.
- a digital signature then is generated within the device for a message as a function of the identified verification status and includes modifying within the device data representing the message as a function of the identified verification status of the device. The generated digital signature comprises an indicator of the identified verification status.
- the digital signature is output from the verification component of the device and, thereafter, communicated to the second entity.
- a verification status regarding an entity authentication wherein no verification data is yet received by a device.
- the method in this case includes the steps of maintaining within the device prestored data of an entity for identifying a verification status of the device as a function of the prestored data and verification data later input into the device; identifying within the device a current verification status of the device representing the lack of input of any verification data during a predefined period of time; generating within the device a digital signature for a message such that the generated digital signature comprises an indicator of the identified verification status; and outputting from the device the generated digital signature for evaluation of the identified verification status.
- input comprising verification data is received within the device; a current verification status is identified within the device out of a plurality of predefined verification statuses of the device by comparing the received verification data with the prestored data; and another digital signature is generated within the device for a message as a function of the identified verification status.
- data representing the message is modified within the device as a function of the identified verification status of the device.
- the second generated digital signature comprising an indicator of the identified verification status is then output from the device for evaluation thereof.
- one verification status out of the plurality of predefined verification statuses of the device is representative of the verification data being the same as the prestored data, and at least one other predefined verification status is representative of the verification data being different from the prestored data; the indicator of the identified verification status neither reveals the prestored data nor the verification data; the prestored data represents a Secret; and the prestored data represents a biometric characteristic. Additionally, a request is evaluated with business logic based on the identified verification status.
- the generation of the digital signature includes encrypting within the device using a private key of a public private key pair a message digest calculated within the device for the modified data.
- the digital signature for the modified data representing the message is output from the device, but the modified data itself is not output from the device.
- the message is composed within the device by a user of the device.
- the message for which a digital signature is generated is displayed on a display screen of the device for review and approval by the user.
- the message is composed within an I/O support element external to the device which, in turn, transmits the input representing the message into the device through an interface of the device.
- a portion of the message is composed within an I/O support element external to the device which, in turn, transmits input representing the portion of the message into the device through an interface of the device, and a remaining portion of the message is composed within the device.
- the I/O support element may comprise, for example, a point of sale terminal, a biometric scanner, a card reader, or a computer.
- the message itself may be for the performance of a financial transaction, the performance of a legal action, access to a database, access to a physical space, access to a web site, or access to a computer program.
- the message also may be predetermined and static, and may be stored within the device itself. Verification data also may not be required to be input into the device for other types of messages, or for a predefined period of time such as the time between approval of a request embodied in a message and a powering off of the device.
- the data representing the message comprise a hash value of the message or, alternatively, the data representing the message comprise a message digest for the message.
- the data representing the message may be stored within the device.
- the modification of the data representing the message preferably includes: embedding the assigned value of an identification marker within the data representing the message; appending the assigned value of the identification marker to the data representing the message; appending the assigned value of the identification marker to the beginning of the data representing the message; and appending the assigned value of the identification marker to the end of the data representing the message.
- verification data may be required to be input into the device following a predefined period of time after a last successful verification, and verification data may be required to be input into the device for each one of a particular type of message.
- the particular type of message may comprise, for example, a request for a financial transaction.
- Additional preferred embodiments include message authentication using the digital signature generated within the device, and include the steps of: modifying data representing the message embodying the request as a function of a suspected verification status of the device, calculating a message digest as a function of the modified data, decrypting the generated digital signature using the public key of the public-private key pair, and concluding the verification status of the device as being the suspected verification status of the device when the calculated message digest matches the decrypted digital signature.
- the device preferably identifies the current verification status of the device by assigning an identification marker within the device equal to a value out of a set of predefined values corresponding to the predefined verification statuses.
- the identification marker is assigned a value equated with a successful verification, and the assigned value further represents whether a digital signature was generated since verification data was last input into the device.
- the generated digital signature preferably comprises the indicator.
- a fourth aspect of the present invention relates to the provision of a verification status of a device and includes the step of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of verification data input into the device and data prestored within the device. This step includes comparing verification data representing a Secret with the data prestored within the device and assigning, based on the comparison, a first comparison marker within the device equal to a value out of a set of predefined values; and comparing verification data representing biometric data with the data prestored within the device and assigning, based on the comparison, a second comparison marker within the device equal to a value out of a set of predefined values.
- Data representing a message is modified within the device as a function of the assigned values for the first and second comparison markers. Thereafter, a digital signature is generated within the device for the modified data such that the generated digital signature comprises an indicator of the identified verification status. The generated digital signature then is transmitted to an electronic apparatus external to the device.
- the verification status regards an entity authentication using a device.
- This variation includes the steps of receiving within the device input comprising verification data of an entity, the verification data representing both a Secret and a biometric characteristic of the entity; identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of the verification data and data prestored within the device; modifying within the device data representing a message as a function of the identified verification status and generating within the device a digital signature for a message such that the generated digital signature comprises an indicator of the identified verification status; and outputting from the device the generated digital signature.
- the identification of the verification status includes comparing verification data representing the Secret with the data prestored within the device and assigning, based on the comparison, a first comparison marker within the device equal to a value out of a set of predefined values; and comparing verification data representing biometric data with the data prestored within the device and assigning, based on the comparison, a second comparison marker within the device equal to a value out of a set of predefined values.
- the modification of the message data includes modifying the data as a function of the assigned values for the first and second comparison markers.
- a first entity is authenticated to a second entity.
- data representing both a Secret and biometric data of the first entity is stored within a verification component of a device during a personalization of the verification component. Later, verification data is input into the device and received within the verification component of the device, and a current verification status is identified as a function of the verification data and prestored data within the verification component of the device.
- the identification of the verification status includes comparing verification data representing the Secret with data prestored within the device and assigning, based on the comparison, a first comparison marker within the device equal to a value out of a set of predefined values; and comparing verification data representing biometric data with data prestored within the device and assigning, based on the comparison, a second comparison marker within the device equal to a value out of a set of predefined values.
- a digital signature is generated within the device for a message by first modifying within the device data representing the message as a function of the assigned values for the first and second comparison markers, and then encrypting the modified data such that the digital signature comprises an indicator of the identified verification status. The digital signature then is output from the verification component and transmitted to the second entity.
- one verification status out of the plurality of predefined verification statuses of the device is representative of the verification data being the same as the prestored data, and at least one other predefined verification status is representative of the verification data being different from the prestored data;
- the assigned value of the first comparison marker, the assigned value of the second comparison marker, or the assigned values of the first and second comparison markers are output from the device with the generated digital signature;
- the modification of the message includes embedding the assigned value of the first comparison marker, the assigned value of the second comparison marker, or both, within the data representing the message, or appending such assigned value(s) to the data representing the message, including appending to the beginning or the end of the message data.
- a request is evaluated with business logic based on the identified verification status.
- the data representing the message is modified as a function of only one of the assigned values for the first and second comparison markers. Furthermore, the generated digital signature for the message and the other of the assigned values for the first and second comparison markers is transmitted to the second entity.
- a fifth aspect of the present invention relates to determining a current verification status of a device that generates a digital signature and includes the steps: receiving a digital signature; decrypting the digital signature using a public key of a public-private key pair; for each one of a plurality of predefined verification statuses of the device, modifying data representing a message as a function of the predefined verification status; and identifying the current verification status of the device as being the predefined verification status for which the modified data matches the decrypted digital signature.
- a message digest is calculated as a function of the modified data following the modification.
- the calculation of the message digest as a function of the modified data may include the calculation of a hash value for the modified data.
- each one of the verification statuses represents a relational correspondence between verification data input into the device and data prestored within the device. Furthermore, each verification status neither reveals verification data nor prestored data of the device for which the current verification status is determined.
- the current verification status is associated with a request.
- the request for example, may be for the performance of a financial transaction or for the performance of a legal action.
- the request for example, may be predetermined and static and included in a predefined message.
- the request may be for access to a physical space, access to a web site, access to a database, or access to a computer program.
- the request is received in association with the digital signature and evaluated based on the current verification status indicated by the digital signature.
- the evaluation of the request includes the step of considering an assurance level of the device generating the digital signature.
- the request may be implicit in the receipt of the digital signature.
- the request may be communicated over an electronic communications medium such as a computer network, whether public or private.
- one of the predefined verification statuses represents an unsuccessful verification; one of the predefined verification statuses represents a successful verification; one of the predefined verification statuses additionally represents whether a digital signature has been generated by the device since verification data was last input into the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated subsequent to a comparison of verification data input into the device with data prestored within the device; one of the predefined verification statuses additionally represents whether any verification data has been input into the device within a predetermined time period comprising, for example, the time since a last successful verification or the time since a resetting of the device.
- one of the predefined verification status represents a difference between verification data input into the device and data prestored within the device; one of the predefined verification statuses represents a degree of match between biometric verification data input into the device and biometric data prestored within the device; one of the predefined verification statuses additionally represents a percentage of match between biometric verification data input into the device and biometric data prestored within the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated by the device since verification data was last input into the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated subsequent to a comparison of verification data input into the device with data prestored within the device; one of the predefined verification statuses additionally represents whether any verification data has been input into the device within a predetermined time period.
- the device preferably identifies the current verification status of the device by assigning an identification marker within the device equal to a value out of a set of predefined values corresponding to the predefined verification statuses.
- the identification marker is assigned a value equated with a successful verification when the comparison results in a match, including an exact match (e.g., when the data represents a Secret); the identification marker is assigned a value equated with a successful verification when the comparison results in a match, but not an exact match (e.g., when the data represents a biometric characteristic); and, the identification marker is assigned a value equated with an unsuccessful verification when a comparison between the verification data and the prestored data does not result in a match.
- an exact match e.g., when the data represents a Secret
- the identification marker is assigned a value equated with a successful verification when the comparison results in a match, but not an exact match (e.g., when the data represents a biometric characteristic)
- the identification marker is assigned a value equated with an unsuccessful verification when a comparison between the verification data and the prestored data does not result in a match.
- the identification marker is assigned a value representing a difference determined from a comparison between the verification data and the prestored data; the identification marker is assigned a value representing a degree of match between the verification data and the prestored data; the identification marker is assigned a value equated with a percentage of match between the verification data and the prestored data; and the identification marker is assigned a value representing whether any verification data was input into the device within a predefined time period, such as the time since a last successful verification or the time since a resetting of the device
- the assigned value further represents whether an indicator was output subsequent to the successful verification or whether an indicator was output since verification data was last input into the device.
- the indicator comprises the assigned value of the identification marker, and the assigned value further represents whether a digital signature was generated by the device since verification data was last input into the device.
- the device preferably generates a digital signature in response to an external inquiry received by the device, in response to receipt of data representing the message, or in response to receipt of input comprising the verification data.
- the verification data being input directly into the device by a user; and, alternatively, input representing the verification data being received within an I/O support element external to the device and then transmitted into the device.
- the I/O support element may include, for example, a point of sale terminal, a biometric scanner, a card reader, an ATM machine, or a computer.
- the indicator points definitively (i.e., without ambiguity) to a single predefined verification status of the device; neither the prestored data comprising a Secret and/or biometric data nor the verification data input into the device are exported from the device; and the device prestores data for a plurality of users of the device; a digital signature is generated within the device and output from the device with the value of the identification marker.
- the identification marker is assigned a value representing the type of the biometric data in a feature of the present invention.
- the biometric data may represent, for example, a digitized fingerprint, a digitized handprint or hand geometry, a digitized retina, a digitized iris, a digitized voice print, a digitized facial scan, a digitized written signature, or a digitized DNA sample.
- the device may include a biometric scanner for inputting of the verification data.
- the device also may prestore data for a plurality of different types of biometric data, whether for one person or for several persons.
- verification data is required to be input into the device for each one of a particular type of request such as, for example, a financial transaction. Verification data may not be required to be input into the device for other types of requests. Verification data also may be required to be input into the device for a particular type of request, but only until an evaluation of the request results in an approval, and then verification data may not be required to be input into the device for additional requests of such type during a predefined period of time thereafter, such as the time between the approval of the request and a resetting of the device.
- Random numbers are utilized in may computer applications, such as in security protocols like secure socket layer (SSL) protocol and pretty good privacy (PGP) for the creation of session keys.
- SSL secure socket layer
- PGP pretty good privacy
- Yet another feature of the present invention includes the generation of a digital signature using a digital signature algorithm, with the resulting digital signature being used in such an application as a random number.
- the device of the methods of the present invention preferably is a personal device of the sender of the EC.
- the device also preferably includes a device interface such as, for example, an alphanumeric keypad, an electrical contact, a touch screen display, a standard electronic interface with a computer bus, or an antenna.
- the device interface also may comprise a port the device, such as a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port.
- the device preferably is portable and of a handheld form factor.
- the device preferably includes a computer chip and/or integrated circuitry, and may be, for example, a cell phone, a PDA, a digitized key, a dongle, a subcutaneous implant, jewelry, an integrated circuit card (IC Card), a credit card, a debit card, smart card, a security card, an ID badge, or a computer.
- a computer chip and/or integrated circuitry may be, for example, a cell phone, a PDA, a digitized key, a dongle, a subcutaneous implant, jewelry, an integrated circuit card (IC Card), a credit card, a debit card, smart card, a security card, an ID badge, or a computer.
- Other features of the present invention include: a device with a computer-readable medium having computer-executable instructions that perform one or more steps of a method of the present invention; integrated circuitry that performs one or more steps of a method of the present invention; and a computer chip that performs one or more steps of a method of the present invention.
- FIG. 1 illustrates in block diagram a conceptual framework of the present invention
- FIG. 2 a illustrates a first preferred embodiment of the present invention
- FIG. 2 b illustrates a variation of the embodiment of FIG. 2 a
- FIG. 2 c illustrates a variation of the embodiment of FIG. 2 a
- FIG. 3 illustrates a preferred mode of operation of the device of FIGS. 2 a , 2 b , and 2 c;
- FIG. 4 a illustrates a second preferred embodiment of the present invention
- FIG. 4 b illustrates a variation of the embodiment of FIG. 4 a
- FIG. 4 c illustrates a variation of the embodiment of FIG. 4 a
- FIG. 5 illustrates a preferred mode of operation of the device of FIGS. 4 a , 4 b , and 4 c;
- FIG. 6 a illustrates a third preferred embodiment of the present invention
- FIG. 6 b illustrates a variation of the embodiment of FIG. 6 a
- FIG. 6 c illustrates a variation of the embodiment of FIG. 6 a
- FIG. 7 illustrates a preferred mode of operation of the device of FIGS. 6 a , 6 b , and 6 c;
- FIG. 8 a illustrates a fourth preferred embodiment of the present invention
- FIG. 8 b illustrates a variation of the embodiment of FIG. 8 a
- FIG. 8 c illustrates a variation of the embodiment of FIG. 8 a
- FIG. 8 d illustrates a variation of the embodiment of FIG. 8 a
- FIG. 9 illustrates a preferred mode of operation of the device of FIGS. 8 a , 8 b , and 8 c;
- FIG. 10 a illustrates a fifth preferred embodiment of the present invention
- FIG. 10 b illustrates a variation of the embodiment of FIG. 10 a
- FIG. 10 c illustrates a variation of the embodiment of FIG. 10 a
- FIG. 11 illustrates a preferred mode of operation of the device of FIGS. 10 a , 10 b , and 10 c;
- FIG. 12 a illustrates a sixth preferred embodiment of the present invention
- FIG. 12 b illustrates a variation of the embodiment of FIG. 12 a
- FIG. 12 c illustrates a variation of the embodiment of FIG. 12 a
- FIG. 13 illustrates a preferred mode of operation of the device of FIGS. 12 a , 12 b , and 12 c;
- FIG. 14 a illustrates a seventh preferred embodiment of the present invention
- FIG. 14 b illustrates a variation of the embodiment of FIG. 14 a
- FIG. 14 c illustrates a variation of the embodiment of FIG. 14 a
- FIG. 15 illustrates a preferred mode of operation of the device of FIGS. 14 a , 14 b , and 14 c;
- FIG. 16 a illustrates an eighth preferred embodiment of the present invention
- FIG. 16 b illustrates a variation of the embodiment of FIG. 16 a
- FIG. 16 c illustrates a variation of the embodiment of FIG. 16 a
- FIG. 17 illustrates a preferred mode of operation of the device of FIGS. 16 a , 16 b , and 16 c;
- FIG. 18 a illustrates a ninth preferred embodiment of the present invention
- FIG. 18 b illustrates a variation of the embodiment of FIG. 18 a
- FIG. 18 c illustrates a variation of the embodiment of FIG. 18 a
- FIG. 19 illustrates a preferred mode of operation of the device of FIGS. 18 a , 18 b , and 18 c;
- FIGS. 20 a , 20 b , and 20 c illustrate preferred formats of prestored data of the present invention
- FIGS. 21 a , 21 b , and 21 c illustrate preferred formats of verification data of the present invention
- FIG. 22 illustrates a preferred comparison and verification status identification process
- FIGS. 23 a and 23 b illustrate preferred comparison and verification status identification processes
- FIG. 24 illustrates a preferred comparison and verification status identification process
- FIGS. 25 a and 25 b illustrate preferred formats of identification markers of the present invention
- FIG. 26 illustrates preferred formats of identification markers of the present invention
- FIG. 27 illustrates a table of identification markers resulting from a hypothetical sequence of verification data inputs in accordance with the present invention
- FIG. 28 illustrates a preferred data flowchart within an implementation of the present invention using a computer chip
- FIG. 29 illustrates a first specific implementation of the present invention using an IC card
- FIG. 30 illustrates a second specific implementation of the present invention using an IC card
- FIG. 31 illustrates a third specific implementation of the present invention using an IC card
- FIGS. 32 a and 32 b illustrate fourth and fifth specific implementations of the present invention using an IC card
- FIG. 33 illustrates a sixth specific implementation of the present invention using an IC card.
- a device 140 includes a verification component thereof that performs the functions of: receiving input 150 representing verification data of the sender 120 ; identifying a current verification status of the device 140 ; and communicating the identified verification status (VS) 160 to the recipient 130 in association with the EC 110 .
- the verification data represented by the input 150 comprise a Secret or a biometric value.
- the verification status 160 preferably is identified within the device by maintaining prestored data of the sender 120 and by comparing the prestored data with the verification data that is input. Accordingly, the prestored data comprises a Secret or a biometric value, too.
- the device 140 also includes a plurality of predefined verification statuses, each representing a relational correspondence between the verification data and the prestored data. None of the verification statuses, however, actually reveals the verification data or the prestored data; thus, there need be no “shared secret” between the sender 120 and the recipient 130 .
- the device 140 identifies one of the predefined verification statuses as being the current verification status 160 based on the comparison of the verification data with the prestored data, and the device 140 communicates the identified verification status 160 to the recipient 130 by outputting from the device 140 an indicator of the identified verification status that then is transmitted to the recipient 130 .
- the indicator may or may not actually comprise the verification status 160 ; however, the indicator does indicate to the recipient 130 (or enables the recipient 130 to determine) the verification status 160 identified within the device.
- the device 140 preferably includes a predefined verification status representing that no input 150 was received within a predefined period of time.
- the device 140 identifies this verification status as being the current verification status 160 if no input 150 is received within such predefined period of time and, when appropriate, communicates such verification status to the recipient 130 in association with an EC 110 .
- the predefined period of time may comprise, for example, the time since a resetting of the device 140 or simply a predetermined amount of time.
- the predefined amount of time may comprise the time since the device 140 was, in fact, “powered on.”
- Examples of possible verification statuses include “match” and “no match” between the verification data and the prestored data, and degrees of match or difference between the verification data and prestored data (e.g., when the verification data and prestored data comprises biometric values).
- the verification statuses also may further represent whether a verification status has been provided to the recipient 130 within a predefined period of time.
- the predefined period of time may comprise, for example, the time since the last comparison of verification data with prestored data that resulted in a successful verification, the time since the last receipt of input 150 representing verification data, or simply a predetermined amount of time, as discussed above.
- the recipient 130 preferably has the ability of determining a level of risk associated with the EC 110 based on the verification status 160 . Because of this determined level of risk associated with the EC 110 , the recipient 130 is better able to evaluate the message of the EC 110 .
- the recipient 130 preferably is represented by an electronic apparatus that includes an interface for receiving the indicator transmitted from device 140 and logic circuitry or software incorporating business logic for evaluating the EC 110 from the sender 120 based on the received indicator.
- the electronic apparatus may be located remote to the device 140 but disposed in electronic communication therewith, such as over an electronic communications network (e.g. Internet, intranet, wireless network, and the like).
- the message may be explicit or implicit. If implicit, the content of the message may be predefined. For example, the actual act of receiving an indicator of the verification status of the device 140 by the recipient 130 may, in itself, represent a message agreed upon between the sender 120 and the recipient 130 . In such a case, no EC 110 containing a message need be sent. Furthermore, when an EC 110 actually is sent from the sender 120 to the recipient 130 , part or all of the EC 110 may be composed and sent from the device 140 , rather than separate from the device 140 as shown in FIG. 1.
- FIG. 2 a A first preferred embodiment 200 of the present invention is illustrated in FIG. 2 a , wherein an EC 210 including a message from a sender 220 is received by a recipient represented by an electronic apparatus 230 , and wherein a device 240 receives input representing verification data (VD) 250 at a device interface 252 .
- the device 240 includes a verification component therein that maintains data (PD) 270 of the sender 220 prestored in memory 254 of the device 240 .
- the verification data 250 and prestored data 270 represent Secret or biometric values.
- the verification component identifies at 256 a current verification status of the device 240 based on a comparison of the verification data 250 with the prestored data 270 .
- a signal (S) 280 the last identified (i.e., “current”) verification status of the device 240 is communicated to the recipient by outputting from the device 240 an indicator 260 that then is transmitted to the recipient in association with the EC 210 .
- the signal 280 is sent to the device 240 , which triggers the device 240 to output the indicator 260 .
- the signal 280 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by the sender 220 , by the electronic apparatus 230 , or by another apparatus (not shown).
- the device interface 252 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 220 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port, or other wireless communications port.
- a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 220 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port, or other wireless communications port.
- the device 240 also includes a set of predefined verification statuses each representing a relational correspondence between the verification data 250 and the prestored data 270 . Verification statuses of the set further represent whether an indicator 260 has been output from the device 240 since the last successful verification or since the last receipt of input representing verification data.
- the set also contains one additional predefined verification status representing the lack of input representing verification data 250 since a resetting after a timeout or a powering on of the device 240 .
- the indicator 260 output from the device 240 is based on the last comparison of the verification data 250 with the prestored data 270 , but only if input representing verification data 250 has been received since the resetting of the device 240 .
- the indicator 260 indicates the lack of input representing verification data 250 since the resetting of the device 240 .
- the indicator 260 is transmitted in association with the EC 210 , whereby the recipient is able to identify the indicator 260 as relating to the EC 210 .
- the electronic apparatus 230 includes an interface (not shown) capable of receiving the indicator 260 from device 240 , and also includes logic circuitry or software incorporating business logic therein for determining the verification status based on the indicator 260 and for evaluating the EC 210 received from the sender 220 based on the verification status of the device 240 .
- the predefined set of verification statuses includes at least four verification statuses, comprising: a first verification status representing the lack of verification data 250 since a resetting of the device; a second verification status representing a match between the verification data 250 and the prestored data 270 , and further representing no other indicator 260 being output from the device 240 since the match; a third verification status representing a failed match between the verification data 250 and the prestored data 270 ; and a fourth verification status representing a match between the verification data 250 and the prestored data 270 , and further representing that an indicator 260 has been output since the match.
- the device 240 preferably includes an identification marker (“IM”) 272 stored in memory 274 and comprising one of four binary numbers that represents the current verification status identified by the device 240 .
- the four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status.
- the indicator 260 output from the device 240 preferably includes the value of the identification marker 272 , with the correspondence of the value with the predefined verification statuses of the device 240 being previously known by the recipient. None of the verification statuses actually reveal the verification data 250 or the prestored data 270 ; thus, no “shared secret” is required between the sender 220 and the recipient. However, the recipient can infer correct knowledge of the Secret from the verification status.
- the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between the verification data 250 and prestored data 270 , together with a verification status representing the lack of input representing verification data 250 since a resetting of the device 240 .
- the predefined verification statuses comprising the percentage match of the verification data 250 with the prestored data 270 may comprise the set of percentages ranging from 0% to 100% in increments of 1%.
- each one of the verification statuses representing a percentage match also further represents whether an indicator 260 has been output from the device 240 since the last receipt of input representing verification data 250 .
- the device 240 preferably includes the identification marker 272 for storing a value representing the verification status identified by the device 240 as the current verification status. Furthermore, the indicator 260 output from the device 240 preferably comprises the value of the identification marker 272 , with the correspondence of such value with the predefined verification statuses of the device being previously known by the recipient.
- FIG. 2 b A variation based on the first preferred embodiment 200 of FIG. 2 a is shown in FIG. 2 b , and includes an I/O support element 262 from which the input representing the verification data 250 is received at the device interface 252 .
- the I/O support element 262 includes a user interface 258 from which input from the sender is received and an I/O interface 259 that communicates the input representing the verification data 250 to the device 240 .
- FIG. 2 c Yet an additional variation thereof is shown in FIG. 2 c , wherein the I/O support element 262 receives the indicator 260 output from the device 240 and, in turn, transmits the indicator 260 to the electronic apparatus 230 .
- the indicator 260 transmitted from the I/O support element 262 is the same as the indicator 260 output from the device 240 .
- the indicator transmitted from the I/O support element 262 may be different from the indicator output from the device 240 , so long as the recipient is able to determine the verification status as indicated by the indicator 260 output from the device 240 .
- the indicator transmitted from the I/O support element 262 may indicate not only the verification status of the device 240 , but also a verification status of the I/O support element 262 when the I/O support element 262 itself identifies a verification status.
- the indicator 260 transmitted from the I/O support element 262 may be packaged or embedded within another communication-including additional information that is digitally signed by the I/O support element 262 .
- the EC 210 is shown as being transmitted separate from the indicator 260 .
- the indicator 260 equally may be associated with the EC 210 by being transmitted as part of the EC 210 .
- the EC 210 may be output from the device 240 , an associated I/O support element 262 (not shown in FIG. 2 a ), or other apparatus.
- a preferred mode 300 of operation of the device of FIGS. 2 a , 2 b , and 2 c is illustrated in FIG. 3 and begins with a resetting Step 304 of the device following a timeout or powering on of the device at 302 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input representing verification data and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 306 and ends at 312 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 308 whether any input representing verification data (VD) is received by the device.
- Step 314 the current verification status (VS) of the device is identified Step 314 by comparing the verification data (VD) with the data prestored (PD) in memory of the device.
- the verification status identified then is recorded by assigning Step 316 a value to the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- Step 308 If no input representing verification data is received in Step 308 or after the value of the identification marker has been assigned in Step 316 , a determination is then made of whether a signal (S) has been or is being received by the device. If a signal is not received, then the loop restarts Step 306 .
- the determination in Step 310 is positive and the indicator of the current verification status of the device is output Step 318 .
- the indicator comprises the value of the identification marker maintained in memory within the device.
- Step 320 the determination is made Step 320 whether the indicator output is the first indicator output since receipt of input representing verification data. The loop restarts Step 306 if the determination in Step 320 is negative.
- Step 320 If the determination in Step 320 is positive, then the verification status is newly recorded by assigning Step 322 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data was received in Step 308 . The loop then restarts Step 306 .
- FIG. 4 a A second preferred embodiment 400 of the present invention is illustrated in FIG. 4 a , wherein an EC 410 including a message from a sender 420 is received by a recipient represented by an electronic apparatus 430 , and wherein a device 440 receives input representing verification data (VD) 450 at a device interface 452 .
- the device 440 includes a verification component therein that maintains data (PD) 470 of the sender 420 prestored in memory 454 of the device 440 .
- the verification data 450 and prestored data 470 represent Secret or biometric values.
- the verification component identifies at 456 a current verification status of the device 440 based on a comparison of the verification data 450 with the prestored data 470 .
- a signal (S) 480 the last identified (i.e., “current”) verification status of the device 440 is communicated to the recipient by outputting from the device 440 an indicator 460 that then is transmitted to the recipient in association with the EC 410 .
- a digital signature component of the device 440 originates a digital signature (DS) 482 for the indicator 460 by calculating a hash value for the indicator at 490 and then encrypting the hash value at 492 using a private key 495 of a public-private key pair.
- DS digital signature
- the digital signature 482 then is output from the device 440 and transmitted to the recipient with the indicator 460 .
- the private key 495 is retained securely within memory 494 so that it is never exported from the device 440 and is not discoverable from outside of the device 440 .
- the digital signature is originated in accordance with an elliptical curve digital signature algorithm (ECDSA) as specified in Federal Information Processing Standards Publication 186-2 , Digital Signature Standard, US DOC/NBS, Jan. 11, 1994 (hereinafter “FIPS PUB 186-2”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips.
- EDSA elliptical curve digital signature algorithm
- FIPS PUB 186-2 Digital Signature Standard
- the digital signature 482 is generated using a random number generator, and the hash function at 490 is performed using the secure hash algorithm (“SHA-1”), which generates a 20-byte output regardless of the size of the input received from component 456 .
- SHA-1 secure hash algorithm
- FIPS PUB 180-1 Federal Information Processing Standards Publication 180-1, Secure Hash Standard, US DOC/NBS, Apr. 17, 1995 (hereinafter “FIPS PUB 180-1”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips.
- the signal 480 is sent to the device 440 , which triggers the device 440 to output the indicator 460 .
- the signal 480 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by the sender 420 , by the electronic apparatus 430 , or by another apparatus (not shown).
- the device interface 452 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 420 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- the device 440 also includes a set of predefined verification statuses each representing a relational correspondence between the verification data 450 and the prestored data 470 . Verification statuses of the set further represent whether an indicator 460 has been output from the device since the last successful verification or since the last receipt of input representing verification data.
- the set also contains one additional predefined verification status representing the lack of input representing verification data 450 since a resetting after a timeout or a powering on of the device 440 .
- the indicator 460 output from the device 440 is based on the last comparison of the verification data 450 with the prestored data 470 , but only if input representing verification data 450 has been received since the resetting of the device 440 .
- the indicator 460 indicates the lack of input representing verification data 450 since the resetting of the device 440 .
- the indicator 460 is transmitted with the digital signature 482 therefor in association with the EC 410 , whereby the recipient is able to identify the indicator 460 as relating to the EC 410 .
- the electronic apparatus 430 includes an interface (not shown) capable of receiving the indicator 460 and digital signature 482 from device 440 .
- the electronic apparatus 430 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on the indicator 460 and for evaluating the EC 410 received from the sender 420 based on the verification status of the device 440 .
- the electronic apparatus 430 also decrypts the digital signature 482 to confirm the authenticity of the indicator 460 (i.e., the electronic apparatus 430 conducts Message Authentication with respect to the indicator 460 ). The decryption is performed using the public key, which corresponds to the private key 495 and which may be received in association with the digital signature 482 or otherwise known or obtained beforehand by the recipient.
- the predefined set of verification statuses includes at least four verification statuses, comprising: a first verification status representing the lack of verification data 450 since a resetting of the device; a second verification status representing a match between the verification data 450 and the prestored data 470 , and further representing no other indicator 460 being output from the device 440 since the match; a third verification status representing a failed match between the verification data 450 and the prestored data 470 ; and a fourth verification status representing a match between the verification data 450 and the prestored data 470 , and further representing that an indicator 460 has been output since the match.
- the device 440 preferably includes an identification marker (“IM”) 472 stored in memory 474 and comprising one of four binary numbers that represents the current verification status identified by the device 440 .
- the four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the ad first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status.
- the indicator 460 output from the device 440 preferably includes the value of the identification marker 472 , with the correspondence of the value with the predefined verification statuses of the device 440 being previously known by the recipient. None of the verification statuses actually reveal the verification data 450 or the prestored data 470 ; thus, no “shared secret” is required between the sender 420 and the recipient. However, the recipient can infer correct knowledge of the Secret from the verification status.
- the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between the verification data 450 and prestored data 470 , together with a verification status representing the lack of input representing verification data 450 since a resetting of the device 440 .
- the predefined verification statuses comprising the percentage match of the verification data 450 with the prestored data 470 may comprise the set of percentages ranging from 0% to 100% in increments of 1%.
- Each one of the verification statuses representing a percentage match also further represents whether an indicator 460 has been output from the device 440 since the last receipt of input representing verification data 450 .
- the device 440 preferably includes the identification marker 472 for storing a value representing the verification status identified by the device 440 as the current verification status. Furthermore, the indicator 460 output from the device 440 preferably comprises the value of the identification marker 472 , and the correspondence of such value with the predefined verification statuses of the device is previously known by the recipient. Again, none of the verification statuses actually reveal either of the verification data 450 or the prestored data 470 ; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of the sender 420 from the reading of the biometric characteristic.
- FIG. 4 b A variation based on the second preferred embodiment 400 of FIG. 4 a is shown in FIG. 4 b , and includes an I/O support element 462 from which the input representing the verification data 450 is received at the device interface 452 .
- the I/O support element 462 includes a user interface 458 from which input from the sender 420 is received and an I/O interface 459 that communicates the input representing the verification data 450 to the device 440 .
- FIG. 4 c Yet an additional variation thereof is shown in FIG. 4 c , wherein the I/O support element 462 receives the indicator 460 and digital signature 482 therefor output from the device 440 .
- the I/O support element 462 transmits the indicator 460 and digital signature 482 to the external electronic apparatus 430 .
- the indicator 460 transmitted from the I/O support element 462 is the same as the indicator 460 output from the device 440 .
- the indicator transmitted from the I/O support element 462 may be different from the indicator output from the device 440 , so long as the recipient is able to determine both the verification status as indicated by the indicator 460 output from the device 440 , and the bit pattern of the indicator 460 for which the digital signature was originated by the device 440 .
- the indicator transmitted from the I/O support element 462 may indicate not only the verification status of the device 440 , but also a verification status of the I/O support element 462 when the I/O support element 462 itself identifies a verification status.
- the indicator 460 transmitted from the l/O support element 462 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 462 .
- the EC 410 is shown as being transmitted separate from the indicator 460 and digital signature 482 .
- the indicator 460 and digital signature 482 equally may be associated with the EC 410 by being transmitted as part of the EC 410 .
- the EC 410 may be output from the device 440 , an associated I/O support element 462 (not shown in FIG. 4 a ), or other apparatus.
- a preferred mode 500 of operation of the device of FIGS. 4 a , 4 b , and 4 c is illustrated in FIG. 5 and begins with a resetting Step 504 of the device following a timeout or powering on of the device at 502 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input representing verification data and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 506 and ends at 512 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 508 whether any input representing verification data (VD) is received by the device.
- Step 508 the current verification status (VS) of the device is identified Step 514 by comparing the verification data (VD) with the data prestored (PD) in memory of the device.
- the verification status identified then is recorded by assigning Step 516 a value to the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- Step 508 If no input representing verification data is received in Step 508 or after the value of the identification marker has been assigned in Step 516 , a determination is then made of whether a signal (S) has been or is being received by the device. If a signal is not received, then the loop restarts Step 506 . When a signal is received, the determination in Step 510 is positive and a digital signature is originated Step 518 for the indicator of the current verification status. The indicator and the digital signature therefor then are output Step 520 . As set forth above, the indicator comprises the value of the identification marker maintained in memory within the device. Following the output of the indicator and digital signature, the determination is made Step 522 whether the indicator output is the first indicator output since receipt of input representing verification data.
- Step 506 The loop restarts Step 506 if the determination in Step 522 is negative. If the determination in Step 522 is positive, then the verification status is newly recorded by assigning Step 524 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data was received in Step 508 . The loop then restarts Step 506 .
- FIG. 6 a A third preferred embodiment 600 of the present invention is illustrated in FIG. 6 a , wherein an EC 610 including a message from a sender 620 is received by a recipient represented by an electronic apparatus 630 , and wherein a device 640 receives input representing verification data (VD) 650 at a device interface 652 .
- the device 640 includes a verification component therein that maintains data (PD) 670 of the sender 620 prestored in memory 654 of the device 640 .
- the verification data 650 and prestored data 670 represent Secret or biometric values.
- the verification component identifies at 656 a current verification status of the device 640 based on a comparison of the verification data 650 with the prestored data 670 .
- a signal (S) 680 the last identified (i.e., “current”) verification status of the device 640 is communicated to the recipient by outputting from the device 640 an indicator 660 that then is transmitted to the recipient in association with the EC 610 .
- the signal 680 is sent to the device 640 , which triggers the device 640 to output the indicator 660 .
- the signal 680 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by the sender 620 , by the electronic apparatus 630 , or by another apparatus (not shown).
- the device interface 652 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 620 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 620 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- the device 640 receives at the device interface 652 data (MD) 622 representing the message of the EC 610 .
- the message data may comprise the message itself, a message digest thereof, or the result of some other processing of the message (M).
- the device 640 includes a digital signature component that, upon receipt of the message data 622 , originates a digital signature (DS) 686 for the message data 622 .
- the digital signature 686 is originated by calculating a hash value for the message data 622 at 690 and then encrypting the hash value at 692 using a private key 695 of a public-private key pair.
- the private key 695 is retained securely within memory 694 so that it is never exported from the device 640 and is not discoverable from outside of the device 640 .
- the digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 682 is generated using a random number generator, and the hash function at 690 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received. The digital signature 686 then is output from the device 640 and transmitted to the recipient with the indicator 660 .
- the device 640 is configured not to hash any message data 622 or not to hash message data 622 if a specific instruction, signal, or command is received.
- the device 640 also includes a set of predefined verification statuses each representing a relational correspondence between the verification data 650 and the prestored data 670 . Verification statuses of the set further represent whether an indicator 660 has been output from the device 640 since the last successful verification or since the last receipt of input representing verification data.
- the set also contains one additional predefined verification status representing the lack of input representing verification data 650 since a resetting after a timeout or a powering on of the device 640 .
- the indicator 660 output from the device 640 is based on the last comparison of the verification data 650 with the prestored data 670 , but only if input representing verification data 650 has been received since the resetting of the device 640 . Otherwise, the indicator 660 indicates the lack of input representing verification data 650 since the resetting of the device 640 .
- the indicator 660 is transmitted with the digital signature 686 in association with the EC 610 , whereby the recipient is able to identify the indicator 660 and digital signature 686 as relating to the EC 610 .
- the electronic apparatus 630 includes an interface (not shown) capable of receiving the indicator 660 and digital signature 686 from the device 640 .
- the electronic apparatus 630 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on the indicator, and for evaluating the EC 610 received from the sender 620 based on the determined verification status.
- the electronic apparatus 630 also decrypts the digital signature 686 to confirm the authenticity of the message of the EC 610 .
- the decryption is performed with the public key, which corresponds with the private key 695 and which may be received in association with the digital signature 686 or known or obtained beforehand by the recipient.
- the electronic apparatus 630 performs any necessary processing to the message in order to produce the message data for which the digital signature was originated.
- the predefined set of verification statuses includes at least four verification statuses, comprising: a first verification status representing the lack of verification data 650 since a resetting of the device; a second verification status representing a match between the verification data 650 and the prestored data 670 , and further representing no other indicator 660 being output from the device 640 since the match; a third verification status representing a failed match between the verification data 650 and the prestored data 670 ; and a fourth verification status representing a match between the verification data 650 and the prestored data 670 , and further representing that an indicator 660 has been output since the match.
- the device 640 preferably includes an identification marker (“IM”) 672 stored in memory 674 and comprising one of four binary numbers that represents the current verification status identified by the device 640 .
- the four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status.
- the indicator 660 output from the device 640 preferably includes the value of the identification marker 672 , with the correspondence of the value with the predefined verification statuses of the device being previously known by the recipient. None of the verification statuses actually reveal the verification data 650 or the prestored data 670 ; thus, no “shared secret” is required between the sender 620 and the recipient. However, the recipient can infer correct knowledge of the Secret from the verification status.
- the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between the verification data 650 and prestored data 670 , together with a verification status representing the lack of input representing verification data 650 since a resetting of the device 640 .
- the predefined verification statuses comprising the percentage match of the verification data 650 with the prestored data 670 may comprise the set of percentages ranging from 0% to 100% in increments of 1%.
- each one of the verification statuses representing a percentage match also further represents whether an indicator 660 has been output from the device 640 since the last receipt of input representing verification data 650 .
- the device 640 preferably includes the identification marker 672 for storing a value representing the verification status identified by the device 640 as the current verification status. Furthermore, the indicator 660 output from the device 640 preferably comprises the value of the identification marker 672 , with the correspondence of such value with the predefined verification statuses of the device being previously known by the recipient. Again, none of the verification statuses actually reveal either of the verification data 650 or the prestored data 670 ; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of the sender from the reading of the biometric characteristic.
- FIG. 6 b A variation based on the third preferred embodiment 600 of FIG. 6 a is shown in FIG. 6 b , and includes an I/O support element 662 from which input representing the verification data 650 and input representing the message data 622 are received by the device 640 .
- the I/O support element 662 includes a user interface 658 from which input from the sender 620 is received and an I/O interface 659 that communicates the input representing the verification data 650 and input representing the message data 622 to the device 640 .
- the message data 622 is shown coming from the I/O support element 662 , it is possible for some or all of the message data 622 to be composed within the device 640 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG.
- the I/O support element 662 receives the indicator 660 and digital signature 686 output from the device 640 .
- the I/O support element 662 transmits the indicator 660 and the digital signature 686 to the electronic apparatus 630 .
- the indicator 660 and digital signature 686 transmitted from the I/O support element 662 are the same as the indicator 660 and digital signature 686 output from the device 640 .
- the indicator transmitted from the I/O support element 662 may be different from the indicator output from the device 640 , so long as the recipient is able to determine the verification status as indicated by the indicator 660 output from the device 640 .
- the indicator transmitted from the I/O support element 662 may indicate not only the verification status of the device 640 , but also a verification status of the I/O support element 662 when the I/O support element 662 itself identifies a verification status.
- the indicator 660 and digital signature 686 transmitted from the I/O support element 662 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 662 .
- the EC 610 is shown as being transmitted separate from the indicator 660 and digital signature 686 .
- the indicator 660 and digital signature 686 equally may be associated with the EC 610 by being transmitted as part of the EC 610 .
- the EC 610 may be output from the device 640 , an associated I/O support element 662 (not shown in FIG. 6 a ), or other apparatus.
- a preferred mode 700 of operation of the device of FIGS. 6 a , 6 b , and 6 c is illustrated in FIG. 7 and begins with a resetting Step 704 of the device following a timeout or powering on of the device at 702 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input representing verification data and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 706 and ends at 714 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 708 whether any input representing verification data (VD) is received by the device.
- Step 716 the current verification status (VS) of the device is identified Step 716 by comparing the verification data (VD) with the data prestored (PD) in memory of the device.
- the verification status identified then is recorded by assigning Step 718 a value to the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- Step 710 determines whether any input representing message data (MD) is received by the device. If the determination in Step 710 is positive, the device originates Step 720 a digital signature for the message data. The digital signature for the message data is then output Step 722 from the device.
- MD message data
- Step 710 If no input representing message data is received in Step 710 or after the digital signature for the message data is output in Step 722 , a determination is then made of whether a signal (S) has been or is being received by the device. If a signal is not received, then the loop restarts Step 706 . When a signal is received, the determination in Step 712 is positive and the indicator of the current verification status of the device is output Step 724 . As set forth above, the indicator comprises the value of the identification marker maintained in memory within the device. Following the output of the indicator, the determination is made Step 726 whether the indicator output is the first indicator output since receipt of input representing verification data. The loop restarts Step 706 if the determination in Step 726 is negative.
- Step 726 If the determination in Step 726 is positive, then the verification status is newly recorded by assigning Step 728 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data was received in Step 708 . The loop then restarts Step 706 .
- FIG. 8 a A fourth preferred embodiment 800 of the present invention is illustrated in FIG. 8 a , wherein a device 840 includes message data (MD) 822 representing a predefined message that is maintained in memory of the device 840 . Furthermore, it is preferred that the content of the predefined message be known in advance by the recipient, whereby the message is implicitly received by the recipient in the act of receiving a digital signature 886 for the message data 822 . However, in the event that the recipient does not have knowledge of the predefined message, the device 840 preferably includes the option of exporting the message data 822 for communication to the recipient as shown by the dotted line in FIG. 8 a.
- MD message data
- the device 840 preferably includes the option of exporting the message data 822 for communication to the recipient as shown by the dotted line in FIG. 8 a.
- the device 840 includes a digital signature component that, upon receipt of a signal (SI) 898 at the device interface 852 , originates the digital signature 886 for the message data 822 by calculating a hash value therefor at 890 and then encrypting the hash value at 892 using a private key 895 of a public-private key pair, and then outputs the digital signature 886 for transmitting to the recipient.
- SI signal
- the private key 895 is retained securely within memory 894 so that it is never exported from the device 840 and is not discoverable from outside of the device 840 .
- the digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 882 is generated using a random number generator, and the hash function at 890 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received.
- the signal 898 represents, for example, a request or command generated by the sender 820 for the communication of the digital signature 886 to the recipient or, alternatively, the signal 898 may simply comprise the receipt from the sender 820 of input representing verification data 850 by the device 840 .
- the device 840 receives input representing verification data (VD) 850 at a device interface 852 .
- the device 840 includes a verification component therein that maintains data (PD) 870 of the sender 820 prestored in memory 854 of the device 840 .
- the verification data 850 and prestored data 870 represent Secret or biometric values.
- the verification component of the device 840 identifies at 856 a current verification status of the device 840 based on a comparison of the verification data 850 with the prestored data 870 .
- the last identified (i.e., “current”) verification status of the device 840 is communicated to the recipient by outputting from the device 840 an indicator (IVS) 860 that then is transmitted to the recipient in association with the digital signature 886 .
- the signal 880 is sent to the device 840 , which triggers the device 840 to output the indicator 860 .
- the signal 880 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by the sender 820 , by the electronic apparatus 830 , or by another apparatus (not shown).
- the signal 880 may comprise the receipt of the input representing the verification data 850 itself; thus, it is possible for signal (S 1 ) 898 and signal (S 2 ) 880 to be the same signal.
- the device interface 852 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 820 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 820 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- the device 840 includes a set of predefined verification statuses each representing a relational correspondence between the verification data 850 and the prestored data 870 . Verification statuses of the set further represent whether an indicator 860 has been output from the device 840 since the last successful verification or since the last receipt of input representing verification data 850 .
- the set also contains one additional predefined verification status representing the lack of input representing verification data 850 since a resetting after a timeout or a powering on of the device 840 .
- the indicator 860 output from the device 840 is based on the last comparison of the verification data 850 with the prestored data 870 , but only if input representing verification data 850 has been received since the resetting of the device 840 . Otherwise, the indicator 860 indicates the lack of input representing verification data 850 since the resetting of the device 840 .
- the indicator 860 is transmitted with the digital signature 886 , whereby the recipient is able to identify the indicator 860 as relating to the digital signature 686 .
- the electronic apparatus 830 includes an interface (not shown) capable of receiving the indicator 860 and digital signature 886 .
- the electronic apparatus 830 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device 840 based on the indicator 860 , and for evaluating the implicit (or explicit) message received from the sender 820 based on the determined verification status.
- the electronic apparatus 830 also decrypts the digital signature 886 to confirm the authenticity of the message. The decryption is performed with the public key, which corresponds with the private key 895 and which may be received in association with the digital signature 886 or known or obtained beforehand by the recipient.
- the predefined set of verification statuses includes at least four verification statuses, comprising: a first verification status representing the lack of verification data 850 since a resetting of the device; a second verification status representing a match between the verification data 850 and the prestored data 870 , and further representing no other indicator 860 being output from the device 840 since the match; a third verification status representing a failed match between the verification data 850 and the prestored data 870 ; and a fourth verification status representing a match between the verification data 850 and the prestored data 870 , and further representing the output of an indicator 860 since the match.
- the device 840 preferably includes an identification marker (“IM”) 872 stored in memory 874 and comprising one of four binary numbers that represents the current verification status identified by the device 840 .
- the four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status.
- the indicator 860 output from the device 840 preferably includes the value of the identification marker 872 , with the correspondence of the value with the predefined verification statuses of the device being previously known by the recipient. None of the verification statuses actually reveal the verification data 850 or the prestored data 870 ; thus there is no “shared secret” between the sender 820 and the recipient. However, the recipient can infer correct knowledge of the Secret from the verification status.
- the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between the verification data 850 and prestored data 870 , together with a verification status representing the lack of input representing verification data 850 since a resetting of the device 840 .
- the predefined verification statuses comprising the percentage match of the verification data 850 with the prestored data 870 may comprise the set of percentages ranging from 0% to 100% in increments of 1%.
- each one of the verification statuses representing a percentage match also further represents whether an indicator 860 has been output from the device 840 since the last receipt of input representing verification data 850 .
- the device 840 preferably includes the identification marker 872 for storing a value representing the verification status identified by the device 840 as the current verification status. Furthermore, the indicator 860 output from the device 840 preferably comprises the value of the identification marker 872 , and the correspondence of such value with the predefined verification statuses of the device is previously known by the recipient. Again, none of the verification statuses actually reveal either of the verification data 850 or the prestored data 870 ; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of the sender from the reading of the biometric characteristic.
- FIG. 8 b A variation based on the fourth preferred embodiment 800 of FIG. 8 a is shown in FIG. 8 b , and includes an I/O support element 862 from which input representing the verification data 850 is received by the device 840 .
- the I/O support element 862 includes a user interface 858 from which input from the sender 820 is received and an I/O interface 859 that communicates the input representing the verification data 850 to the device 840 .
- FIG. 8 c Yet an additional variation thereof is shown in FIG. 8 c , wherein the I/O support element 862 receives the indicator 860 and digital signature 886 (and optionally the message data 822 ) output from the device 840 .
- the I/O support element 862 transmits the indicator 860 and the digital signature 886 (and optionally the message data 822 ) to the electronic apparatus 830 .
- the indicator 860 and digital signature 886 transmitted from the I/O support element 862 are the same as the indicator 860 and digital signature 886 output from the device 840 .
- the indicator transmitted from the I/O support element 862 may be different from the indicator output from the device 840 , so long as the recipient is able to determine the verification status as indicated by the indicator 860 output from the device 840 .
- the indicator transmitted from the I/O support element 862 may indicate not only the verification status of the device 840 , but also a verification status of the I/O support element 862 when the I/O support element 862 itself identifies a verification status.
- the indicator 860 and digital signature 886 transmitted from the I/O support element 862 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 862 .
- FIG. 8 d A further variation based on the fourth preferred embodiment 800 of FIG. 8 a is shown in FIG. 8 d , in which the message data 822 stored in the device 840 is a calculated hash value of the predefined message.
- the device 840 generates a digital signature 886 for the predefined message by directly encrypting the message data 822 at 892 , and the component 890 for calculating the hash value in FIG. 8 a is omitted from the device of FIG. 8 d .
- the recipient knows the predefined message corresponding to the message data 822 stored within the device 840 ; thus, there is no need to communicate the message (or message data 822 ) from the device 840 to the recipient.
- a preferred mode 900 of operation of the device of FIGS. 8 a , 8 b , 8 c , and 8 d is illustrated in FIG. 9 and begins with a resetting Step 904 of the device following a timeout or powering on of the device at 902 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input representing verification data and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 906 and ends at 914 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 908 whether any input representing verification data (VD) is received by the device. If the determination in Step 908 is positive, the current verification status (VS) of the device is identified Step 916 by comparing the verification data (VD) with the data prestored (PD) in memory of the device. The verification status identified then is recorded by assigning Step 918 a value to the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- VD verification data
- PD data prestored
- the next step in the loop preferably includes the determination Step 910 whether any signal S 1 is received by the device. If the determination in Step 910 is positive, the device originates Step 920 (or generates, as applicable) a digital signature for the predefined message data. The digital signature for the predefined message data is then output Step 922 from the device. If signal S 1 is not received in Step 910 or after the digital signature for the predefined message data is output in Step 922 , a determination is then made of whether a signal S 2 has been or is being received by the device. If a signal S 2 is not received, then the loop restarts Step 906 .
- Step 912 When a signal S 2 is received, the determination in Step 912 is positive and the indicator of the current verification status of the device is output Step 924 .
- the indicator comprises the value of the identification marker maintained in memory within the device.
- Step 926 Following the output of the indicator, the determination is made Step 926 whether the indicator output is the first indicator output since receipt of input representing verification data. The loop restarts Step 906 if the determination in Step 926 is negative. If the determination in Step 926 is positive, then the verification status is newly recorded by assigning Step 928 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data was received in Step 908 . The loop then restarts Step 906 .
- FIG. 10 a A fifth preferred embodiment 1000 of the present invention is illustrated in FIG. 10 a , wherein an EC 1010 including a message from a sender 1020 is received by a recipient represented by an electronic apparatus 1030 , and wherein a device 1040 receives input representing verification data for a Secret (SVD) 1051 and input representing verification data for a biometric characteristic (BVD) 1053 at a device interface 1052 .
- the device 1040 includes a verification component therein that maintains data of the sender 1020 prestored in memory of the device 1040 .
- the prestored data (SPD) 1042 is located in memory 1041 and comprises a value for a Secret
- the prestored data (BPD) 1044 is located in memory 1043 and comprises a value for a biometric characteristic.
- the verification component identifies at 1056 a current verification status of the device 1040 based on respective comparisons of the verification data 1051 , 1053 with the prestored data 1042 , 1044 .
- a signal (S) 1080 the last identified (i.e., “current”) verification status of the device 1040 is communicated to the recipient by outputting from the device 1040 an indicator 1060 that is transmitted to the recipient in association with the EC 1010 .
- the signal 1080 is sent to the device 1040 , which triggers the device 1040 to output the indicator 1060 .
- the signal 1080 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by the sender 1020 , by the electronic apparatus 1030 , or by another apparatus (not shown).
- the device interface 1052 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 1020 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- the device 1040 also receives at the device interface 1052 data (MD) 1022 representing the message of the EC 1010 .
- the message data 1022 may comprise the message (M) itself, a message digest thereof, or the result of some other processing of the message.
- the device 1040 includes a digital signature component that, upon receipt of the message data 1022 , originates a digital signature (DS) 1086 for the message data 1022 by calculating a hash value therefor at 1090 and then encrypting the hash value at 1092 using a private key 1095 of a public-private key pair. For increased reliability and trust, the private key 1095 is retained securely within memory 1094 so that it is never exported from the device 1040 and is not discoverable from outside of the device 1040 .
- DS digital signature
- the digital signature 1086 then is output from the device 1040 and transmitted to the recipient with the indicator 1060 .
- the digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 1082 is generated using a random number generator, and the hash function at 1090 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received.
- the device 1040 is configured not to hash any message data 1022 or not to hash message data 1022 if a specific instruction, signal, or command is received.
- the device 1040 also includes a set of predefined verification statuses each representing a relational correspondence between the verification data 1051 , 1053 and the prestored data 1042 , 1043 . Verification statuses of the set further represent whether an indicator 1060 has been output from the device 1040 since the last successful verification or since the last receipt of input representing verification data.
- the set also contains one additional predefined verification status representing the lack of input representing verification data 1051 since a resetting after a timeout or a powering on of the device 1040 , and one predefined verification status representing the lack of input representing verification data 1053 since a resetting after a timeout or a powering on of the device 1040 .
- the indicator 1060 output from the device 1040 is based on the last comparison of each of verification data 1051 (if received) with prestored data 1042 and of verification data 1053 (if received) with prestored data 1044 . Otherwise, the indicator 1060 indicates the lack of input representing verification data 1051 , 1053 since the resetting of the device 1040 .
- the indicator 1060 is transmitted with the digital signature 1086 in association with the EC 1010 , whereby the recipient is able to identify the indicator 1060 and digital signature 1086 as relating to the EC 1010 .
- the electronic apparatus 1030 includes an interface (not shown) capable of receiving the indicator 1060 and digital signature 1086 .
- the electronic apparatus 1030 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device 1040 based on the indicator 1060 , and for evaluating the EC 1010 received from the sender 1020 based on the determined verification status.
- the electronic apparatus 1030 also decrypts the digital signature 1086 to confirm the authenticity of the message of the EC 1010 .
- the decryption is performed with the public key, which corresponds with the private key 1095 and which may be received in association with the digital signature 1086 or known or obtained beforehand by the recipient.
- the electronic apparatus 1030 also performs any necessary processing to the message in order to produce the message digest for which the digital signature was originated.
- Verification data 1051 and prestored data 1042 represent a Secret
- a comparison of verification data 1051 received with the prestored data 1042 produces a result preferably out of four possible outcomes, including: a first outcome representing the lack of verification data 1050 since a resetting of the device 1040 ; a second outcome representing a match between the verification data 1051 and the prestored data 1042 , and further representing no other indicator 1060 being output from the device 1040 since the match; a third outcome representing a failed match between the verification data 1051 and the prestored data 1042 ; and a fourth outcome representing a match between the verification data 1051 and the prestored data 1042 , and further representing the output of an indicator 1060 since the match.
- Verification data 1053 and prestored data 1044 represent a biometric characteristic, and a comparison of verification data 1053 received with the prestored data 1044 produces a result preferably out of a predefined number of possible outcomes.
- Each outcome represents a possible percentage of match—or degree of difference—between the verification data 1053 and prestored data 1044 that is allowed, together with a verification status representing the lack of input for verification data 1053 since a resetting of the device 1040 .
- the predefined outcomes comprising the percentage match of the verification data 1053 with the prestored data 1044 may comprise the set of percentages ranging from 0% to 100% in increments of 1%.
- each one of the outcomes representing a percentage match also further represents whether an indicator 1060 has been output from the device 1040 since the last receipt of input representing verification data 1053 .
- the device 1040 preferably includes an identification marker (“IM”) 1072 stored in memory 1074 and comprising one of the set of predefined verification statuses of the device.
- the set of predefined verification statuses preferably comprises all of the possible combinations of outcomes from the comparison of the verification data 1051 with the prestored data 1042 in addition to all of the possible outcomes from the comparison of the verification data 1053 with the prestored data 1044 .
- the indicator 1060 output from the device 1040 preferably includes the value of the identification marker 1072 , with the correspondence of the value of the identification marker with the predefined verification statuses of the device 1040 being previously known by the recipient.
- FIG. 10 b A variation based on the fifth preferred embodiment 1000 of FIG. 10 a is shown in FIG. 10 b , and includes an I/O support element 1062 from which input representing the verification data 1051 , 1053 and input representing the message data 1022 is received by the device 1040 .
- the I/O support element 1062 includes a user interface 1058 from which input from the sender 1020 is received and an I/O interface 1059 that communicates the input representing the verification data 1051 , 1053 to the device 1040 .
- the message data 1022 is shown coming from the I/O support element 1062 , it is possible for some or all of the message data 1022 to originate with the device 1040 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG.
- the I/O support element 1062 receives the indicator 1060 and digital signature 1086 output from the device 1040 .
- the I/O support element 1062 transmits the indicator 1060 and the digital signature 1086 to the electronic apparatus 1030 .
- the indicator 1060 and digital signature 1086 transmitted from the I/O support element 1062 are the same as the indicator 1060 and digital signature 1086 output from the device 1040 .
- the indicator transmitted from the I/O support element 1062 may be different from the indicator output from the device 1040 , so long as the recipient is able to determine the verification status as indicated by the indicator 1060 output from the device 1040 .
- the indicator transmitted from the I/O support element 1062 may indicate not only the verification status of the device 1040 , but also a verification status of the I/O support element 1062 when the I/O support element 1062 itself identifies a verification status.
- the indicator 1060 and digital signature 1086 transmitted from the I/O support element 1062 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 1062 .
- the EC 1010 is shown as being transmitted separate from the indicator 1060 and digital signature 1086 .
- the indicator 1060 and digital signature 1086 equally may be associated with the EC 1010 by being transmitted as part of the EC 1010 .
- the EC 1010 may be output from the device 1040 , an associated I/O support element 1062 (not shown in FIG. 10 a ), or other apparatus.
- FIG. 11 A preferred mode 1100 of operation of the device of FIGS. 10 a , 10 b , and 10 c is illustrated in FIG. 11 and begins with a resetting Step 1104 of the device following a timeout or powering on of the device at 1102 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input for verification data for either a Secret or a biometric characteristic and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 1106 and ends at 1116 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 1108 whether any input representing verification data for the Secret (SVD) is received by the device. If the determination in Step 1108 is positive, the current verification status (VS) of the device is identified Step 1118 by comparing the Secret verification data (SVD) with the data for the Secret (SPD) prestored in the memory of the device. The verification status identified then is recorded by assigning Step 1120 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- the next step in the loop preferably includes the determination Step 1110 whether any input representing verification data for the biometric characteristic (BVD) is received by the device. If the determination in Step 1110 is positive, the current verification status (VS) of the device is identified Step 1122 by comparing the biometric verification data (BVD) with the biometric data (BPD) prestored in the memory of the device. The verification status identified then is recorded by assigning Step 1124 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- the determination Step 1110 is positive
- the current verification status (VS) of the device is identified Step 1122 by comparing the biometric verification data (BVD) with the biometric data (BPD) prestored in the memory of the device.
- the verification status identified then is recorded by assigning Step 1124 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- Step 1110 If no input representing verification data for the biometric characteristic is received in Step 1110 or after the value of the identification marker is recorded in Step 1124 , the next step in the loop preferably includes the determination Step 1112 whether any input representing message data (MD) is received by the device. If the determination in Step 1112 is positive, the device originates Step 1126 a digital signature for the message data. The digital signature for the message data is then output Step 1128 from the device.
- MD message data
- Step 1114 determines whether a signal (S) has been or is being received by the device. If a signal is not received, then the loop restarts Step 1106 . When a signal is received, the determination in Step 1114 is positive and the indicator of the current verification status of the device is output Step 1130 . As set forth above, the indicator comprises the value of the identification marker maintained in memory within the device. Following the output of the indicator, the determination is made Step 1132 whether the indicator output is the first indicator output since receipt of input representing verification data for the Secret.
- Step 1132 If the determination in Step 1132 is positive, then the verification status is newly recorded by assigning Step 1136 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data for the Secret was received in Step 1108 . If the determination in Step 1132 is negative or after the value of the identification marker is newly recorded in Step 1136 , the determination is made Step 1134 whether the indicator output is the first indicator output since receipt of input representing verification data for the biometric characteristic.
- Step 1134 If the determination in Step 1134 is positive, then the verification status is newly recorded by assigning Step 1138 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data for the biometric characteristic was received in Step 1110 . If the determination in Step 1134 is negative or after the value of the identification marker is newly recorded in Step 1138 , then the loop restarts Step 1106 .
- FIG. 12 a A sixth preferred embodiment 1200 of the present invention is illustrated in FIG. 12 a , wherein an EC 1210 including a message from a sender 1220 is received by a recipient represented by an electronic apparatus 1230 , and wherein a device 1240 receives input representing verification data (VD) 1250 at a device interface 1252 .
- the device interface 1252 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 1220 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- the device 1240 includes a verification component therein that maintains data (PD) 1270 of the sender 1220 prestored in memory 1254 .
- the verification data 1250 and prestored data 1270 represent Secret or biometric values.
- the verification component identifies at 1256 a current verification status of the device 1240 based on a comparison of the verification data 1250 with the prestored data 1270 and records the last identified (i.e., “current”) verification status of the device 1240 by assigning a value to an identification marker (IM) 1272 that is stored in memory 1274 .
- IM identification marker
- the device 1240 also receives at the device interface 1252 data (MD) 1222 representing the message of the EC 1210 .
- the message data may comprise the message itself, a message digest thereof, or the result of some other processing of the message (M).
- the digital signature component then originates a digital signature 1299 for the modified message data (MD′) by calculating a hash value therefor at 1290 and then encrypting the hash value at 1292 using a private key 1295 of a public-private key pair.
- the private key 1295 is retained securely within memory 1294 so that it is never exported from the device 1240 and is not discoverable from outside of the device 1240 .
- the digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 1299 is generated using a random number generator, and the hash function at 1290 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received.
- the digital signature 1299 then is output from the device 1240 for transmitting to the recipient as the indicator 1260 of the verification status of the device 1240 .
- the digital signature 1299 output from the device 1240 actually comprises the indicator of the verification status (IVS) 1260 as a result of the modification process.
- the indicator 1260 then is transmitted to the recipient in association with the EC 1210 , whereby the recipient is able to identify the indicator 1260 as pertaining to the EC 1210 .
- the device 1240 includes a set of predefined verification statuses each representing a relational correspondence between the verification data 1250 and the prestored data 1270 . Verification statuses of the set further represent whether an indicator 1260 has been output from the device 1240 since the last successful verification or since the last receipt of input representing verification data.
- the set also contains an additional predefined verification status representing the lack of input representing verification data 1250 since a resetting after a timeout or a powering on of the device 1240 .
- the indicator 1260 output from the device 1240 is based on the last comparison of the verification data 1250 with the prestored data 1270 , but only if input representing verification data 1250 has been received since the resetting of the device 1240 . Otherwise, the indicator 1260 indicates the lack of input representing verification data 1250 since the resetting of the device 1240 .
- the electronic apparatus 1230 includes an interface (not shown) capable of receiving the indicator 1260 .
- the electronic apparatus 1230 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on the indicator 1260 and for evaluating the EC 1210 received from the sender 1220 based on the determined verification status.
- the electronic apparatus 1230 decrypts the digital signature with the public key, which corresponds to the private key 1295 and which may be received in association with the digital signature or known or obtained beforehand by the recipient.
- the recipient also modifies—and then calculates a hash value for—the message for each one of the predefined verification statuses of the device until the calculated hash value equals the hash value of the decrypted digital signature.
- the electronic apparatus 1230 In calculating a hash value for comparison, the electronic apparatus 1230 also performs any necessary processing to the message in order to produce the message data that was modified within the device 1240 .
- the hash value calculated by the recipient equals the hash value of the decrypted digital signature
- the recipient thereby determines the current verification status of the device 1240 . This determination also confirms the authenticity of the message of the EC 1210 .
- the set of verification statuses of the device is predefined to contain only a limited number of verification statuses when this particular device 1240 of the preferred embodiment 1200 is used.
- the predefined set of verification statuses includes four verification statuses, comprising: a first verification status representing the lack of verification data 1250 since a resetting of the device; a second verification status representing a match between the verification data 1250 and the prestored data 1270 , and further representing no other indicator 1260 being output from the device 1240 since the match; a third verification status representing a failed match between the verification data 1250 and the prestored data 1270 ; and a fourth verification status representing a match between the verification data 1250 and the prestored data 1270 , and further representing the output of an indicator 1260 since the match.
- the identification marker 1272 stored in memory 1274 preferably comprises one of four binary numbers that represents the current verification status identified by the device 1240 .
- the correspondence between the values of the identification marker 1272 and the predefined verification statuses of the device should be previously known by the recipient.
- the four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status.
- the modification of the message data 1222 at 1277 preferably includes the embedding of the value of the identification marker 1272 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data.
- the “modification” of the message data for one of the verification statuses may include not modifying the message data, such as when the identification marker 1272 equals “00.” Even in this case, however, the digital signature 1299 identifies the verification status of the device as representing the lack of verification data 1250 being received since a resetting of the device. Furthermore, it will be appreciated that the digital signature 1299 for the modified message neither reveals the verification data 1250 nor the prestored data 1270 ; thus, no “shared secret” is required between the sender and the recipient in the preferred embodiment 1200 . However, the recipient can infer correct knowledge of the Secret from the verification status.
- the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between the verification data 1250 and prestored data 1270 , together with a verification status representing the lack of input representing verification data 1250 since a resetting of the device 1240 .
- the predefined verification statuses comprising the percentage match of the verification data 1250 with the prestored data 1270 may comprise the set of percentages ranging from 0% to 100% in increments of, in this embodiment, 20%.
- each one of the verification statuses representing a percentage match also further represents whether an indicator 1260 has been output from the device 1240 since the last receipt of input representing verification data 1250 .
- the identification marker 1272 stored in memory 1274 preferably comprises the percentage match plus a flag regarding the output of the indicator 1260 as identified by the device 1240 .
- the correspondence between the values of the identification marker 1272 and the predefined verification statuses of the device 1240 should be previously known by the recipient.
- the modification of the message data 1222 at 1277 preferably includes the embedding of the value of the identification marker 1272 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data.
- the “modification” of the message data for one of the verification statuses may include not modifying the message data, such as when no verification data 1250 has been received since a resetting of the device 1240 .
- the digital signature 1299 identifies the verification status of the device 1240 as representing the lack of verification data 1250 being received since a resetting of the device 1240 . Furthermore, it will be appreciated that the digital signature 1299 for the modified message neither reveals the verification data 1250 nor the prestored data 1270 ; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of the sender 1220 from the reading of the biometric characteristic.
- FIG. 12 b A variation based on the sixth preferred embodiment 1200 of FIG. 12 a is shown in FIG. 12 b , and includes an I/O support element 1262 from which input representing the verification data 1250 and input representing the message data 1222 is received by the device 1240 .
- the I/O support element 1262 includes a user interface 1258 from which input from the sender 1220 is received and an I/O interface 1259 that communicates the input representing the verification data 1250 and input representing the message data 1222 to the device 1240 .
- the message data 1222 is shown coming from the I/O support element 1262 , it is possible for some or all of the message data 1222 to originate with the device 1240 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG.
- the I/O support element 1262 receives the indicator 1260 being output from the device 1240 .
- the I/O support element 1262 transmits the indicator 1260 to the electronic apparatus 1230 .
- the indicator 1260 transmitted from the I/O support element 1262 is the same as the indicator 1260 output from the device 1240 .
- the indicator 1260 transmitted from the I/O support element 1262 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 1262 .Furthermore, in FIGS. 12 a , 12 b , and 12 c , the EC 1210 is shown as being transmitted separate from the indicator 1260 . However, in the preferred embodiment of FIG.
- the indicator 1260 equally may be associated with the EC 1210 by being transmitted as part of the EC 1210 . Furthermore, the EC 1210 may be output from the device 1240 , an associated I/O support element 1262 (not shown in FIG. 12 a ), or other apparatus.
- a preferred mode 1300 of operation of the device of FIGS. 12 a , 12 b , and 12 c is illustrated in FIG. 13 and begins with a resetting Step 1304 of the device following a timeout or powering on of the device at 1302 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input of verification data and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 1306 and ends at 1312 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 1308 whether any input representing verification data is received by the device. If the determination in Step 1308 is positive, the current verification status (VS) of the device is identified Step 1314 by comparing the verification data (VD) with the data (PD) prestored in the memory of the device. The verification status identified then is recorded by assigning Step 1316 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- Step 1308 If no input representing verification data is received in Step 1308 or after the value of the identification marker is recorded in Step 1316 , the next step in the loop preferably includes the determination Step 1310 whether any input representing message data (MD) is received by the device. If the determination in Step 1310 is negative, the loop restarts Step 1306 .
- MD message data
- Step 1310 If the determination in Step 1310 is positive, the device then modifies Step 1318 the message data based on the identification marker. Next, the device originates Step 1320 a digital signature for the modified message data. The digital signature for the modified message data is then output Step 1322 from the device. Following the output of the digital signature for the modified message, the determination is made Step 1324 whether the digital signature output is the first digital signature output since receipt of input for verification data in Step 1308 . The loop restarts Step 1306 if the determination in Step 1324 is negative. If the determination in Step 1324 is positive, then the verification status is newly recorded Step 1326 by assigning a value to the identification marker that represents the verification status indicated by the digital signature output in Step 1322 , and that further represents the fact that the digital signature has been output. The loop then restarts Step 1306 .
- a seventh preferred embodiment 1400 of the present invention is illustrated in FIG. 14 a , wherein an EC 1410 including a message from a sender 1420 is received by a recipient represented by an electronic apparatus 1430 , and wherein a device 1440 receives input representing verification data (VD) 1450 at a device interface 1452 .
- the device interface 1452 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 1420 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- the device 1440 includes a verification component therein that maintains data (PD) 1470 of the sender 1420 prestored in memory 1454 .
- the verification data 1450 and prestored data 1470 represent Secret or biometric values.
- the verification component identifies at 1456 a current verification status of the device 1440 based on a comparison of the verification data 1450 with the prestored data 1470 and records the last identified (i.e., “current”) verification status of the device 1440 by assigning a value to an identification marker (IM) 1472 that is stored in memory 1474 .
- IM identification marker
- the device 1440 also receives at the device interface 1452 message data (MD) 1422 representing the message (M) of the EC 1410 .
- the message data 1422 may comprise the message itself, a message digest thereof, or the result of some other processing of the message.
- the digital signature component then originates a digital signature 1499 for the modified message data (MD′) by calculating a hash value therefor at 1490 and then encrypting the hash value at 1492 using a private key 1495 of a public-private key pair.
- the private key 1495 is retained securely within memory 1494 so that it is never exported from the device 1440 and is not discoverable from outside of the device 1440 .
- the digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 1499 is generated using a random number generator, and the hash function at 1490 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received.
- the digital signature 1499 then is output from the device 1440 together with the value of the identification marker 1472 as the indicator 1460 of the verification status (IVS) of the device 1440 for transmitting to the recipient.
- the digital signature 1499 and the indicator 1460 then are transmitted to the recipient in association with the EC 1410 , whereby the recipient is able to identify the indicator 1460 as pertaining to the EC 1410 .
- the device 1440 includes a set of predefined verification statuses each representing a relational correspondence between the verification data 1450 and the prestored data 1470 . Verification statuses of the set further represent whether an indicator 1460 has been output from the device 1440 since the last successful verification or since the last receipt of input representing verification data.
- the set also contains an additional predefined verification status representing the lack of input representing verification data 1450 since a resetting after a timeout or a powering on of the device 1440 .
- the indicator 1460 output from the device 1440 is based on the last comparison of the verification data 1450 with the prestored data 1470 , but only if input representing verification data 1450 has been received since the resetting of the device 1440 . Otherwise, the indicator 1460 indicates the lack of input representing verification data 1450 since the resetting of the device 1440 .
- the electronic apparatus 1430 includes an interface (not shown) capable of receiving the indicator 1460 .
- the electronic apparatus 1430 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on the indicator 1460 and for evaluating the EC 1410 received from the sender 1420 based on the determined verification status.
- the electronic apparatus 1430 decrypts the digital signature with the public key, which corresponds to the private key 1495 and which may be received in association with the digital signature 1499 or known or obtained beforehand by the recipient.
- the recipient also modifies—and then calculates a hash value for—the message based on the verification status identified by the indicator 1460 .
- the electronic apparatus 1430 In calculating a hash value for comparison, the electronic apparatus 1430 also performs any necessary processing to the message in order to produce the message data that was modified within the device 1440 .
- the hash value calculated by the recipient equals the hash value of the decrypted digital signature
- the recipient confirms the authenticity of the current verification status of the device 1440 as indicated by the indicator 1460 as well as confirms the authenticity of the message of the EC 1410 .
- the predefined set of verification statuses includes four verification statuses, comprising: a first verification status representing the lack of verification data 1450 since a resetting of the device; a second verification status representing a match between the verification data 1450 and the prestored data 1470 , and further representing no other indicator 1460 being output from the device 1440 since the match; a third verification status representing a failed match between the verification data 1450 and the prestored data 1470 ; and a fourth verification status representing a match between the verification data 1450 and the prestored data 1470 , and further representing the output of an indicator 1460 since the match.
- the identification marker 1472 stored in memory 1474 preferably comprises one of four binary numbers that represents the current verification status identified by the device 1440 .
- the correspondence between the values of the identification marker 1472 and the predefined verification statuses of the device should be previously known by the recipient.
- the four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status.
- the modification of the message data 1422 at 1477 preferably includes the embedding of the value of the identification marker 1472 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data.
- the “modification” of the message data for one of the verification statuses may include not modifying the message data, such as when the identification marker 1472 equals “00.” Even in this case, however, the digital signature 1499 identifies the verification status of the device as representing the lack of verification data 1450 being received since a resetting of the device. Furthermore, it will be appreciated that neither the digital signature 1499 for the modified message nor the indicator 1460 reveals the verification data 1450 or the prestored data 1470 ; thus, no “shared secret” is required between the sender 1420 and the recipient in the preferred embodiment 1400 . However, the recipient can infer correct knowledge of the Secret from the verification status.
- the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between the verification data 1450 and prestored data 1470 , together with a verification status representing the lack of input representing verification data 1450 since a resetting of the device 1440 .
- the predefined verification statuses comprising the percentage match of the verification data 1450 with the prestored data 1470 may comprise the set of percentages ranging from 0% to 100% in increments of 1%.
- each one of the verification statuses representing a percentage match also further represents whether an indicator 1460 has been output from the device 1440 since the last receipt of input representing verification data 1450 .
- the identification marker 1472 stored in memory 1474 preferably comprises the percentage match plus a flag regarding the output of the indicator 1460 as identified by the device 1440 .
- the correspondence between the values of the identification marker 1472 and the predefined verification statuses of the device 1440 should be previously known by the recipient.
- the modification of the message data 1422 at 1477 preferably includes the embedding of the value of the identification marker 1472 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data.
- the “modification” of the message data for one of the verification statuses may include not modifying the message data, such as when no verification data 1450 has been received since a resetting of the device 1440 . Even in this case, however, the digital signature 1499 identifies the verification status of the device 1440 as representing the lack of verification data 1450 being received since a resetting of the device 1440 .
- FIG. 14 b A variation based on the seventh preferred embodiment 1400 of FIG. 14 a is shown in FIG. 14 b , and includes an I/O support element 1462 from which input representing the verification data 1450 and input representing the message data 1422 is received by the device 1440 .
- the I/O support element 1462 includes a user interface 1458 from which input from the sender 1420 is received and an I/O interface 1459 that communicates the input representing the verification data 1450 and input representing the message data 1422 to the device 1440 .
- the message data 1422 is shown coming from the I/O support element 1462 , it is possible for some or all of the message data 1422 to originate with the device 1440 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG.
- the I/O support element 1462 receives the indicator 1460 and digital signature 1499 output from the device 1440 .
- the I/O support element 1462 transmits the indicator 1460 and the digital signature 1499 to the electronic apparatus 1430 .
- the indicator 1460 and digital signature 1499 transmitted from the I/O support element 1462 are the same as the indicator 1460 and digital signature 1486 output from the device 1440 .
- the indicator transmitted from the I/O support element 1462 may be different from the indicator output from the device 1440 , so long as the recipient is able to determine both the verification status as indicated by the indicator 1460 output from the device 1440 , as well as the bit pattern of the identification marker 1472 based on which the message was modified.
- the indicator transmitted from the I/O support element 1462 may indicate not only the verification status of the device 1440 , but also a verification status of the I/O support element 1462 when the I/O support element 1462 itself identifies a verification status.
- the indicator 1460 and digital signature 1499 transmitted from the I/O support element 1462 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 1462 .
- the EC 1410 is shown as being transmitted separate from the indicator 1460 and digital signature 1499 .
- the indicator 1460 and digital signature 1499 equally may be associated with the EC 1410 by being transmitted as part of the EC 1410 .
- the EC 1410 may be output from the device 1440 , an associated I/O support element 1462 (not shown in FIG. 14 a ), or other apparatus.
- a preferred mode 1500 of operation of the device of FIGS. 14 a , 14 b , and 14 c is illustrated in FIG. 15 and begins with a resetting Step 1504 of the device following a timeout or powering on of the device at 1502 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input of verification data and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 1506 and ends at 1512 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 1508 whether any input representing verification data is received by the device. If the determination in Step 1508 is positive, the current verification status (VS) of the device is identified Step 1514 by comparing the verification data (VD) with the data (PD) prestored in the memory of the device. The verification status identified then is recorded by assigning Step 1516 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- Step 1508 If no input representing verification data is received in Step 1508 or after the value of the identification marker is recorded in Step 1516 , the next step in the loop preferably includes the determination Step 1510 whether any input representing message data (MD) is received by the device. If the determination in Step 1510 is negative, the loop restarts Step 1506 .
- MD message data
- Step 1510 If the determination in Step 1510 is positive, the device then modifies Step 1518 the message data based on the identification marker. Next, the device originates Step 1520 a digital signature for the modified message data. The digital signature for the modified message data and the value of the identification marker are then output Step 1522 from the device. Following the output of the digital signature for the modified message and value of the identification marker, the determination is made Step 1524 whether the value of the identification marker output is the first value thereof output since receipt of input representing verification data in Step 1508 . The loop restarts Step 1506 if the determination in Step 1524 is negative.
- Step 1524 If the determination in Step 1524 is positive, then the verification status is newly recorded Step 1526 by assigning a value to the identification marker that represents the verification status identified by the value of the identification marker output in Step 1522 , and that further represents the fact that the value of the identification marker has been output. The loop then restarts Step 1506 .
- FIG. 16 a An eighth preferred embodiment 1600 of the present invention is illustrated in FIG. 16 a , wherein an EC 1610 including a message from a sender 1620 is received by a recipient represented by an electronic apparatus 1630 , and wherein a device 1640 receives input representing first verification data (VD 1 ) 1651 and input representing second verification data (VD 2 ) 1653 at a device interface 1652 .
- VD 1 first verification data
- VD 2 second verification data
- the device interface 1652 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 1620 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 1620 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- the device 1640 includes a verification component therein that maintains data prestored in memory of the device 1640 .
- the first prestored data (PD 1 ) 1642 is located in memory 1641
- the second prestored data (PD 2 ) 1644 is located in memory 1643 .
- the verification component identifies at 1656 a current verification status of the device 1640 based on a comparison of the first verification data 1651 with the first prestored data 1642 and the second verification data 1653 with the second prestored data 1644 , and records the latest (i.e., “current”) verification status of the device 1640 by assigning a value to an identification marker (IM) 1672 stored in memory 1674 .
- IM identification marker
- the device 1640 also receives at the device interface 1652 message data (MD) 1622 representing the message (M) of the EC 1610 .
- the message data 1622 may comprise the message itself, a message digest thereof, or the result of some other processing of the message.
- the modification of the message preferably includes the embedding of the value of the identification marker 1672 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data.
- the “modification” of the message data for one of the verification statuses may include not modifying the message data.
- the digital signature component then originates a digital signature 1699 for the modified message data (MD′) by calculating a hash value therefor at 1690 and then encrypting the hash value at 1692 using a private key 1695 of a public-private key pair.
- the private key 1695 is retained securely within memory 1694 so that it is never exported from the device 1640 and is not discoverable from outside of the device 1640 .
- the digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 1699 is generated using a random number generator, and the hash function at 1690 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received.
- the digital signature 1699 then is output from the device 1640 together with the value of the identification marker 1672 as the indicator 1660 of the verification status (IVS) of the device 1640 for transmitting to the recipient.
- the digital signature 1699 and the indicator 1660 then are transmitted to the recipient in association with the EC 1610 , whereby the recipient is able to identify the indicator 1660 as pertaining to the EC 1610 .
- the device 1640 includes a set of predefined verification statuses each representing a relational correspondence between the verification data 1651 , 1653 and the prestored data 1642 , 1644 . Verification statuses of the set further represent whether an indicator 1660 has been output from the device 1640 since the last successful verification based on either or both of the first and second verification data 1651 , 1653 , or since the last receipt of input representing either or both of the first and second verification data 1651 , 1653 .
- the set also contains a predefined verification status representing the lack of input of both first and second verification data 1651 , 1653 since a resetting after a timeout or a powering on of the device 1640 .
- the indicator 1660 output from the device 1640 is based on the last respective comparison of verification data with the prestored data, but only if input representing the respective verification data has been received since the resetting of the device 1640 . Otherwise, the indicator 1660 indicates the lack of input for both the first and second verification data 1651 , 1653 since the resetting of the device 1640 .
- the electronic apparatus 1630 includes an interface (not shown) capable of receiving the indicator 1660 .
- the electronic apparatus 1630 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on the indicator 1660 and for evaluating the EC 1610 received from the sender 1620 based on the determined verification status.
- the electronic apparatus 1630 decrypts the digital signature with the public key, which corresponds to the private key 1695 and which may be received in association with the digital signature 1699 or known or obtained beforehand by the recipient.
- the recipient also modifies—and to then calculates a hash value for—the message based on the verification status identified by the indicator 1660 .
- the electronic apparatus 1630 In calculating a hash value for comparison, the electronic apparatus 1630 also performs any necessary processing to the message in order to produce the message data that was modified within the device 1640 .
- the hash value calculated by the recipient equals the hash value of the decrypted digital signature
- the recipient confirms the authenticity of the current verification status of the device 1640 as indicated by the indicator 1660 as well as confirms the authenticity of the message of the EC 1610 .
- the predefined set of results for the comparison for such includes four possible outcomes, comprising: a first outcome representing the lack of verification data since a resetting of the device 1640 ; a second outcome representing a match between the verification data and the prestored data, and further representing no other indicator 1660 being output from the device 1640 since the match; a third outcome representing a failed match between the verification data and the prestored data; and a fourth outcome representing a match between the verification data and the prestored data, and further representing the output of an indicator 1660 since the match.
- the predefined set of results for the comparison for such produces a result preferably out of a predefined number of possible outcomes.
- Each outcome represents a possible percentage of match—or degree of difference—between the verification data and prestored data that is allowed, together with a verification status representing the lack of input for verification data since a resetting of the device 1640 .
- the predefined outcomes comprising the percentage match of the verification data with the prestored data may comprise the set of percentages ranging from 0% to 100% in increments of 1%.
- each one of the outcomes representing a percentage match also further represents whether an indicator 1660 has been output from the device 1640 since the last receipt of input representing verification data.
- the identification marker 1672 is stored in memory 1674 and comprises a value representing one of the set of predefined verification statuses of the device 1640 .
- the set of predefined verification statuses preferably comprises all of the possible combinations of outcomes from the respective comparisons for the first and second verification data 1651 , 1653 .
- the correspondence of the possible values for the identification marker 1672 with the predefined verification statuses of the device 1640 should be previously known by the recipient.
- none of the verification statuses actually reveal any of the verification data 1651 , 1653 or the prestored data 1642 , 1644 ; thus, no “shared secret” is required between the sender 1620 and the recipient, and no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient.
- the recipient can infer from the verification status both the correct knowledge of the Secret and the presence of the sender from the reading of the biometric characteristic.
- FIG. 16 b A variation based on the eighth preferred embodiment 1600 of FIG. 16 a is shown in FIG. 16 b , and includes an I/O support element 1662 from which input representing the first and second verification data 1651 , 1653 and input representing the message data 1622 is received by the device 1640 .
- the I/O support element 1662 includes a user interface 1658 from which input from the sender 1620 is received and an I/O interface 1659 that communicates the input representing the first and second verification data 1651 , 1653 and input representing the message data 1622 to the device 1640 .
- the message data 1622 is shown coming from the I/O support element 1662 , it is possible for some or all of the message data 1622 to originate with the device 1640 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG. 16 c , wherein the I/O support element 1662 receives the indicator 1660 and digital signature 1699 output from the device 1640 . The I/O support element 1662 , in turn, transmits the indicator 1660 and the digital signature 1699 to the electronic apparatus 1630 .
- the indicator 1660 and digital signature 1699 transmitted from the I/O support element 1662 are the same as the indicator 1660 and digital signature 1686 output from the device 1640 .
- the indicator transmitted from the I/O support element 1662 may be different from the indicator output from the device 1640 , so long as the recipient is able to determine both the verification status as indicated by the indicator 1660 output by the device 1640 , as well as the bit pattern of the identification marker 1672 based on which the message was modified.
- the indicator transmitted from the I/O support element 1662 may indicate not only the verification status of the device 1640 , but also a verification status of the I/O support element 1662 when the I/O support element 1662 itself identifies a verification status.
- the indicator 1660 and digital signature 1699 transmitted from the I/O support element 1662 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 1662 .
- the EC 1610 is shown as being transmitted separate from the indicator 1660 and digital signature 1699 .
- the indicator 1660 and digital signature 1699 equally may be associated with the EC 1610 by being transmitted as part of the EC 1610 .
- the EC 1610 may be output from the device 1640 , an associated I/O support element 1662 (not shown in FIG. 16 a ), or other apparatus.
- a preferred mode 1700 of operation of the device of FIGS. 16 a , 16 b , and 16 c is illustrated in FIG. 17 and begins with a resetting Step 1704 of the device following a timeout or powering on of the device at 1702 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input of any verification data and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 1706 and ends at 1714 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 1708 whether any input representing the first verification data (VD 1 ) is received by the device. If the determination in Step 1708 is positive, the current verification status (VS) of the device is identified Step 1716 by comparing the first verification data (VD 1 ) with the first data (PD 1 ) prestored in the memory of the device. The verification status identified then is recorded by assigning Step 1718 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- the next step in the loop preferably includes the determination Step 1710 whether any input representing the second verification data (VD 2 ) is received by the device. If the determination in Step 1710 is positive, the current verification status (VS) of the device is identified Step 1720 by comparing the second verification data (VD 2 ) with the second data (PD 2 ) prestored in the memory of the device. The verification status identified then is recorded by assigning Step 1722 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- Step 1710 If no input representing the second verification data is received in Step 1710 or after the value of the identification marker is recorded in Step 1722 , the next step in the loop preferably includes the determination Step 1712 whether any input representing message data (MD) is received by the device. If the determination in Step 1712 is negative, the loop restarts Step 1706 .
- MD message data
- Step 1712 If the determination in Step 1712 is positive, the device then modifies Step 1724 the message data based on the identification marker. Next, the device originates Step 1726 a digital signature for the modified message data. The digital signature for the modified message data and the value of the identification marker are then output Step 1728 from the device. Following the output of the digital signature for the modified message and value of the identification marker, the determination is made Step 1730 whether the value of the identification marker output is the first value thereof output since receipt of input representing the first verification data in Step 1708 .
- Step 1734 If the determination in Step 1730 is positive, then the verification status is newly recorded Step 1734 by assigning a value to the identification marker that represents the verification status identified by the value of the identification marker output in Step 1728 , and that further represents the fact that the value of the identification marker has been output. If the determination in Step 1730 is negative or after the value of the identification marker is newly recorded in Step 1734 , the next step in the loop preferably includes the determination Step 1732 whether the value of the identification marker output is the first value thereof output since receipt of input representing the second verification data in Step 1710 .
- Step 1732 If the determination in Step 1732 is positive, then the verification status is newly recorded Step 1736 by assigning a value to the identification marker that represents the verification status identified by the value of the identification marker output in Step 1728 , and that further represents the fact that the value of the identification marker has been output. If the determination in Step 1732 is negative or after the value of the identification marker is newly recorded in Step 1736 , the loop then restarts Step 1706 .
- FIG. 18 a A ninth preferred embodiment 1800 of the present invention is illustrated in FIG. 18 a , wherein an EC 1810 including a message from a sender 1820 is received by a recipient represented by an electronic apparatus 1830 , and wherein a device 1840 receives input representing first verification data (VD 1 ) 1851 and input representing second verification data (VD 2 ) 1853 at a device interface 1852 .
- VD 1 first verification data
- VD 2 second verification data
- the device interface 1852 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 1820 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from the sender 1820 ; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port.
- the device 1840 includes a verification component therein that maintains data prestored in memory of the device 1840 .
- the first prestored data (PD 1 ) 1842 is located in memory 1841
- the second prestored data (PD 2 ) 1844 is located in memory 1843 .
- the verification component identifies at 1856 a current verification status of the device 1840 based on a comparison of the first verification data 1851 with the first prestored data 1842 and the second verification data 1853 with the second prestored data 1844 , and records the latest (i.e., “current”) verification status of the device 1840 by assigning a value to an identification marker (IM) 1872 stored in memory 1874 .
- the identification marker 1872 comprises a value assigned to a first comparison marker representing the result of the first comparison and a value assigned to a second comparison marker representing the result of the second comparison.
- the device 1840 also receives at the device interface 1852 message data (MD) 1822 representing the message (M) of the EC 1810 .
- the message data 1822 may comprise the message itself, a message digest thereof, or the product of some other processing of the message.
- the modification of the message preferably includes the embedding of the value of the identification marker 1872 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data.
- the “modification” of the message data for one of the verification statuses may include not modifying the message data.
- the digital signature component then originates a digital signature 1899 for the modified message data (MD′) by calculating a hash value therefor at 1890 and then encrypting the hash value at 1892 using a private key 1895 of a public-private key pair.
- the private key 1895 is retained securely within memory 1894 so that it is never exported from the device 1840 and is not discoverable from outside of the device 1840 .
- the digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 1899 is generated using a random number generator, and the hash function at 1890 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received.
- the digital signature 1899 then is output from the device 1840 as the indicator 1860 of the verification status (IVS) of the device 1840 for transmitting to the recipient.
- the digital signature 1899 output from the device 1840 actually comprises the indicator of the verification status (IVS) 1860 as a consequence of the modification process.
- the current outcome of the first comparison (results of VD 1 and PD 1 comparison) is also output as a result (R) 1896 .
- the indicator 1860 and result 1896 then are transmitted to the recipient in association with the EC 1810 , whereby the recipient is able to identify the indicator 1860 and result 1896 as pertaining to the EC 1810 .
- the device 1840 includes a set of predefined verification statuses each representing a relational correspondence between the verification data 1851 , 1853 and the prestored data 1842 , 1844 .
- Verification statuses of the set further represent whether an indicator 1860 has been output from the device 1840 since the last successful verification based on either or both of the first and second verification data 1851 , 1853 , or since the last receipt of input representing either or both of the first and second verification data 1851 , 1853 .
- the set also contains a predefined verification status representing the lack of input of both first and second verification data 1851 , 1853 since a resetting after a timeout or a powering on of the device 1840 .
- the indicator 1860 output from the device 1840 is based on the last respective comparisons of verification data with the prestored data, but only if input representing verification data has been received since the resetting of the device 1840 . Otherwise, the indicator 1860 indicates the lack of input for both the first and second verification data 1851 , 1853 since the resetting of the device 1840 .
- the electronic apparatus 1830 includes an interface (not shown) capable of receiving the indicator 1860 .
- the electronic apparatus 1830 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on the indicator 1860 and for evaluating the EC 1810 received from the sender 1820 based on the determined verification status.
- the electronic apparatus 1830 decrypts the digital signature with the public key, which corresponds to the private key 1895 and which may be received in association with the digital signature 1899 or known or obtained beforehand by the recipient.
- the recipient also modifies—and then calculates a hash value for—the message based on the result 1896 and for each possible outcome of the second comparison until the calculated hash value equals the hash value of the decrypted digital signature.
- the electronic apparatus 1830 also performs any necessary processing to the message in order to produce the message data that was modified within the device 1840 .
- the recipient determines the current verification status of the device 1840 . This determination also confirms the authenticity of the message of the EC 1810 .
- the second set of outcomes for the second comparison (VD 2 with PD 2 ) is predefined to contain only a limited number of outcomes.
- the first verification data and prestored data therefor A preferably represent a biometric characteristic
- the second verification data and prestored data therefor preferably represent a Secret.
- the predefined set of outcomes for the comparison for such includes four possible outcomes, comprising: a first outcome representing the lack of verification data since a resetting of the device 1840 ; a second outcome representing a match between the verification data and the prestored data, and further representing no other indicator 1860 being output from the device 1840 since the match; a third outcome representing a failed match between the verification data and the prestored data; and a fourth outcome representing a match between the verification data and the prestored data, and further representing the output of an indicator 1860 since the match.
- the predefined set of outcomes for the comparison for such produces a result preferably out of a predefined number of possible outcomes.
- Each outcome represents a possible percentage of match—or degree of difference—between the verification data and prestored data that is allowed, together with a verification status representing the lack of input for verification data since a resetting of the device 1840 .
- the predefined outcomes comprising the percentage match of the verification data with the prestored data may comprise the set of percentages ranging from 0% to 100% in increments of 1%.
- each one of the outcomes represents a percentage match also further represents whether an indicator 1860 has been output from the device 1840 since the last receipt of input representing verification data.
- the identification marker 1872 is stored in memory 1874 and comprises a value representing one of the set of predefined verification statuses of the device 1840 .
- the set of predefined verification statuses preferably comprises all of the possible combinations of outcomes from the respective comparisons for the first and second verification data 1851 , 1853 .
- the correspondence of the possible values for the identification marker 1872 with the predefined verification statuses of the device 1840 should be previously known by the recipient.
- none of the verification statuses actually reveal any of the verification data 1851 , 1853 or the prestored data 1842 , 1844 ; thus, no “shared secret” is required between the sender 1820 and the recipient, and no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient.
- the recipient can infer from the verification status both the correct knowledge of the Secret and the presence of the sender.
- FIG. 18 b A variation based on the ninth preferred embodiment 1800 of FIG. 18 a is shown in FIG. 18 b , and includes an I/O support element 1862 from which input representing the first and second verification data 1851 , 1853 and input representing the message data 1822 is received by the device 1840 .
- the I/O support element 1862 includes a user interface 1858 from which input from the sender 1820 is received and an I/O interface 1859 that communicates the input representing the first and second verification data 1851 , 1853 and input representing the message data 1822 to the device 1840 .
- the message data 1822 is shown coming from the I/O support element 1862 , it is possible for some or all of the message data 1822 to originate with the device 1840 or another apparatus (not shown).
- FIG. 18 c Yet an additional variation thereof is shown in FIG. 18 c , wherein the I/O support element 1862 receives the indicator 1860 and the result 1896 output from the device 1840 .
- the I/O support element 1862 transmits the indicator 1860 and the result 1896 to the electronic apparatus 1830 .
- the indicator 1860 and result 1896 transmitted from the I/O support element 1862 are the same as the indicator 1860 and result 1896 output from the device 1840 .
- the result transmitted from the I/O support element 1862 may be different from the result output from the device 1840 , so long as the recipient is able to determine the bit pattern of the result 1872 based in part on which the message was modified.
- the result transmitted from the I/O support element 1862 may indicate not only the result of the comparison of the first verification data input into the device 1840 , but also a verification status of the I/O support element 1862 when the I/O support element 1862 itself identifies a verification status.
- the indicator 1860 and result 1896 transmitted from the I/O support element 1862 may be packaged or embedded within another communication-including additional information that is digitally signed by the I/O support element 1862 .
- the EC 1810 is shown as being transmitted separate from the indicator 1860 and result 1896 .
- the indicator 1860 and result 1896 equally may be associated with the EC 1810 by being transmitted as part of the EC 1810 .
- the EC 1810 may be output from the device 1840 , an associated I/O support element 1862 (not shown in FIG. 18 a ), or other apparatus.
- FIG. 19 A preferred mode 1900 of operation of the device of FIGS. 18 a , 18 b , and 18 c is illustrated in FIG. 19 and begins with a resetting Step 1904 of the device following a timeout or powering on of the device at 1902 .
- the identification marker is assigned a value corresponding to a verification status representing the receipt of no input of any verification data and further representing the fact that that no indicator has yet been output.
- the device then enters a repeating loop that begins at 1906 and ends at 1914 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time.
- the first step in the loop preferably includes the determination Step 1908 whether any input representing the first verification data (VD 1 ) is received by the device. If the determination in Step 1908 is positive, the current verification status (VS) of the device is identified Step 1916 by comparing the first verification data (VD 1 ) with the first data (PD 1 ) prestored in the memory of the device. The verification status identified then is recorded by assigning Step 1918 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- the next step in the loop preferably includes the determination Step 1910 whether any input representing the first verification data (VD 1 ) is received by the device. If the determination in Step 1910 is positive, the current verification status (VS) of the device is identified Step 1920 by comparing the second verification data (VD 2 ) with the second data (PD 2 ) prestored in the memory of the device. The verification status identified then is recorded by assigning Step 1922 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status.
- Step 1910 If no input representing the second verification data is received in Step 1910 or after the value of the identification marker is recorded in Step 1922 , the next step in the loop preferably includes the determination Step 1912 whether any input representing message data (MD) is received by the device. If the determination in Step 1912 is negative, the loop restarts Step 1906 .
- MD message data
- Step 1912 If the determination in Step 1912 is positive, the device then modifies Step 1924 the message data based on the identification marker. Next, the device originates Step 1926 a digital signature for the modified message data. The digital signature for the modified message data and the value of the result for the first comparison are then output Step 1928 from the device. Following the output of the digital signature for the modified message and value of the result of the first comparison, the determination is made Step 1930 whether the digital signature is the first output since receipt of input representing the first verification data in Step 1908 . If the determination in Step 1930 is positive, then the verification status is newly recorded Step 1934 by assigning a value to the identification marker that represents the verification status identified by the digital signature marker output in Step 1928 , and that further represents the fact that the digital signature has been output.
- the next step in the loop preferably includes the determination Step 1932 whether the digital signature is the first output since receipt of input representing the second verification data in Step 1910 . If the determination in Step 1932 is positive, then the verification status is newly recorded Step 1936 by assigning a value to the identification marker that represents the verification status identified by the digital signature output in Step 1928 , and that further represents the fact that the digital signature has been output. If the determination in Step 1932 is negative or after the value of the identification marker is newly recorded in Step 1936 , the loop then restarts Step 1906 .
- the device comprises hardware, software and/or firmware and, specifically, comprises a computer chip, an integrated circuit, a computer—readable medium having suitable software therein, or a combination thereof.
- the device further may comprise a physical object such as a hardware token or an embedded token, the token containing such a computer chip, integrated circuitry, software, or combination thereof.
- a hardware token it preferably takes the form of a ring or other jewelry; a dongle; an electronic key; a card, such as an IC card, smart card, debit card, credit card, ID badge, security badge, parking card, or transit card; or the like.
- the device preferably takes the form of a cell phone; a telephone; a television; a personal digital assistant (PDA); a watch; a computer; computer hardware; or the like.
- the device preferably includes a device interface comprising a port—including a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port—or some other physical interface for communicating with at least an external electronic apparatus, whether contact or contactless.
- the device also may include a trusted platform module (TPM) comprising hardware and software components providing increased trust in a platform, as set forth and described in the TCPA Documents cited above.
- TPM trusted platform module
- Some of the devices require an I/O support element to receive specific types of verification data but not others. Some of the devices require use of an I/O support element to transmit information regarding verification statuses, digital signatures, and messages to recipients of the ECs. Some of the devices are self-contained, which means that they can generate and transmit messages, digital signatures, and indicators of verification status without the use of external apparatuses; some devices, although self-contained, are capable of interacting with such external apparatuses, such as an I/O support element, if desired.
- An I/O support element may take the form of any number of different apparatuses, depending upon the particular application in which it is used and depending upon the type of device with which it interacts.
- the device preferably includes the following components: a keypad (alphanumeric), interactive display, or other type of user data entry mechanism (collectively referred to herein as “User Interface”) that allows the sender of an EC to compose or modify a message; a User Interface for inputting Secret verification data (it should be noted that the User Interface for generating or modifying a message may, but does not have to, be the same as the User Interface for the entry of the Secret verification data); a display for showing the message and/or Secret to the sender of the EC using the device; a scanner or reader for receiving at least one type of biometric verification data; memory for securely storing the Secret(s), prestored biometric data, and the private key (PrK); a processor or circuitry for performing the various comparisons and for identifying a verification status of the device; a processor or circuitry for generating or originating digital signatures; and a means for outputting information from the device and transmit
- the device also includes memory for storing and exporting the public key (PuK) associated with the particular private key (PrK), and for storing additional user information such as account information, user ID's, and the like.
- PuK public key
- PrK private key
- additional user information such as account information, user ID's, and the like.
- the prestored data of an authorized user of a device may be maintained in suitable records 2000 a , 2000 b , and 2000 c , respectively, within a database of the device.
- PD secret Prestored Data
- FIG. 20 a for simple applications in which the device is adapted to receive and process only a Secret, such as a PIN 2003 , record 2000 a would simply contain the “value” 2005 for the Secret Prestored Data (SPD) 2042 (or referred to generically as PD 2070 ).
- SPD Secret Prestored Data
- record 2000 b would simply contain the “value” 2009 for the applicable Biometric Prestored Data (BPD) 2044 (also referred to generically as PD 2070 ).
- BPD Biometric Prestored Data
- the record 2000 c includes a list of the possible verification data types 2002 representing both a Secret and a biometric characteristic.
- Each type 2002 of verification data (whether Secret or biometric) has associated therewith a corresponding pre-set identifier 2004 and a corresponding unique value 2006 comprising the prestored data 2070 therefor.
- the specific identifiers 2004 associated with particular data types 2002 as shown in FIG.
- 20 c are arbitrary and may be formatted or established to conform with any industry standard or convention now or hereinafter developed (such as, for example, the standards set forth in Biometric Information Management and Security for the Financial Services Industry , Document Number X9.84-2000 WD, American National Standards Institute, 2000, which is incorporated herein by reference and which is available for download at http://webstore.ansi.org). Further, the list of types 2002 of data shown in FIG. 20 c , is only intended to be exemplary and, in practice, record 2000 c may include more, less, or different specific types 2002 of data.
- the types 2002 of data are shown in records 2000 a , 2000 b , and 2000 c for ease of reference and explanation, it is not necessary that the information that appears in the column showing the types 2002 actually be maintained in these records if the relationship between each data type 2002 and its corresponding identifier 2004 is otherwise known. Except for the prestored data (values 2005 , 2008 ) for the PINs, which is conventionally includes a 4-10 digit alphanumeric string, the values 2009 , 2010 associated with each type 2002 of biometric data will generally be a numeric value corresponding to a digital representation of an authorized user's biometric characteristic. For example, the current F.B.I.
- biometric data type 2002 it is preferably that the same standard, scale, or convention be used at both the personalization stage of the device, when such data is input into the device for the purpose of creating the prestored data, as well as each time verification data is later input into the device for the purpose of identifying a verification status. If no data has been prestored for comparison with a particular type 2002 of data, then the corresponding value 2012 for that data type 2002 is set to zero, null, or comparable equivalent value.
- the verification data 2150 comprise Secret Verification Data (SVD) 2151 having a value 2102 input by the sender of an EC when using the device.
- the verification data 2150 comprise Biometric Verification Data (BVD) 2153 having a value 2104 input in response to a scan of a biometric characteristic provided by the sender when using the device.
- VBD Biometric Verification Data
- the verification data 2150 comprise both an identifier 2106 and a corresponding value 2108 .
- the identifier 2106 indicates the type of verification data being input into the device, and, hence, indicates the prestored data the device will need to reference for comparison purposes.
- identifiers it should be understood that instead of using identifiers, it is possible to use software or device commands or instructions in combination with the input of verification data 2150 to notify the device of the particular type of the verification data 2150 being input.
- FIGS. 22, 23 a , 23 b , and 24 several exemplary processes by which a device compares the verification data with prestored data and thereby identifies the verification status are set forth in greater detail.
- the device first determines if input representing verification data (e.g. as shown in Step 308 in FIG. 3) has in fact been received and, if so, determines (Step 2202 ) whether such verification data is for a Secret. If verification data for the Secret is not received, then the device maintains Step 2204 the current verification status (the start-up default value of which is “No PIN entered”).
- Step 2206 the corresponding prestored data (SPD), e.g., value 2005 from record 2000 a in FIG. 20 a .
- the device compares Step 2208 the input value with the prestored data value. If the result (Rs) of the comparison is that the values are equal, then the device identifies Step 2210 the verification status as “PIN match.” If the result (Rs) of the comparison is that the values are not equal, then the device identifies Step 2212 the verification status as “PIN no match.” Furthermore, although FIG.
- FIG. 22 shows the verification statuses in a descriptive format (e.g., “No PIN entered;” “PIN match;” and “PIN no match”), it should be understood that the device, preferably, sets an identification marker (IM) to an arbitrary value that directly maps to a respective verification status which, in this simple example, is also equal to the result of the comparison (Rs).
- IM identification marker
- Rs result of the comparison
- a first identification marker comprising a Secret verification result (Rs 1 )) 2502 is in cardinal number format.
- a second identification marker comprising a Secret verification result (Rs 2 ) 2504 is in binary format.
- a third identification marker comprising a Secret verification result (Rs 3 ) 2506 that is shown is merely a different character string representation of the verification statuses listed in the first column of FIG. 25 a . Referring back to FIG. 22, the resulting identification marker values shown in Steps 2210 and 2212 use the second convention described above.
- Step 2302 that biometric verification data has, in fact, been received. If no biometric verification data has been received, then the device maintains Step 2304 the current verification status (the start-up default value of which is “No BIO input”). If the device has received biometric verification data, then the device retrieves Step 2306 the corresponding prestored data (BVD) (e.g. value 2009 from record 2000 b in FIG. 20 b ).
- Step 2306 the corresponding prestored data (BVD) (e.g. value 2009 from record 2000 b in FIG. 20 b ).
- the device identifies Step 2308 a a verification status by dividing the biometric verification data by the prestored data to obtain a percentage match between the two values and assigning the result (Rb) to the identification marker.
- the device may alternatively obtain a percentage difference between the two values by calculating Step 2308 b the absolute value of the difference between the two values and dividing that number by the prestored data, and then assigning the result (Rb) to the identification marker.
- Rb result
- FIG. 26 Several examples of equivalent biometric identification marker values are illustrated in FIG. 26; however, it should be obvious to one skilled in the art that many different types, conventions, or formats for identification marker values showing degree or percentage of match or difference between the biometric verification data and the prestored data (e.g., such as those set forth in FIG. 26) may be chosen within the scope of the present invention.
- a first identification marker comprising a biometric verification result (Rb 1 ) 2602 is a percentage value (to 2 digits) corresponding to the degree of match or difference between the two values (with the calculated number substituted for the “##”).
- a second identification marker comprising a biometric verification result (Rb 2 ) 2604 is a decimal value (to 2 digits) corresponding to the degree of match or difference between the two values.
- a third identification marker comprising biometric verification result (Rb 3 ) 2606 is a character string associated with the corresponding verification status in the first column of the figure.
- the device outputs an indicator of the verification status based on biometric verification data in the form of a degree (or percentage) of match or degree (or percentage) of difference between the biometric verification data and the prestored data.
- the electronic apparatus or recipient
- the electronic apparatus is allowed to determine, based on its own logic or business rules, whether the degree of match obtained and provided by the device meets a required security threshold for a particular business purpose or application. This enables the device to be used easily with different recipients, each with its own threshold requirements for biometric verification data.
- the device itself could be pre-programmed or pre-hardwired to determine within the device whether the biometric verification data qualifies as a “match” or “no match” with the prestored data relative to an arbitrarily determined threshold-in which case, its identification marker would be similar merely to that for a comparison of verification data for a Secret.
- Step 2402 for other applications in which the device is adapted to receive and process Secret and biometric verification data, the device first initiates Step 2402 a loop for the purpose of processing each input for those applications in which more than one type of verification data is received.
- the device determines Step 2404 whether verification data has been received. If verification data has not been received, then the device maintains Step 2406 the current verification status (which at start-up is “No PIN entered; No BIO entered”). If verification data has been received, then the device retrieves Step 2410 the prestored data ( 2006 from FIG. 2000 c ) corresponding with the identifier ( 2106 from FIG. 21 c ) for such verification data.
- another embodiment allows a device or computer command sent with the verification data to indicate the type of verification data being input without the use of an identifier 2106 (as shown in FIG. 21 c ).
- the device determines Step 2412 , based on the identifier (or command input), whether the verification data represents a Secret or a biometric characteristic.
- the device compares Step 2414 the verification data with the corresponding prestored data for such Secret. If the values are equal, then the device identifies Step 2416 the result of the comparison as a “match” and, in this example, sets Rs equal to a value of “01” (using the binary convention from FIG. 25 a ). The loop then restarts Step 2408 . If the values are not equal, then the device identifies Step 2416 the results of the comparison as a “no match” and, in this example, sets Rs equal to a value of “10” (again using the binary convention from FIG. 25 a ). The loop then restarts at Step 2408 .
- the device determines that the verification data represents a biometric characteristic, then the device identifies Step 2420 the verification status by comparing the verification data with the corresponding prestored data and calculating a percentage match therebetween.
- the device sets Rb for the particular type of biometric verification data (designated by ###) equal to the value of the percentage match.
- the loop then restarts at Step 2408 .
- the value of the identification marker (IM) corresponding with the verification status includes the value for Rs as well as the values for each Rb for each biometric verification type.
- This identification marker indicates a verification status in which an incorrect PIN was received and a right handprint having a 90% degree of match was received.
- a suitable verification status is represented by an identification marker including the following value:
- This identification marker indicates a verification status in which a right thumbprint had a 95% match, a left thumbprint had a 93% match, and a right iris scan produced an 87% match.
- the device after performing the above steps, identifies the verification status as an identification marker containing every possible identifier 2004 (or some subset thereof from FIG. 20 c ) followed by its corresponding Rs or Rb value.
- the identification marker nevertheless includes all identifiers 2004 and their corresponding Rs and Rb values.
- the corresponding value for Rs or Rb is its default value preferably comprising zero or null, or a suitable equivalent.
- a suitable verification status is represented as an identification marker of:
- the identification marker in this example indicates a verification status in which a correct PIN was input, a right middle fingerprint had a 25% match, a right pinky fingerprint had a 96% match, and a DNA scan had a 95% match.
- this example uses the conventions for Rb discussed above with regard to column 2604 of FIG. 26.
- the identification marker for the above-described verification status could be presented, alternatively, as follows:
- Each identification marker above identifies a verification status in which a correct PIN was input, a right middle fingerprint had a 25% match, a right pinky fingerprint had a 96% match, and a DNA scan had a 95% match.
- the device prefferably provides additional information to the recipient of an EC as to whether the verification status of the device is in a “persistent” state or whether the verification status applies specifically to the EC with which the indicator of verification status is associated.
- Such information can be used by the recipient to determine whether the sender of the EC input the correct Secret for a previous message or whether the correct Secret was input as specific approval or authorization of the transaction or request contained within the EC that is digitally signed.
- the same advantages apply in the case of a biometric characteristic.
- This fourth state may be shown using any of the formats previously discussed, including a cardinal number format shown in column 2508 of FIG. 25 b ; a binary format shown in column 2510 of FIG. 25 b ; and a character string format shown in column 2512 of FIG. 25 b .
- the fourth state is identified whenever an indicator is output or a digital signature is generated with the identification marker equaling “01” by setting, thereafter, the identification marker equal to “11”.
- the device maintains a counter or “digital signature flag” (referred to hereinafter generically as “DSFlag”).
- DSFlag is initially set to zero and counts to one or more each time an indicator of verification status is output from or a digital signature is generated by the device. Thereafter, the DSFlag remains at one (or continues counting by one) for each indicator output or digital signature generated until verification data again is received by the device, after which the DSFlag is reset to zero.
- the value of the DSFlag is incorporated into the value of the identification marker as an additional bit of information.
- possible values of an identification marker thus include the following, wherein “/” separates the binary value of Rs and the corresponding DSFlag value for purposes of illustration: 00/0 (no PIN input; no IVS or DS output); 00/1 (no PIN input; IVS or DS output); 01/0 (PIN match; no IVS or DS output since PIN match); 01/1 (PIN match; IVS or DS output since PIN match); 10/0 (PIN no match; no IVS or DS output); and 10/1 (PIN no match; IVS or DS output).
- the device preferably includes a DSFlag as part of the identification marker in similar manner to the methodology just described.
- the identification marker includes the degree of match as well as the value of the DSFlag.
- a suitable value of the identification marker is “90/0” (with the “/” merely to indicate the separation of the two values), with the value of “90” for Rb indicating the degree of match and the value of “0” for the DSFlag indicating that no digital signature had been generated since last receipt of verification data.
- the identification marker would be “90/1” (or in the case of a counter, “90/x” where “x” is any number greater than 0).
- each comparison result (R) for each type of verification data it is preferable for each comparison result (R) for each type of verification data to have its own DSFlag. In this situation, every time a digital signature is originated, all of the DSFlags are set to one (or otherwise incremented as described above); however, each time additional verification data is received by the device, the DSFlag for that particular type of verification data is set to zero.
- the particular identifier it is preferred to include the particular identifier, as discussed previously. Using the example from the previous section, a suitable identification marker appears as:
- This identification marker indicates a verification status in which a correct Secret was input, a right middle fingerprint had a 25% match, a right pinky fingerprint had a 96% match, a DNA scan had a 95% match, and the right middle fingerprint was entered since the last digital signature was generated by the device.
- FIG. 27 a table illustrates a hypothetical series of actions (primarily inputs of different types of verification data) into a device of the present invention and the resulting change (if any) to the value of the identification marker.
- the identification marker (IM) of the device comprises the Rs value, the Rb(002) value, DSFlag(002) value, Rb(016) value, and DSFlag(016) value.
- the identification marker uses the two digit binary convention for the value of Rs (i.e., from column 2510 from FIG. 25 b ), a two-digit percentage match convention for the values of Rb(002) and Rb(016) (from column 2602 from FIG. 26), and binary values for the DSFlag associated with each biometric verification data type.
- the DSFlag values are either “0”—indicating no generation of a digital signature or output of an indicator of the verification status since the particular type of biometric verification data was received, or “1”—indicating generation of a digital signature or output of an indicator since the particular type of biometric verification data was received.
- a series of thirteen actions is illustrated in sequence in the first column of the table of FIG. 27.
- the impact of each of these actions upon the device and, more specifically, upon the identification marker of the device, which identifies the current verification status of the device, is shown horizontally across the remaining columns of the table.
- the device is activated, turned on, or otherwise reset. This action causes each of the values that make up the identification marker to reset to their default values of zero, as shown.
- a second generation of a digital signature, output of the value of the identification marker, or other output of the verification status of the device has no effect upon the value of identification marker; however, it should be noted that the value of Rs and of the DSFlags will be different from the values that were output during the fourth action.
- a correct PIN input as the sixth action sets the value of Rs to “01,” but noticeably has no impact on the DSFlags for the right thumbprint and right retina.
- a right thumbprint is provided to the device and results in an 85% match with the to prestored right thumbprint value. This causes the value of Rb( 002 ) to be set to “85” and the value of DSFlag(002) to be set to “0.”
- a right retina scan result is provided to the device and results in a 90% match with the prestored value. This causes the value of Rb(016) to be set to “ 90 ” and also the value of DSFlag(016) to be set to “0.”
- the ninth action is a third generation of a digital signature, output of the identification marker, or other output of the verification status of the device including the identification marker that was in effect after the eighth action, which causes Rs to switch to “11” and both of the DSFlags to toggle back to “1.”
- a second right thumbprint is provided to the device, which results in an 88% match, which changes the value of Rb(002) to “88” and the value of DSFlag( 002 ) to “ 0 .”
- An incorrect PIN entry at this point, in the eleventh action merely changes the value of Rs to “10.”
- the fourth generation of a digital signature, output of the identification marker, or other output of the verification status of the device causes DSFlag(002) to toggle back to “1” but has not effect upon the Rs value or upon the DSFlag(016) value, which is already set to “1.”
- a second right retina provided to the device,
- FIG. 28 a preferred computer chip 50 that may be used in conjunction with an IC card, PDA, cell phone, personal computer, or other device in accordance with the present invention is illustrated.
- the computer chip 50 receives power 52 , a clock input 54 , and a reset or master clear input 56 from an external source 90 .
- the computer chip 50 is also connected to ground 58 and exchanges input and output data 60 through external source 90 .
- the external source 90 may be part of the IC card, PDA, cell phone, personal computer or other device in which the computer chip 50 is installed or it may be part of an I/O support element (not shown) with which the IC card, PDA, cell phone, personal computer, or other device is in communication, as the case may be.
- the computer chip 50 includes an I/O router 62 , a central controller 64 , a memory location 66 for securely storing a private key of a public-private key pair, a memory location 68 for storing the corresponding public key of the public/private key pair, a dedicated public/private key generator circuit 70 , a private key destruction circuit 72 , a memory location 65 for storing a default prestored message, a digital signature circuit 71 (which includes a hash function circuit 73 , a random number generator 74 , and an encryption circuit 75 ), a memory location 76 for prestoring data (Secret and/or biometric data), a selection multiplexer 78 for retrieving selected prestored data from memory location 76 , a memory location 80 for storing various account and other user information, a selection multiplexer 82 for retrieving selected information from memory location 80 , a memory location 83 for storing the current verification status (preferably in the form of an identification marker (IM)) of the computer chip 50
- IM identification marker
- the computer chip 50 is designed with the following capabilities: the ability to store data securely and permanently (especially the private key); the ability to create a public-private key pair on the chip on a one-time only basis using a random number produced within the chip from the random number generator 74 ; and the ability to originate digital signatures, when requested, using a random number produced within the chip from the random number generator 74 in accordance with FIPS PUB 186-2.
- the computer chip 50 further preferably is resistant to tampering and is immune to Differential Power Attacks and other physical analysis.
- the prestored data for the Secret preferably also is protected from exhaustive search attacks.
- One method of “protecting” the private key is by designing the computer chip 50 with the destruct circuit 72 , which destroys the private key when triggered by any tampering or attempted theft of the private key by electronic, physical, and other known means. Under such circumstances, the destruct circuit 72 renders the computer chip 50 useless by preventing the computer chip 50 from being able to generate further digital signatures and by destroying the information retained in memory location 66 .
- the computer chip 50 also includes non-modifiable operating software either loaded into the chip during manufacture or permanently etched into read-only memory (ROM) on the chip 50 .
- ROM read-only memory
- Such software enables the computer chip 50 to respond to and act upon a specific set of commands.
- Such commands enable, for example, the computer chip 50 to be personalized.
- Personalization includes the input and prestoring of data for a Secret, a biometric characteristic, user name, and account number(s).
- the prestored data for the Secret is capable of being changed, upon successful input of the current Secret verification data.
- the biometric prestored data preferably is permanent once loaded into memory.
- the software further includes a command that causes the key generation circuit 70 to create a unique public-private key pair directly within the computer chip 50 on a one-time only basis.
- the private key is stored securely in memory location 66 .
- the public key is stored in memory location 68 .
- the software includes a command that enables the public key to be exported from the computer chip 50 .
- the command to export the public key may be executable multiple times or one time only, depending upon whether strict control over access to the public key is desired.
- the software also includes a command that notifies the computer chip 50 that verification data is being input.
- separate commands are used to indicate whether the verification data being input is for a Secret or a biometric characteristic and, if for a biometric characteristic, the biometric type.
- the computer chip 50 also automatically identifies a verification status whenever it receives verification data.
- the software further includes a command that notifies the computer chip 50 that message data is being input.
- a command that notifies the computer chip 50 that message data is being input.
- all of the account and other user information is extracted from the computer chip 50 and the user is prompted through a display to select the appropriate account or user information to be included as part of the message to be digitally signed using the computer chip 50 .
- a message data command then is sent to the computer chip 50 for the origination of a digital signature, with the selected account or user information included in the message data.
- the I/O support element sends a command to the computer chip 50 for the extraction of all account and user information.
- the user selects the appropriate account or user information from a display provided by the I/O support element to be included as part of the message to be digitally signed using the computer chip 50 . Thereafter a message data command is sent to the computer chip 50 for the origination of a digital signature, with the selected account or user information included in the message data.
- the message data command provided to the computer chip 50 includes one or more “null fields” or other appropriate “tags” which identify a particular account field or user information field, but in which no value is supplied.
- the computer chip 50 searches content addressable memory to identify a corresponding field maintained in memory. Upon location of the corresponding field, the computer chip 50 supplies the value of such field in the message data in substitution for the null value of the tag.
- each data cell containing account or user information in memory location 80 has its own tag or content address.
- tags or content addresses are standardized so that account or user information can be correctly stored in memory location 80 and easily retrieved using a tag when later needed.
- Such tags may include XML tags.
- a message data command could be sent to the computer chip 50 in which the message data contains a null field or tag requesting that ⁇ user name> be inserted into a particular location within the text of the message data.
- the computer chip 50 automatically completes the message data by inserting, in this case, the “user name” stored in the third cell of memory location 80 of the chip 50 .
- a tag could be used to extract and insert any of the various field values (e.g., credit card account number; banking account number; user name; employer account number; web site account number, etc.) maintained in memory location 80 of the computer chip 50 .
- message data is “completed” with all requested account and user information using one of the above techniques, such message data is then ready for: modification by the current verification status of the computer chip (using the value of IM); calculation of the hash value for the modified message data; encryption of the hash value to generate a digital signature; and output of the digital signature.
- the computer chip 50 generates a digital signature in the same manner using a prestored message in memory location 65 —rather than imported message data—in response to a suitable command to generate a digital signature.
- a computer chip including components and functionality described above, and which is used in providing a verification status in accordance with the present invention, is itself novel and nonobvious and, accordingly, such a computer chip indeed comprises an aspect of the present invention.
- FIGS. 29 - 33 illustrate how a single IC card 95 , configured to function in accordance with the present invention and containing a suitable computer chip 50 (such as described above with reference to FIG. 28), may be used in many different applications and settings by a suspect user 46 of the IC card 95 .
- the structure of the IC card 95 is conventional in that it has the computer chip 50 embedded therein and surface contacts for enabling communication between an IC card reader and the computer chip 50 in the IC card 95 .
- the surface contacts are ISO/IEC 7816 compliant. It is also possible to have an ISO/IEC 14443 compliant proximity card or a combination card capable of both 7816 and 14443 operations.
- the computer chip 50 (as shown in FIG. 28) already contains a unique public/private key pair created in the manner previously described. It is further assumed that a PIN (the Secret in these examples) and digitized versions of the authorized user's right thumbprint, right retina, and voice print have been input and prestored in memory location 76 (cells 001, 002, 016, and 020 respectively) of the chip 50 (again, as shown in FIG. 28).
- a PIN the Secret in these examples
- memory location 76 cells 001, 002, 016, and 020 respectively
- the authorized user's name, credit card account number, checking account number, relevant employee ID number for building and computer access, and website broker account number have been suitably prestored in memory location 80 for access as needed using an appropriate tag contained within message data provided to the IC card 95 from an external source, as discussed above.
- the public key stored on the computer chip 50 has been provided to the authorized user's employer, credit card account company, bank, and broker, each of which has, in turn, associated in its own database the public key with the authorized user's account.
- the computer chip 50 outputs the value for the identification marker (IM), which is a data string containing the value of Rs using the convention as set forth in column 2504 of FIG.
- IM identification marker
- the value for the identification marker further includes the type identifier (0xx) and the value of Rb (in the format of a two-digit percentage match (xx) as set forth in column 2602 of FIG. 26) for every biometric verification data type. Furthermore, the identification marker includes a respective DSFlag associated with the Rs value and with each Rb value.
- a first example illustrates the IC card 95 being used by the suspect user 46 .
- the suspect user 46 presents the IC card 95 to gain access to a parking area 2902 .
- the parking area 2902 is secured by a parking gate 2904 , which has an arm 2906 and which is controlled by a parking gate controller 2908 .
- the parking gate controller 2908 is in communication with an IC card reader 2910 .
- the controller 2908 and the IC card reader 2910 could, in fact, be physically installed within the housing of the parking gate 2904 .
- the suspect user 46 inserts the IC card 95 into the reader 2910 (or positions the card near the reader in case of 14443 operations).
- the IC card reader 2910 does not have an associated keypad or biometric scanner; thus, there is no means by which the suspect user 46 can input any verification data.
- access to the parking area is not dependent upon any particular verification status of the IC card 95 .
- the parking gate controller 2908 opens the parking gate 2906 merely upon proper presentation of the IC card 95 , which is pre-registered with the parking gate controller 2908 .
- pre-registration involves the authorized user of the card providing his name (“user name”) as retained in the memory 80 (as shown in FIG. 28) of the computer chip 50 to the parking gate controller 2908 or, conversely, having the operator of the parking gate 2904 (e.g., the authorized user's employer or agent) “approve” the IC card 95 for use with the parking gate system by inputting an employee account number into memory location 80 (as shown in FIG. 28) of the computer chip 50 .
- the authorized user of the card 95 also provides his public key (retained on the chip 50 ) to the parking gate controller 2908 , which associates the user's name or employee account number (hereinafter generally referred to as “user information”) therewith.
- the card reader 2910 When the IC card 95 is inserted into the card reader 2910 (or brought into proximity to the card reader 2910 ), the card reader 2910 is initialized. Initialization of the card reader 2910 is conventional and is accomplished either by the card reader 2910 physically detecting an IC card 95 , or by the IC card 95 outputting a “reset” message to the card reader 2910 as part of its start-up protocol when it first receives power from the card reader 2910 . Once the IC card 95 receives power, the identification marker and all DSFlags for the PIN and each applicable biometric type are reset. Alternatively, all such values may be reset when power is removed from the card 95 .
- the card reader 2910 sends a message input command to the IC card 95 .
- the message input command includes a tag requesting user information, such as “user name” or “employee account number” from the appropriate data field in memory location 80 (as shown in FIG. 28). In this example, there is no additional message data other than the tag.
- the computer chip 50 (as shown in FIG. 28) on the IC card 95 retrieves the requested user information from memory location 80 (as shown in FIG. 28), with such user information becoming part of the message data; retrieves the current value of the identification marker; modifies the message data with the value of the identification marker by pre-pending the value to the message data; calculates a hash value of the modified message data; encrypts the hash value to generate a digital signature; and exports the digital signature, requested user information, and value of the identification marker to the card reader 2910 , which forwards such data on to the controller 2908 for processing.
- the controller 2908 first compares the requested user information (name or employee account number) received from the IC card 95 with a list of authorized names or authorized employee account numbers maintained in its database. For low security having no regard for authentication, the controller 2908 opens the parking gate 2906 if the user information received from the IC card 95 matches one of the authorized names or authorized employee account numbers in its database. For higher security to guard against a counterfeit IC card, the controller 2908 decrypts the digital signature received from the IC card 95 using the public key associated with the matching user information.
- the controller 2908 determines that the IC card 95 from which the digital signature is received contains the unique private key associated with the user who pre-registered with the operator of the parking gate 2904 , and lifts the parking gate arm 2906 —the decision in this case to raise the gate being based on Factor A Entity Authentication.
- the same IC card 95 may be used by the suspect user 46 first to gain access into secure building 3002 and then into secure room 3102 , which is located within the secure building 3002 .
- one IC card reader 3004 is mounted next to the secure entrance 3010 into the building 3002 .
- This IC card reader 3004 includes an alphanumeric keypad 3006 and a display screen 3008 .
- the IC card reader 3004 is in electronic communication with a building security controller 3014 , which controls the locking mechanism 3012 of the entrance 3010 .
- another IC card reader 3104 is mounted on the wall next to secure door 3110 .
- This IC card reader 3104 includes a retina scanner 3106 and a display 3108 . Likewise, this IC card reader 3104 is in electronic communication with the building security controller 3114 , which controls the locking mechanism 3112 of the door 3110 . If the parking area 2902 (from FIG. 29) is part of the same facility as secure building 3002 , it is possible that parking gate controller 2908 and building security controllers 3014 , 3114 are the same apparatus, part of the same computer system, or share the same database of information regarding the authorized user and public key for IC card 95 .
- the IC card 95 is inserted into the IC card reader 3004 (or brought into proximity to the card reader 3004 ).
- the reader 3004 is initialized in much the same way as the card reader 2910 in FIG. 29.
- the identification marker and all DSFlags are reset when power is first supplied to the IC card 95 .
- the card reader 3004 uses the display 3008 , prompts the suspect user 46 to input a PIN. Once the PIN is entered using the keypad 3006 , the card reader 3004 transmits the same, not to the building security controller 3014 , but directly to the IC card 95 .
- the card reader 3004 sends a message input command to the IC card 95 .
- the message input command includes a “tag” requesting user information (e.g. “user name” or “employee account number”) from the appropriate data field in memory location 80 (as shown in FIG. 28). Again, it is assumed that the message data comprises the tag only and no additional information.
- the computer chip 50 on the IC card 95 retrieves the requested user information from memory location 80 (as shown in FIG. 28); retrieves the current value of the identification marker; modifies the user information (i.e., message data) with the value of the identification marker by pre-pending the value to the user information; calculates a hash value of the modified user information to generate a digital signature; encrypts the hash value; and exports the digital signature, requested user information, and value of the identification marker to the card reader 3004 .
- the computer chip 50 increments the value of all of the DSFlags to “1”. Equivalently, the computer chip 50 only increments the value of the DSFlags to “1” for the specific verification data types for which any verification data input has been received since powering on of the card 95 .
- the digital signature, value of the identification marker, and user information received by the card reader 3004 are communicated to the building security controller 3014 .
- the building security controller 3014 first confirms that the user information matches either an authorized name or an authorized employee account number for access to the building 3002 . If so, the building security controller 3014 then decrypts the digital signature using the public key associated with the matching authorized user information. If the decrypted hash value from the digital signature matches a hash value calculated based on the user information received from the IC card 95 , as modified by the value of the identification marker received from the IC card 95 , then the building security controller 3014 determines that the IC card 95 from which the digital signature is received contains the unique private key.
- the IC card 95 is inserted into the IC card reader 3104 (or brought into proximity to the card reader 3104 ).
- the reader 3104 is initialized in much the same way as the card reader 3004 , with the identification marker and all DSFlags being reset when power is first supplied to the IC card 95 .
- the card reader 3104 using the display 3108 , prompts the suspect user 46 to place his right eye before the scanner 3106 .
- the retina scanner 3106 scans the right eye of the suspect user 46 and obtains a digitized version thereof.
- the card reader 3104 transmits the biometric verification data (which includes an identifier and a value of the digitized scan of the right retina), not to the building security controller 3114 , but to the IC card 95 for comparison.
- the controller 64 determines the type of biometric verification data received (based on the identifier), retrieves the corresponding prestored biometric data for the authorized user's right retina from memory location 76 (cell 016), and compares the two values (Factor C Entity Authentication). A degree of match determination/calculation is made by the controller 64 , which sets Rb(016) to a two-digit number corresponding with the percentage match (again, as shown in FIG. 28).
- the card reader 3104 sends a message input command to the IC card 95 .
- the message input command includes a tag requesting user information from the appropriate data field in memory location 80 . Again, it is assumed that the message data comprises the tag only and no additional information.
- the computer chip 50 on the IC card 95 retrieves the requested user information from memory location 80 ; retrieves the current value of the identification marker (including therein the value of Rb(016) and the value of the DSFlag(016), which was reset to zero when the card was inserted into the card reader 3104 ); modifies the user information with the value of the identification marker by pre-pending the value to the user information, calculates a hash value of the modified user information; encrypts the hash value to generate a digital signature; and exports the digital signature, requested user information, and value of the identification marker to the card reader 3104 .
- the computer chip 50 then increments the value of all of the DSFlags to “1.”
- the digital signature, user information, and value of the identification marker received from the IC card 95 are then communicated by the card reader 3104 to the building security controller 3114 .
- the building security controller 3114 first confirms that the user information received from the IC card 95 matches an authorized user name or employee account number for access to the room 3102 . If so, the building security controller 3114 then decrypts the digital signature using the public key associated with the matching user information. If the decrypted hash value from the digital signature matches a hash value calculated based on the user information received from the IC card 95 , as modified by the value of the identification marker received from the IC card 95 , then the building security controller 3114 determines that the IC card 95 from which the digital signature is received contains the unique private key.
- the building security controller 3114 checks the verification status indicated by the value of the identification marker to determine whether the suspect user 46 is in fact the authorized user of the IC card 95 . In this regard, if the degree of match between the value for the scanned retina and the prestored value for the retina of the authorized user meets a threshold requirement (e.g. 90% match or better) set by the building security controller 3114 , then the building security controller 3114 infers that the suspect user 46 is the authorized user and sends a signal to the locking mechanism 3112 to unlock and/or open the door 3110 .
- a threshold requirement e.g. 90% match or better
- the building security controller 3114 may include business logic that denies access to the room 3102 if there is a “perfect” or 100% match between the scanned retina and the prestored retina, since such a comparison likely indicates a fraudulently input verification data. If the degree of match received from the card 95 does not exceed the required threshold set by the building security controller 3114 for this room 3102 , an additional retina scan may be requested and the above procedure repeated.
- the verification status output by the card 95 will include the DSFlag for the right retina set to a value of “1,” which signals the building security controller 3114 that a new retina scan was not input or correctly received by the IC card 95 .
- the DSFlag for the right retina (DSFlag(016)) is reset to zero.
- the building security controller 3114 will be alert to the potential of a fraudulent biometric verification data received by the IC card 95 when a new degree of match determination is exactly identical to a previous determination for the same biometric characteristic from the same IC card 95 .
- the building security controller 3114 may nevertheless request a follow-up retina scan from the suspect user 46 simply for the purpose of determining if the biometric input was fraudulent (i.e., is the follow-up degree of match identical to the initial degree of match?).
- the building security controller 3114 may also include business logic that denies access to the room 3102 if there is a “perfect” or 100% match between the scanned retina and the prestored retina, since such a comparison also likely indicates a fraudulently input verification data. Referring to FIG. 32 a , the suspect user 46 now sits at his desk to access his personal computer 3202 .
- the computer 3202 is conventional in that it includes a keyboard 3204 , a monitor 3206 , and a mouse 3208 .
- the computer 3202 also includes a card reader 3210 , which exchanges data with the computer 3202 through a suitable port (e.g., serial, parallel, USB, etc.) of the computer 3202 .
- the card reader 3210 is similar to those discussed above and is capable of exchanging information with an IC card 95 when inserted therein (or brought within proximity thereof.
- the computer 3202 also includes a microphone 3212 for receipt of audio input, such as the voice of the suspect user 46 .
- the present example assumes that the computer 3202 will power on and “boot up” to a security screen (using suitable software installed on the computer 3202 ), but that no substantive access, such as to programs or databases maintained on, or to the operating system of, the computer 3202 is enabled until the suspect user 46 is authenticated.
- the building security controller 3114 may also request additional PIN and/or bio input if there suspicion of fraudulent input.
- the computer 3202 After powering on, the computer 3202 prompts, on a security screen displayed on the monitor 3206 , the suspect user 46 to insert the IC card 95 into card reader 3210 , to enter a PIN into a suitable data entry window also displayed on the screen, and to state (audibly) his name—first name, middle initial, and last name—for the purpose of obtaining a voiceprint.
- the reader 3210 When the IC card 95 is inserted into the reader 3210 , the reader 3210 is initialized (as described previously) and the power supplied to the card 95 causes the identification marker and all of the DSFlags on the computer chip 50 to be reset.
- the computer 3202 transmits both the PIN and a digitized version of the voiceprint, via the card reader 3210 , to the IC card 95 .
- the card reader 3210 transmits the value of the PIN and digitized voiceprint along with an identifier (e.g., 001 for the PIN and 020 for the voiceprint) for each to identify to the card 95 the type and order of the verification data input.
- an identifier e.g., 001 for the PIN and 020 for the voiceprint
- the controller 64 on the computer chip 50 Upon receipt of the PIN and biometric verification data by the IC card 95 , the controller 64 on the computer chip 50 (referring back to FIG. 28) first determines the type of verification data received based on the identifiers and then retrieves the appropriate prestored data from memory location 76 . In this example, the controller 64 first retrieves the prestored data for the PIN from memory location data cell 001 in memory location 76 , and then compares the value with the value of the PIN verification data received from the card reader 3210 (Factor B Entity Authentication). A match/no-match determination is made by the controller 64 , which sets the value of the Rs as either “01” (match) or “10” (no match).
- the controller 64 retrieves the prestored data for the authorized user's voiceprint from data cell 020 in memory location 76 , and then compares this value with the digitized voiceprint received from the card reader 3210 (Factor C Entity Authentication). A degree of match determination/calculation is made by the controller 64 , which sets the value of Rb(020) to a two-digit number corresponding to the percentage match.
- the computer 3202 After a suitable but brief delay, the computer 3202 then sends a message input command to the IC card 95 via the card reader 3210 .
- the message input command includes a tag requesting user information from the appropriate data field in memory location 80 (again, as shown in FIG. 28). Again, it is assumed that the message data comprises the tag only and no additional information.
- the computer chip 50 on the IC card 95 retrieves the requested authorized user information (as the message data) from memory location 80 ; retrieves the current value of the identification marker (which includes the value of Rs and the value of DSFlag(001), which was reset to zero when the card was inserted into the card reader 3210 , and which also includes the value of Rb(020) and the value of the DSFlag(020), which was also reset to zero), modifies the message data with the identification marker by pre-pending the value to the message data, calculates a hash value of the modified message data, encrypts the hash value to generate a digital signature, and exports the digital signature, requested user information, and value of the identification marker to the card reader 3210 .
- the computer chip 50 increments the value of all of the DSFlags on the computer chip 50 to “1” (at a minimum, the DSFlags for the PIN and for the voiceprint, namely DSFlag(001) and DSFlag(020), are incremented to “1”).
- the digital signature, user information, and value of the identification marker received by the card reader 3210 are then communicated to the computer 3202 for processing. If the computer 3202 is a stand-alone computer, processing is performed within the computer 3202 itself. More likely, however, computer 3202 will be networked and in communication with a server (not shown), which will actually determine whether the suspect user 46 will gain access to the computer 3202 .
- the server first confirms that the user information received from the IC card 95 matches an authorized user name or employee account number for access to and use of the specific computer 3202 .
- the server then decrypts the digital signature using the public key associated with the matching user information. If the decrypted hash value from the digital signature matches a hash value calculated based on the user information received from the IC card 95 , as modified by the value of the identification marker received from the IC card 95 , then the server determines that the IC card 95 from which the digital signature is received contains the unique private key. Finally, the server checks the verification status indicated by the value of the identification marker to determine whether the suspect user 46 is in fact the authorized user of the IC card 95 .
- the server In the first step, if the value of Rs is “01” (match), then the server infers that the suspect user 46 is the authorized user.
- the server uses business logic or a rule base to determine if the voiceprint provided by the suspect user 46 is sufficiently similar to the voiceprint of the authorized user stored on the IC card 95 so as to infer again that the suspect user 46 is the authorized user.
- the business logic and rule base of the server may be programmed to accept varying combinations of Rs and Rb values (PIN and voiceprint) to infer that the suspect user 46 is the authorized user. For example, a correct PIN by itself, a correct PIN plus at least a 70% match of voiceprint, an incorrect PIN if the voiceprint exceeds 95%, and an incorrect PIN but two voiceprints exceeding 90% are all different types of verification statuses that may be sufficient for the server to infer that the suspect user 46 is the authorized user and grant access to the computer 3202 .
- the business logic or rule base can vary widely, depending upon the necessary security desired.
- the IC card 95 may also be used by the suspect user 46 in accessing a secure website over an insecure network, such as the Internet 3222 .
- an insecure network such as the Internet 3222 .
- the suspect user 46 is accessing the secure website 3224 of his broker 3220 , with whom he already has an established account.
- the brokerage company 3220 that operates the website 3224 already has the authorized user's public key from the IC card 95 stored in its account database 3225 and associated with the authorized user's account.
- the suspect user 46 is accessing the website 3224 using computer 3202 from FIG. 32 a and that the card 95 has not been removed from the card reader 3210 since it was used to gain access to the computer 3202 ; thus, the DSFlags remain set to “1”.
- the suspect user 46 enters a user ID in a login screen for the website.
- the user ID enables the brokerage company 3220 readily to locate the appropriate account of the user, as is conventional.
- the computer 3202 sends the user ID to the IC card 95 via the card reader 3210 .
- the process by which the website 3224 instructs the computer 3202 to send the user ID to the IC card 95 rather than directly over the Internet to the website 3224 is beyond the scope of this invention; however, it may be readily accomplished in several different manners.
- the website 3224 has a dedicated login page for use only by users having a suitable IC card 95 (or other device of the present invention), in which case, entry of the user ID into such login page automatically instructs the computer 3202 to send the user ID to the IC card 95 for processing.
- the login page for the website 3224 could enable the user to select a conventional login using an ID and password or to login using his IC card 95 .
- the user ID could actually be prestored in a “cookie” in memory on the computer 3202 , as is conventional, which would enable the user merely to click one button on the login page of the website 3224 , which causes the computer 3202 to send the user ID to the IC card 95 .
- the computer chip 50 on the IC card 95 retrieves the current value of the identification marker, modifies the user ID received from the card reader 3210 with the value of the identification marker by pre-pending the value to the user ID, calculates a hash value of the modified user ID, encrypts the hash value to generate a digital signature, and returns the digital signature and the value of the identification marker to the computer 3202 via the card reader 3210 .
- the values of the DSFlags are not incremented since they are already set to a value of “1.”
- the user ID, the digital signature, and value of the identification marker then are communicated in an EC by the computer 3202 over the Internet 3222 to the website 3224 for processing.
- Computer programming associated with the website 3224 first confirms that the suspect user 46 maintains an account with the brokerage company by matching the user ID with an account. If an account with a matching user ID is found, then the computer programming next decrypts the digital signature using the public key associated with the identified account.
- the decrypted hash value from the digital signature matches a hash value calculated based on the user ID received from the IC card 95 , as modified by the value of the identification marker received from the IC card 95 , then it is determined that the IC card 95 from which the digital signature is received contains the unique private key corresponding with the account of the user. Finally, the computer programming associated with the website 3224 checks the verification status indicated by the value of the identification marker to determine whether the suspect user 46 is in fact the authorized user of the IC card 95 .
- the computer programming extracts only the value of the Rs from the value of the identification marker for initial evaluation. If the value of Rs is “00” (no PIN input), then the website 3224 sends a request data back to the computer 3202 requesting input of the user's PIN. If the value of Rs is “10” (incorrect PIN), then the website 3224 sends a request for the suspect user 46 to reenter the PIN. In either case, a suitable screen is displayed on the monitor 3206 of the computer 3202 to enable the suspect user 46 to enter the PIN. It should again be emphasized that such PIN will be transmitted by a keyboard of the computer 3202 to the card 95 but not transmitted over the Internet 3222 .
- the website 3224 infers that the suspect user 46 is in fact the authorized user and grants access to the website 3224 . Thus, for mere access to the website 3224 , it is not necessary that the PIN be entered just prior to the generation of the digital signature for the user ID—previous entry of a correct PIN is satisfactory for access to the website 3224 .
- the website 3224 transmits a detailed confirmation of the requested transaction and specifically requests entry of a PIN to confirm specific approval for the purchase order.
- the computer 3202 provides the same to the IC card 95 .
- the controller 64 Upon receipt of the PIN, the controller 64 first retrieves the prestored data for the PIN from memory location data cell 001 in memory location 76 and compares it with the PIN received from the computer 3202 . A match/no-match determination then is made by the controller 64 , and the value of Rs is set to either “01” representing a match or to “10” representing a failed match, and the DSFlag( 001 ) also is set to “0”.
- the computer 3202 After a suitable but brief delay, the computer 3202 then sends a message input command (which contains the purchase order) to the IC card 95 .
- the computer chip 50 on the IC card 95 retrieves the current value of the identification marker (including therein the value of Rs and DSFlag(001)); modifies the message data received from the computer 3202 with the value of the identification marker by pre-pending the value to the message data; calculates a hash value of the modified message data; encrypts the hash value to generate a digital signature; and exports the digital signature and value of the identification marker to the computer 3202 , which then forwards the same on to the website 3224 .
- the computer chip 50 increments the value of all of the DSFlags to “1.”
- the website 3224 will only approve the requested transaction when the value of the identification marker includes therein a value of Rs of “01” and a value of DSFlag(001) as “0”.
- the communication between the computer 3202 and the website 3224 may be performed using a Secure Socket Layering (SSL) protocol, as is conventional.
- SSL Secure Socket Layering
- Such a protocol is set forth, for example, in U.S. Pat. No. 5,848,161, which is incorporated herein by reference.
- the computer 3202 it is customary for the computer 3202 to generate a random number for use in creating a session key for the SSL communication.
- the IC card 95 is used for the provision of the random number for creation of the session key.
- a digital signature is originated by the IC card 95 and used as the random number itself for the purpose of creating the session key.
- a session key for communication using pretty good privacy (PGP) encryption also may be created based on the digital signature of the IC card 95 .
- a point of sale card reader 3308 includes an alphanumeric keypad 3310 , a display 3314 , and, in this case, a thumbprint reader 3312 .
- the point of sale card reader 3308 is in communication via data connector 3306 with a merchant cash register/terminal 3302 , which has its own display 3304 .
- the point of sale card reader 3308 is also in communication over an insecure network, such as the Internet 3322 , with a banking authority 3320 .
- the banking authority 3320 is either a financial institution that maintains a banking or credit card account on behalf of the authorized user of the IC card 95 or is an authorized approval agent or clearance authority for such a financial institution. In either case, the banking authority 3320 maintains a database 3325 , which associates the public key of the card 95 with the corresponding account of the authorized user of the IC card 95 , and has the authority to approve or disapprove online transactions requested against such account.
- the merchant When an item is purchased by the suspect user 46 , the merchant “rings up” the item on the merchant cash register/terminal 3302 and the total balance due is displayed to the suspect user 46 on the display 3304 .
- the suspect user 46 inserts the IC card 95 into the point of sale card reader 3308 (or brings the IC card 95 into proximity to the card reader 3308 ).
- the point of sale card reader 3308 Upon insertion (or approach), the point of sale card reader 3308 is initialized in a manner similar to the card readers previously described.
- the identification marker and all the DSFlags on the computer chip 50 of the IC card 95 are reset when power is first supplied to the card 95 by the point of sale card reader 3308 .
- the merchant cash register/terminal 3302 transmits the balance due to the point of sale card reader 3308 via data connector 3306 .
- the point of sale card reader 3308 displays the balance due on display 3314 .
- the display 3314 also prompts the suspect user 46 to select whether he wants to pay using either a debit account or a credit card account.
- the point of sale card reader 3308 sends a “retrieve account information” command to the IC card 95 , which returns a list of all available checking, credit card, or other accounts maintained in memory location 80 on the computer chip 50 from which payment may be made.
- the display 3314 prompts the suspect user 46 to select one of the retrieved accounts for payment.
- the display 3314 next prompts the suspect user 46 to enter a PIN using the alphanumeric keypad 3310 and to place his right thumb on the thumbprint scanner 3312 .
- the point of sale card reader 3308 transmits both the PIN and a digitized version of the thumbprint to the IC card 95 .
- the card reader 3308 transmits the value of the PIN and digitized thumbprint along with an identifier (e.g., 001 for the PIN and 002 for the thumbprint) for each so that the card 95 “knows” the type and order of the verification data input.
- the computer chip 50 on the card 95 identifies the verification status of the IC card 95 in the manner previously described.
- the point of sale card reader 3308 then sends a message input command to the IC card 95 .
- the message input command includes message data comprising a receipt for the item purchased, the total balance due, and the payment account specified by the suspect user 46 .
- the account would be retrieved from memory location 80 (on the computer chip 50 ) and inserted into the message data using a suitable “tag,” indicating whether the primary debit account or primary credit card account number should be used.
- the account number for the account specifically selected by the suspect user 46 from the list of available accounts displayed on display 3314 is included in the message data received from the card reader 3308 .
- the computer chip 50 on the IC card 95 retrieves the current value of the identification marker (including therein the value of Rs and DSFlag(001), and including therein the values of Rb(002) and DSFlag(002)), modifies the message data received from the point of sale card reader 3308 with the value of the identification marker by pre-pending the value to the message data, calculates a hash value of the modified message data, encrypts the hash value to generate a digital signature, and exports the digital signature and value of the identification marker to the point of sale card reader 3308 .
- the computer chip 50 then increments the value of all of the DSFlags to “1.”
- the digital signature, value of the identification marker, and message data are then communicated by the point of sale card reader 3308 to banking authority 3320 for processing.
- the banking authority 3320 first confirms that the specified account number is a valid account number. The banking authority 3320 then decrypts the digital signature using the public key associated with the identified account number in the database 3325 . If the decrypted hash value from the digital signature matches a hash value of the message data, as modified by the value of the identification marker received from the IC card 95 , then it is determined that the IC card 95 from which the digital signature is received contains the unique private key and that the message data containing the receipt and total balance due has not been modified since it was digitally signed.
- the banking authority 3320 checks the verification status indicated by the value of the identification marker provided by the IC card 95 to determine whether the suspect user 46 is in fact the authorized user of the IC card 95 .
- This is a two-step process as two different types of verification data are received by the IC card 95 and used to identify the verification status of the IC card 95 .
- the banking authority 3320 uses business logic or a rule base to determine if the thumbprint provided by the suspect user 46 is sufficiently similar to the thumbprint of the authorized user stored on the card 95 so as to infer again that the suspect user 46 is the authorized user.
- the business logic and rule base of the banking authority 3320 is such that it may rely upon varying combinations of values for Rs (PIN) and Rb(002) (thumbprint) in accepting the suspect user 46 as the authorized user.
- Rs PIN
- Rb(002) Thumbprint
- a correct PIN by itself, a correct PIN plus at least a 60% match of thumbprint, an incorrect PIN if the thumbprint exceeds 96%, and an incorrect PIN but two thumbprints exceeding 90% (but not identical) are all different types of verification statuses that may be sufficient for the banking authority 3320 to accept Factors B and C Entity Authentication of the suspect user 46 by the card 95 .
- the banking authority 3320 grants approval of the transaction and transmit confirmation of the same back to the point of sale card reader 3308 .
- the business logic, rule base, and other factors that are taken into consideration by the banking authority 3320 can vary widely, depending upon the necessary level of security desired by the banking authority 3320 .
- a risk of using a device, such as the IC card 95 , in conjunction with the example given in FIG. 33 is the fact that the user of the IC card 95 must rely upon the display 3314 of the card reader 3308 , which is under the control of the point of sale merchant, to present an actual representation of the message displayed for generating a digital signature with the IC card 95 . It is possible for an unscrupulous merchant, for example, to display a purchase price of one amount but have the message data that is transmitted by the card reader 3308 to the IC card 95 to have a higher purchase price. To minimize the risk of such fraud, it is preferable for the computer chip 50 , described in FIG.
- a PDA or cell phone which has its own display (presumably under the control of the owner of the device). Since a PDA or cell phone could be programmed to display the full text of message data accurately prior to the generation of a digital signature thereof with the device, it would be more difficult for a merchant to “present” one purchase price to the customer but actually have a different purchase price included within the message to be digitally signed.
- a PDA or cell phone Unlike an IC card 95 , a PDA or cell phone also provides the user with much greater flexibility and privacy. For example, continuing with the illustration from FIG. 33, rather than having the point of sale reader 3308 prompt the user to select from only a limited number of primary payment accounts, a PDA or cell phone enables the user to store and select from all payment accounts stored on the device. In addition, rather than having the point of sale reader 3308 actually retrieve all available payment accounts from the IC card 95 , which potentially raises some privacy concerns, a PDA or cell phone allows the user to select an account from a list presented by the device and not by the point of sale merchant. Thus, the point of sale merchant never becomes privy to the list of account numbers maintained by the device.
- the party receiving the digital signature generated by the IC card 95 is potentially subject to a replay attack.
- a replay attack occurs when an original digital signature from a device is copied and then reused in an unauthorized manner. Since both the original and copy of a digital signature will decrypt with the appropriate public key, the party receiving the digital signature needs to have some way of distinguishing between the original and a later copy.
- the generation of random numbers may be performed, for example, using any of the random number generators specified in appendix 3 of FIPS PUB 186-2.
- a secure chip manufactured to operative in accordance with the present inventions may sign a computed SHA-1 hash on the data transmitted to the chip for signature, even if the transmitted data is itself already a hash value.
- a “double” SHA-1 leaves no ambiguity regarding whether the consumer's MDS device was presented the raw data stream, computed the SHA-1, and signed it, or whether the device was presented a precomputed SHA-1.
- the digital signature is always in accordance with the digital signature standard (DSS), i.e., a new random number is computed for every digital signature operation.
- DSS digital signature standard
- This operation is normally “latched” by discrete latching components or circuits so that it is only performed once per chip. Care should be taken to handle the situation where the latch is reset if the chip has been zeroized. Preferably, when latched, subsequent execution of this function returns an invalid indication.
- the private key is never available outside of the signing environment.
- a data stream is provided to the digital signature signing environment, in response to which the secure chip performs a SHA-1 on the data stream and then signs the calculated SHA-1.
- Procedures for doing streaming SHA-1 calculations are preferably verified (i.e. a mechanism is preferably provided for calculating SHA-1 on a data stream larger than local available memory.
- the preferred secure chip may include optional service enhancements for additional operations as part of signing a data stream.
- Personalization services may ship an uninitialized PIN card to a consumer. It is specifically contemplated that there can be a combination process where the consumer both initializes the device PIN for the first time and activates use of their device with their service provider and/or financial institution.
- the digital signature function will preferably always return a reasonable result, regardless of whether the correct PIN has been entered, an incorrect PIN has been entered, or no PIN has been entered. This is an important issue to take into consideration, because the normal range of PIN values in many consumer applications are four digits, which is readily susceptible to an offline brute-force attack on a stolen device (i.e., it is computationally easy to mount a brute force attack on a device that only provides approximately 2**10 possible values).
- the present invention may be employed in conjunction with the presently defined version 0 X9.59 ASN.1 encoded signed format, and with the contemplated version 1 X9.59 signed format that uses all the same fields as version 0 but with the emerging XML format (e.g. with FSML deterministic encoding considerations).
- the same process can be used to implement specialized support for other types of tagged objects, adding information to be singed from data previously saved in the device for this purpose.
- the signing device may recognize the object being signed and perform special functions.
- the X9.59 signed object data stream is defined as being from the “ ⁇ ” (less than) symbol of the ⁇ x9.59v-doc> tag to the “>” greater than of the ⁇ /x9.59v-doc> tag (not including the trailing newline character; alternatively, it may be easier to just include the trailing new-line character).
- End-of-line within the body of an X9.59 signed object is a single new-line character (SHA-1 treats the data a single sequential bit-stream regardless of any textual meanings and/or delimiters).
- Added value X9.59 features in this environment can overlay some tag field value with a value stored in the signing device (or optionally insert a field value only when the supplied value is null).
- Exemplary fields in the X9.59 message format for which this might be done include: “prc_c”, “date_e”, and “luid”.
- the enhanced x9.59 services can support the saving of X9.59 field values and/or management of X9.59 field values. This may require spare memory in the device for field values. This will allow a device to be used for X9.59 financial transactions in environments where it is not necessary to know the consumer's account number (and/or expiration date).
- Another possible enhanced X9.59 function is for the signing device to keep track of transactions executed by supplying the “luid” field and incrementing the value after each X9.59 signature operation. It will be appreciated that any fields supplied and/or overlayed in this manner by the enhanced X9.59 functions are preferably returned as part of the signature results provided by the secure chip upon executing the digital signature function.
- enhanced X9.59 services can offer specific operations. Given that many forms of attacks are thwarted by various measures, attackers are left with attempting valid online transactions. While the basic process employed in the disclosed secure chip for thwarting attacks is to return a signature on data other than provided, enhanced X9.59-compatible services can codify the way the data has been modified, given the online service hints as to an attack being in progress.
- a secure chip constructed as described herein may be utilized for transactions that satisfy the ISO 8385 message standard.
- the X9.59 object type field is preferably never transmitted since it is always assumed to be a fixed value for an authorization request.
- the online service When the online service is operative to recreate the original signed object and verify the signature, it typically plugs in a fixed value into the object type field before calculating the SHA-1 on the reconstructed object.
- X9.59 enhanced services can always choose to modify this specific field using a proscribed convention when a valid PIN has not been entered.
- the signature will fail because the object actually signed was not a bit-for-bit duplicate of the reconstructed object.
- the online service when an invalid signature is encountered, can modify the reconstructed data with the different possibilities and attempt to re-verify the signature.
- nnn . . . is numeric data
- hhh . . . is hexadecimal representation of binary data
- ⁇ sig> is the DSS signature of the tagged elements.
- a device constructed in accordance with the present invention preferably has the following aspects: high integrity, tempested, immune to all known chip card attacks, having true random number generator, can generate ECC key pair in less than 1 _second, on-chip ECC key pair generation, and the private key never leaves the chip.
- Such a device can be configured as an independent hardware token or embedded in other devices, such as: contact chip cards, contactless chip cards, rings, watches, PDAs, cellphones, USB tokens, etc.
- the basic functions supported are: PKCS # 11 EC/DSS digital signing, PIN/biometric initialization, PIN/biometric activation or comparison analysis, key pair generation, and export public key.
- the digital signing function is performed on some message that is associated with some identifier (e.g., account number, userID, employee ID, or other information).
- the identifying information, formatting the message, and computation of the SHA-1 (FIPS-180) secure hash of the message may be performed by some supporting personal computing device (personal PC, cellphone, PDA, other I/O support element, etc.), but may also be computed within the device itself.
- personal computing device personal PC, cellphone, PDA, other I/O support element, etc.
- a “stand-alone” computing chip (not operated in conjunction with a personal computing device like a PDA or cellphone) requires additional functions to supply the ID information (account number, user ID, employee ID, chip ID, etc.) that is part of a digital signature authentication function.
- Non-personally owned devices typically read-ID information from the device, create a message with identifying information, compute the SHA-1 hash of the message, write the hash to the device, and read DSS signature from the device.
- load-ID and read-ID functions are required. There are multiple ID architectures possible. One architecture is a single load-ID operation that is latched so that it can only be executed once.
- This ID would either be 1) business-process unique ID (e.g., limiting the device to a specific “ID” related function), or 2) device unique—allowing the device to be used in multiple different business processes, but requiring the business process to map the device unique ID to a business process specific ID, for example, an employee ID for building and corporate data process access.
- the actual employee ID is loaded into the device, or a device-unique ID is loaded and the employee access function maps a card unique ID into a employee ID.
- Another architecture is multiple ID slots that carry a “tag” identifying the associated use. Each slot is latched so that it is only initialized once.
- the latter architecture arrangement more easily allows multiple application specific IDs to be carried in the device, as opposed to relying on a device-specific ID and the application mapping the card ID to an application-specific ID.
- the load-ID function preferably specifies an ID-tag and ID-value and the device returns a message indicating that the slot is not available if there are no unallocated slots.
Abstract
Description
- This patent application claims priority in the United States under 35 U.S.C. 119, and under the Paris Convention worldwide, to the benefit of the filing date of Wheeler et al. U.S. provisional patent application serial No. 60/223,076, which was filed on Aug. 4, 2000, and which is incorporated herein by reference. This application also incorporates herein by reference each of four international patent applications and two U.S. patent application to Anne and Lynn Wheeler filed concurrently herewith on Aug. 6, 2001, in the U.S. Patent & Trademark Office and bearing serial number PCT/US______ /______(entitled “Person-Centric Account-Based Digital Signature System”) and serial number 09/_______,_______ (entitled “Account-Based Digital Signature (ABDS) System”); serial number PCT/US_______/_______(entitled “Entity Authentication in Electronic Communications by Providing Verification Status of Device”); serial number PCT/US______/______(entitled “Linking Public Key of Device to Information During Manufacture”) and serial number 09/______,______ (entitled “Manufacturing Unique Devices That Generate Digital Signatures”); and serial number PCT/US______/______(entitled “Trusted Authentication Digital Signature (TADS) System”).
- The present invention generally relates to entity authentication and, in particular, to entity authentication in the field of electronic communications.
- As used herein, an electronic communication (“EC”) is considered to be any communication in electronic form. ECs have become an integral part of transacting business today, especially with the growth of the Internet and e-commerce. An EC can represent, for example, a request for access to information or a physical area, a financial transaction, such as an instruction to a bank to transfer funds, or a legal action, such as the delivery of an executed contract.
- Over recent years, digital signatures also have become an important part of e-commerce. The origination of a digital signature generally comprises: (1) the calculation of a message digest—such as a hash value; and (2) the subsequent encryption of the message digest. The message digest is encrypted by an electronic device generally using a private key of a key pair used in public-private key cryptography (also known as asymmetric cryptography). The resulting ciphertext itself usually constitutes the digital signature, which typically is appended to the message to form the EC. The second part of originating the digital signature—using encryption with a private key—is referred to herein as “generating” the digital signature, and the combined two steps is referred to herein as “originating” the digital signature. Furthermore, while the generation of the digital signature is conventionally understood as the encryption of the message digest, it is contemplated herein that generating the digital signature also may include simply encrypting the message rather than the message digest. Digital signatures are important because any change whatsoever to the message in an EC is detectable from an analysis of the message and the digital signature. In this regard, the digital signature is used to “authenticate” a message contained within the EC (hereinafter referred to as “Message Authentication”).
- For example, a message digest may be calculated by applying a hashing algorithm—such as the SHA-1 algorithm—to the message. The hashing algorithm may be applied either within the device or external to the device with the resulting hash value then being transmitted to the device for generation of the digital signature. In order to perform Message Authentication in this example, the recipient of the EC must know or be able to obtain both the identity of the hashing algorithm applied to the message as well as the public key (“PuK”) corresponding to the private key used to encrypt the message digest. With this knowledge, the recipient applies the appropriate hashing algorithm to the message to calculate a hash value, and the recipient decrypts the digital signature using the public key. If the hash value calculated by the recipient equals the hash value of the decrypted digital signature, then the recipient determines that the content of the message contained in the EC was not altered in transmission, which necessarily would have changed the hash value.
- In performing Message Authentication, the recipient also authenticates the sender of the EC, in so much as the recipient thereby confirms that the sender of the EC possessed the private key corresponding to the public key used successfully to authenticate the message. This is one type of entity authentication and is based on what the sender “has” (hereinafter referred to as “Factor A Entity Authentication”). Factor A Entity Authentication is useful when the recipient of the EC has trusted information regarding the identity of the owner of the private key. Such trusted information may arise from a digital certificate issued by a trusted third party that accompanies the EC and binds the identity of the private key owner with the public key. This trusted knowledge also may comprise actual knowledge of the identity of the private key owner, such as in the case where the recipient itself has issued the private key or device containing the private key to the owner.
- As will be appreciated, trust in the digital signature system depends upon the legitimate possession and use of the private key, i.e., upon the sender of the EC actually being the private key owner. A fraudulent use of a private key to generate a digital signature of an EC currently cannot be detected through the above-described Message Authentication and Factor A Entity Authentication procedures. The digital signature system therefore is susceptible to fraud if a private key of a device is stolen, either by discovery of the private key therein and subsequent copying and use in another device capable of generating digital signatures, or by physical theft of the device containing the private key.
- To guard against discovery of a private key and subsequent copying and use in another device, devices are manufactured with electronic shielding, zeroization, auditing, tamper evidence and tamper response, and other security features that safeguard the private key (and other protected data) contained therein. Such security features include hardware, software, and firmware and are well known in the art of manufacturing secure computer chips and other devices having cryptographic modules.
- The requirements of such security features are specified, for example, inFederal Information Processing Standards Publication 140-1, Security Requirements for Cryptographic Modules, US DOC/NBS, Jan. 11, 1994 (herein “FIPS PUB 140-1”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips; and Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules, US DOC/NBS, May 25, 2001 (herein “FIPS PUB 140-2”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips. FIPS PUB 140-1 and 140-2 also define security levels that may be met by a device based on the device's security features, with each of these defined security levels generally representing a various level of difficulty—in terms of time and money—that would be encountered in attempting to discern a private key of a device. Currently, four security levels are defined with
security level 4 being the highest level of security available. - Specifications for such security features also are set forth inTrusted Computing Platform Alliance Trusted Platform Module Protection Profile Version 0.45, TRUSTED COMPUTING PLATFORM ALLIANCE, September 2000; Trusted Platform Module (TPM) Security Policy Version 0.45, TRUSTED COMPUTING PLATFORM ALLIANCE, October 2000; and TCPA PC Implementations Specification Version 0.95, TRUSTED COMPUTING PLATFORM ALLIANCE, Jul. 4, 2001, which are incorporated herein by reference (collectively “TCPA Documents”), and which are available for download at http://www.trustedpc.com; and Common Criteria for Information Technology Security Evaluation, Smart Card Protection Profile, Draft Version 2.1 d, SMART CARD SECURITY USER GROUP, Mar. 21, 2001, which is incorporated herein by reference (hereinafter “Smart Card Protection Profile”), and which is available for download at http://csrc.nist.gov.
- To guard against fraudulent use of a device through theft of the device itself, a personal identification number (PIN), password, or passphrase (collectively referred to herein as “Secret”) is typically prestored within the device and must be input into the device before it will operate to generate digital signatures. Alternatively, the Secret is shared with the recipient beforehand and, when the EC later is sent to the recipient, the Secret also is sent to the recipient in association with the message. In the first case, verification of the Secret authenticates the user of the device (hereinafter “User Authentication”), and in the second case, verification of the Secret authenticates the sender of the EC (hereinafter “Sender Authentication”). In either case, confirmation of the Secret represents entity authentication based on what the user or sender “knows” (hereinafter “Factor B Entity Authentication”).
- Another countermeasure against fraudulent use of the device through physical theft includes the verification of a biometric characteristic—like a fingerprint—of the user of the device or sender of the EC. This type of authentication is based on what the user or sender “is” (hereinafter “Factor C Entity Authentication”). As with the Secret, a biometric value is either maintained within the device for User Authentication, or is shared with the recipient beforehand for Sender Authentication by the recipient.
- While Factor B Entity Authentication and Factor C Entity Authentication both reduce the risk of a fraudulent use of a device to generate a digital signature for a message, both also include significant drawbacks. For instance, if the Secret or biometric value is communicated to the recipient in association with a message for sender authentication by the recipient, then the Secret or biometric value first must have been shared with the recipient beforehand and safeguarded by the recipient as part of an established relationship. This conventional paradigm therefore precludes both Factor B Entity Authentication and Factor C Entity Authentication between entities having no such preexisting relationship.
- This paradigm also exposes the Secret or biometric value itself to a greater risk of theft. First, the transmission of the Secret or biometric value for verification carries with it the risk of interception and discovery during transit. Second, the Secret or biometric value must be safeguarded by the recipient, thereby exposing the Secret to theft from the recipient. This is especially significant in the corporate context where a rogue employee may steal the safeguarded Secret or biometric value (insider fraud historically has been the greatest risk).
- The potential damages also are extensive when the Secret or biometric value is stolen under this paradigm. Since it is difficult for an individual to remember multiple Secrets for multiple recipients, it is common for the same Secret to be used by an individual with different recipients. For example, with regard to credit cards, the same Secret usually is shared with all credit card companies as a matter of convenience, and usually comprises the mother's maiden name of the account holder. The theft of the Secret from one credit card company puts all of the other credit card accounts at jeopardy, at least until the Secret is changed. In the case of the theft of a biometric value, the damages are even more severe, as a person's biometric characteristic cannot be changed and, once lost, potentially compromises any future entity authentication therewith.
- Alternatively, when the Secret or biometric value is prestored and maintained within the device for User Authentication, the risks associated with safeguarding of the Secret or biometric value by the recipient and associated with transmission of the Secret or biometric value to the recipient are avoided. In this conventional paradigm, the recipient does not actually perform the verification—it is done at the device level.
- A drawback to this alternative paradigm, however, is that because the device remains inoperable until the correct Secret or biometric value of the user is entered, the recipient is unable to monitor repeated attempts to guess the Secret or biometric value. Furthermore, when the device is enabled by the entry of the correct Secret or a biometric value resulting in a match, the device typically remains enabled for a predefined period of time thereafter, such as until it is powered off or resets. Under this alternative paradigm, a recipient is unable to determine whether a particular EC sent during such a time period includes a fraudulently generated digital signature, as the device may have been stolen after being enabled but before its deactivation. Accordingly, while there is User Authentication under this alternative paradigm, there is no provision per se for Sender Authentication.
- Yet another drawback is that this alternative paradigm does not particularly accommodate the use of the device to send ECs to different recipients when a biometric value is prestored and maintained within—and Factor C Entity Authentication is performed by—the device. In this regard, different recipients may have different requirements as to what constitutes a biometric “match” so as to be a successful verification; a biometric match is a determination of whether a biometric value input is sufficiently close to a stored biometric value so as to meet at least a minimum security threshold. A security threshold is subjectively set by each recipient and includes factors such as the nature of the communication and the extent of liability to the recipient for actions and responses based on a fraudulently sent EC. Different recipients cannot make their own match/no-match determinations based on their own requirements, standards, and criteria if each recipient does not receive beforehand the biometric value of the sender, make its own comparison thereof with each additional biometric value that is received in association with a message, and apply its own business judgment as to whether the comparison is sufficiently close so as to be a match.
- Accordingly, a need exists for a new paradigm in which Factor B Entity Authentication and/or Factor C Entity Authentication is used, but in which the aforementioned drawbacks of the conventional paradigms that use such authentication procedures are overcome. In particular, a need exists for such a paradigm that provides for both User Authentication as well as for Sender Authentication using either or both of Factor B Entity Authentication and Factor C Entity Authentication, and all without requiring a recipient to safeguard either a Secret or a biometric value. In this regard, a need exists for such a paradigm in which Factor B Entity Authentication and Factor C Entity Authentication can be reliably inferred by the recipient without the recipient being privy to the authenticating information, thereby addressing privacy concerns. Furthermore, a need exists in such a paradigm for the recipient to be able to determine, in its own subjective business judgment, what constitutes a successful biometric match when Factor C Entity Authentication is used. A need also exists for such a paradigm in which the recipient is able to monitor repeated attacks on a device to guess a Secret or a biometric value, and for such a paradigm that further accommodates the use of a single device for the sending of ECs to various, unrelated recipients.
- A. First Aspect of the Present Invention
- A first aspect of the present invention relates to the provision of a verification status of a device and includes the steps of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of verification data input into the device and data prestored within the device; and, independent of the verification status identified, transmitting the identified verification status to an electronic apparatus external to the device. One of the predefined verification statuses is representative of the verification data being the same as the prestored data, and at least one other verification status is representative of the verification data being different from the prestored data. An indicator of the identified verification status is output from the device.
- In a variation of this aspect of the invention, the verification status regards an entity authentication using a device. This variation includes the steps of receiving within the device input comprising verification data of an entity; identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of the verification data and data prestored within the device; and, independent of the verification status identified, outputting from the device an indicator of the identified verification status. Again, one of the predefined verification statuses being representative of the verification data being the same as the prestored data, and at least one other verification status being representative of the verification data being different from the prestored data.
- In another variation, a first entity is authenticated to a second entity. In this variation, data of the first entity is stored within a verification component of a device during a personalization of the verification component. Later, verification data is input into the device and received within the verification component of the device, and a current verification status is identified as a function of the verification data and prestored data within the verification component of the device. The verification status identified is one out of a plurality of predefined verification statuses of the device that include a verification status representative of the verification data being the same as the prestored data, and at least one other verification status representative of the verification data being different from the prestored data. Independent of the verification status identified, such verification status is communicated to the second entity. The verification status is communicated to the second entity by outputting an indicator of the verification status from the verification component and transmitting the output indicator to the second entity.
- In a fourth variation of this aspect of the present invention, a verification status regarding an entity authentication is provided wherein no verification data is yet received by a device. In particular, the method in this case includes the steps of maintaining within the device prestored data of an entity for identifying a verification status of the device as a function of the prestored data and verification data later input into the device; identifying within the device a current verification status of the device representing the lack of input of any verification data during a predefined period of time; and outputting from the device an indicator of the identified verification status for evaluation thereof. Preferably at some point thereafter, input comprising verification data is received within the device, a current verification status is identified within the device out of a plurality of predefined verification statuses of the device by comparing the received verification data with the prestored data; and an indicator of the identified verification status is again output from the device for evaluation thereof, wherein the second indicator reveals the identified verification status based on the comparison. Preferably, one verification status out of the plurality of predefined verification statuses of the device is representative of the verification data being the same as the prestored data, and at least one other predefined verification status is representative of the verification data being different from the prestored data.
- In preferred embodiments of this aspect of the present invention: the prestored data represents either a Secret or biometric characteristic, or both; the verification status identified as the current verification status represents a relational correspondence between the verification data and the prestored data without revealing either of the verification data or the prestored data; and the device is capable of generating digital signatures. Additionally, a request is evaluated with business logic based on the identified verification status.
- B. Second Aspect of the Present Invention
- A second aspect of the present invention relates to the provision of a verification status of a device and includes the steps of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of biometric verification data input into the device and biometric data prestored within the device; and, independent of the verification status identified, transmitting an indicator of the identified verification status to an electronic apparatus external to the device, the indicator revealing the identified verification status without revealing either of the verification data or the prestored data. The indicator of the identified verification status is output from the device.
- In a variation of this aspect of the invention, the verification status regards an entity authentication using the device. This variation includes the steps of receiving within the device input comprising biometric verification data of an entity; identifying within the device a current verification status out of a plurality of verification statuses of the device as a function of the verification data and biometric data prestored within the device; and, independent of the verification status identified, outputting from the device an indicator of the identified verification status, the indicator revealing the identified verification status without revealing either of the verification data or the prestored data.
- In another variation, a first entity is authenticated to a second entity. In this variation, biometric data of the first entity is stored within a verification component of a device during a personalization of the verification component. Later, biometric verification data is input into the device and received within the verification component of the device, and a current verification status is identified as a function of the verification data and prestored data within the verification component of the device. Independent of the verification status identified, such verification status is communicated to the second entity by outputting from the verification component an indicator of the identified verification status and transmitting the output indicator to the second entity. The indicator reveals the identified verification status without revealing either of the verification data or the prestored data.
- In a fourth variation of this aspect of the present invention, a verification status regarding an entity authentication is provided wherein no verification data is yet received by a device. In particular, the method in this case includes the steps of maintaining within the device prestored biometric data of an entity for identifying a verification status of the device as a function of the prestored data and biometric verification data later input into the device; identifying within the device a current verification status of the device representing the lack of input of any verification data during a predefined period of time; and outputting from the device an indicator of the identified verification status for evaluation thereof. Preferably at some point thereafter, input comprising verification data is received within the device, a current verification status is identified within the device out of a plurality of predefined verification statuses of the device by comparing the received verification data with the prestored data; and an indicator of the identified verification status is again output from the device for evaluation thereof, wherein the second indicator reveals the identified verification status based on the comparison without revealing either of the verification data or the prestored data.
- In preferred embodiments of this aspect of the present invention: one verification status out of the plurality of predefined verification statuses of the device is representative of the verification data being the same as the prestored data, and at least one other predefined verification status is representative of the verification data being different from the prestored data; and the device is capable of generating digital signatures. Additionally, a request is evaluated with business logic based on the identified verification status.
- C. Third Aspect of the Present Invention
- A third aspect of the present invention relates to the provision of a verification status of a device and includes the steps of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device; generating within the device a digital signature for a message as a function of the identified verification status, including modifying within the device data representing the message as a function of the identified verification status of the device such that the generated digital signature comprises an indicator of the identified verification status; and, transmitting the generated digital signature to an electronic apparatus external to the device. The identification of the current verification status is a function of verification data input into the device and data prestored within the device.
- In a variation of this aspect of the invention, the verification status regards an entity authentication. This variation includes the steps of receiving within the device input comprising verification data of an entity; identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of the verification data and data prestored within the device; generating within the device a digital signature for a message as a function of the identified verification status, including modifying within the device data representing the message as a function of the identified verification status of the device such that the generated digital signature comprises an indicator of the identified verification status; and outputting from the device the generated digital signature.
- In another variation, a first entity is authenticated to a second entity. In this variation, data of the first entity is stored within a verification component of a device during a personalization of the verification component. Later, verification data is input into and received within the verification component of the device, and a current verification status is identified as a function of the verification data and prestored data within the verification component of the device. The verification status identified is one out of a plurality of predefined verification statuses of the device. A digital signature then is generated within the device for a message as a function of the identified verification status and includes modifying within the device data representing the message as a function of the identified verification status of the device. The generated digital signature comprises an indicator of the identified verification status. The digital signature is output from the verification component of the device and, thereafter, communicated to the second entity.
- In a fourth variation of this aspect of the present invention, a verification status regarding an entity authentication is provided wherein no verification data is yet received by a device. In particular, the method in this case includes the steps of maintaining within the device prestored data of an entity for identifying a verification status of the device as a function of the prestored data and verification data later input into the device; identifying within the device a current verification status of the device representing the lack of input of any verification data during a predefined period of time; generating within the device a digital signature for a message such that the generated digital signature comprises an indicator of the identified verification status; and outputting from the device the generated digital signature for evaluation of the identified verification status. Preferably at some point thereafter, input comprising verification data is received within the device; a current verification status is identified within the device out of a plurality of predefined verification statuses of the device by comparing the received verification data with the prestored data; and another digital signature is generated within the device for a message as a function of the identified verification status. In this regard, data representing the message is modified within the device as a function of the identified verification status of the device. The second generated digital signature comprising an indicator of the identified verification status is then output from the device for evaluation thereof.
- In preferred embodiments of this aspect of the present invention, one verification status out of the plurality of predefined verification statuses of the device is representative of the verification data being the same as the prestored data, and at least one other predefined verification status is representative of the verification data being different from the prestored data; the indicator of the identified verification status neither reveals the prestored data nor the verification data; the prestored data represents a Secret; and the prestored data represents a biometric characteristic. Additionally, a request is evaluated with business logic based on the identified verification status.
- The generation of the digital signature includes encrypting within the device using a private key of a public private key pair a message digest calculated within the device for the modified data. In a preferred embodiment, the digital signature for the modified data representing the message is output from the device, but the modified data itself is not output from the device.
- In some preferred embodiments, the message is composed within the device by a user of the device. Preferably, the message for which a digital signature is generated is displayed on a display screen of the device for review and approval by the user. Alternatively, the message is composed within an I/O support element external to the device which, in turn, transmits the input representing the message into the device through an interface of the device. In other preferred embodiments, a portion of the message is composed within an I/O support element external to the device which, in turn, transmits input representing the portion of the message into the device through an interface of the device, and a remaining portion of the message is composed within the device. The I/O support element may comprise, for example, a point of sale terminal, a biometric scanner, a card reader, or a computer.
- The message itself may be for the performance of a financial transaction, the performance of a legal action, access to a database, access to a physical space, access to a web site, or access to a computer program. The message also may be predetermined and static, and may be stored within the device itself. Verification data also may not be required to be input into the device for other types of messages, or for a predefined period of time such as the time between approval of a request embodied in a message and a powering off of the device.
- The data representing the message comprise a hash value of the message or, alternatively, the data representing the message comprise a message digest for the message. The data representing the message may be stored within the device. The modification of the data representing the message preferably includes: embedding the assigned value of an identification marker within the data representing the message; appending the assigned value of the identification marker to the data representing the message; appending the assigned value of the identification marker to the beginning of the data representing the message; and appending the assigned value of the identification marker to the end of the data representing the message.
- In preferred embodiments, verification data may be required to be input into the device following a predefined period of time after a last successful verification, and verification data may be required to be input into the device for each one of a particular type of message. The particular type of message may comprise, for example, a request for a financial transaction.
- Additional preferred embodiments include message authentication using the digital signature generated within the device, and include the steps of: modifying data representing the message embodying the request as a function of a suspected verification status of the device, calculating a message digest as a function of the modified data, decrypting the generated digital signature using the public key of the public-private key pair, and concluding the verification status of the device as being the suspected verification status of the device when the calculated message digest matches the decrypted digital signature.
- The device preferably identifies the current verification status of the device by assigning an identification marker within the device equal to a value out of a set of predefined values corresponding to the predefined verification statuses. In a preferred embodiment, the identification marker is assigned a value equated with a successful verification, and the assigned value further represents whether a digital signature was generated since verification data was last input into the device. Furthermore, the generated digital signature preferably comprises the indicator.
- D. Fourth Aspect of the Present Invention
- A fourth aspect of the present invention relates to the provision of a verification status of a device and includes the step of identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of verification data input into the device and data prestored within the device. This step includes comparing verification data representing a Secret with the data prestored within the device and assigning, based on the comparison, a first comparison marker within the device equal to a value out of a set of predefined values; and comparing verification data representing biometric data with the data prestored within the device and assigning, based on the comparison, a second comparison marker within the device equal to a value out of a set of predefined values. Data representing a message is modified within the device as a function of the assigned values for the first and second comparison markers. Thereafter, a digital signature is generated within the device for the modified data such that the generated digital signature comprises an indicator of the identified verification status. The generated digital signature then is transmitted to an electronic apparatus external to the device.
- In a variation of this aspect of the invention, the verification status regards an entity authentication using a device. This variation includes the steps of receiving within the device input comprising verification data of an entity, the verification data representing both a Secret and a biometric characteristic of the entity; identifying within the device a current verification status out of a plurality of predefined verification statuses of the device as a function of the verification data and data prestored within the device; modifying within the device data representing a message as a function of the identified verification status and generating within the device a digital signature for a message such that the generated digital signature comprises an indicator of the identified verification status; and outputting from the device the generated digital signature. The identification of the verification status includes comparing verification data representing the Secret with the data prestored within the device and assigning, based on the comparison, a first comparison marker within the device equal to a value out of a set of predefined values; and comparing verification data representing biometric data with the data prestored within the device and assigning, based on the comparison, a second comparison marker within the device equal to a value out of a set of predefined values. The modification of the message data includes modifying the data as a function of the assigned values for the first and second comparison markers.
- In another variation, a first entity is authenticated to a second entity. In this variation, data representing both a Secret and biometric data of the first entity is stored within a verification component of a device during a personalization of the verification component. Later, verification data is input into the device and received within the verification component of the device, and a current verification status is identified as a function of the verification data and prestored data within the verification component of the device. The identification of the verification status includes comparing verification data representing the Secret with data prestored within the device and assigning, based on the comparison, a first comparison marker within the device equal to a value out of a set of predefined values; and comparing verification data representing biometric data with data prestored within the device and assigning, based on the comparison, a second comparison marker within the device equal to a value out of a set of predefined values. A digital signature is generated within the device for a message by first modifying within the device data representing the message as a function of the assigned values for the first and second comparison markers, and then encrypting the modified data such that the digital signature comprises an indicator of the identified verification status. The digital signature then is output from the verification component and transmitted to the second entity.
- In preferred embodiments of this fourth aspect of the present invention: one verification status out of the plurality of predefined verification statuses of the device is representative of the verification data being the same as the prestored data, and at least one other predefined verification status is representative of the verification data being different from the prestored data; the assigned value of the first comparison marker, the assigned value of the second comparison marker, or the assigned values of the first and second comparison markers are output from the device with the generated digital signature; and the modification of the message includes embedding the assigned value of the first comparison marker, the assigned value of the second comparison marker, or both, within the data representing the message, or appending such assigned value(s) to the data representing the message, including appending to the beginning or the end of the message data. Additionally, a request is evaluated with business logic based on the identified verification status.
- In alternative embodiments to this fourth aspect of the present invention, the data representing the message is modified as a function of only one of the assigned values for the first and second comparison markers. Furthermore, the generated digital signature for the message and the other of the assigned values for the first and second comparison markers is transmitted to the second entity.
- E. Fifth Aspect of the Present Invention
- A fifth aspect of the present invention relates to determining a current verification status of a device that generates a digital signature and includes the steps: receiving a digital signature; decrypting the digital signature using a public key of a public-private key pair; for each one of a plurality of predefined verification statuses of the device, modifying data representing a message as a function of the predefined verification status; and identifying the current verification status of the device as being the predefined verification status for which the modified data matches the decrypted digital signature. In a variation of this aspect, a message digest is calculated as a function of the modified data following the modification. The calculation of the message digest as a function of the modified data may include the calculation of a hash value for the modified data.
- In preferred embodiments of this fourth aspect of the present invention, each one of the verification statuses represents a relational correspondence between verification data input into the device and data prestored within the device. Furthermore, each verification status neither reveals verification data nor prestored data of the device for which the current verification status is determined.
- Preferably, the current verification status is associated with a request. The request, for example, may be for the performance of a financial transaction or for the performance of a legal action. The request, for example, may be predetermined and static and included in a predefined message. The request may be for access to a physical space, access to a web site, access to a database, or access to a computer program. Preferably, the request is received in association with the digital signature and evaluated based on the current verification status indicated by the digital signature. The evaluation of the request includes the step of considering an assurance level of the device generating the digital signature. The request may be implicit in the receipt of the digital signature. The request may be communicated over an electronic communications medium such as a computer network, whether public or private.
- Additionally, in preferred embodiments, one of the predefined verification statuses represents an unsuccessful verification; one of the predefined verification statuses represents a successful verification; one of the predefined verification statuses additionally represents whether a digital signature has been generated by the device since verification data was last input into the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated subsequent to a comparison of verification data input into the device with data prestored within the device; one of the predefined verification statuses additionally represents whether any verification data has been input into the device within a predetermined time period comprising, for example, the time since a last successful verification or the time since a resetting of the device.
- Additionally, in preferred embodiments, one of the predefined verification status represents a difference between verification data input into the device and data prestored within the device; one of the predefined verification statuses represents a degree of match between biometric verification data input into the device and biometric data prestored within the device; one of the predefined verification statuses additionally represents a percentage of match between biometric verification data input into the device and biometric data prestored within the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated by the device since verification data was last input into the device; one of the predefined verification statuses additionally represents whether a digital signature has been generated subsequent to a comparison of verification data input into the device with data prestored within the device; one of the predefined verification statuses additionally represents whether any verification data has been input into the device within a predetermined time period.
- F. Features of the Present Invention
- In features of the aforementioned aspects of the present invention, the device preferably identifies the current verification status of the device by assigning an identification marker within the device equal to a value out of a set of predefined values corresponding to the predefined verification statuses. In preferred embodiments, the identification marker is assigned a value equated with a successful verification when the comparison results in a match, including an exact match (e.g., when the data represents a Secret); the identification marker is assigned a value equated with a successful verification when the comparison results in a match, but not an exact match (e.g., when the data represents a biometric characteristic); and, the identification marker is assigned a value equated with an unsuccessful verification when a comparison between the verification data and the prestored data does not result in a match.
- Additionally in preferred embodiments, the identification marker is assigned a value representing a difference determined from a comparison between the verification data and the prestored data; the identification marker is assigned a value representing a degree of match between the verification data and the prestored data; the identification marker is assigned a value equated with a percentage of match between the verification data and the prestored data; and the identification marker is assigned a value representing whether any verification data was input into the device within a predefined time period, such as the time since a last successful verification or the time since a resetting of the device
- In preferred embodiments wherein the identification marker is assigned a value equated with a successful verification, the assigned value further represents whether an indicator was output subsequent to the successful verification or whether an indicator was output since verification data was last input into the device. In additional features, the indicator comprises the assigned value of the identification marker, and the assigned value further represents whether a digital signature was generated by the device since verification data was last input into the device. Furthermore, the device preferably generates a digital signature in response to an external inquiry received by the device, in response to receipt of data representing the message, or in response to receipt of input comprising the verification data.
- Other features of the present invention include the verification data being input directly into the device by a user; and, alternatively, input representing the verification data being received within an I/O support element external to the device and then transmitted into the device. The I/O support element may include, for example, a point of sale terminal, a biometric scanner, a card reader, an ATM machine, or a computer.
- In yet additional features, the indicator points definitively (i.e., without ambiguity) to a single predefined verification status of the device; neither the prestored data comprising a Secret and/or biometric data nor the verification data input into the device are exported from the device; and the device prestores data for a plurality of users of the device; a digital signature is generated within the device and output from the device with the value of the identification marker.
- When the prestored data comprises biometric data, the identification marker is assigned a value representing the type of the biometric data in a feature of the present invention. Furthermore, the biometric data may represent, for example, a digitized fingerprint, a digitized handprint or hand geometry, a digitized retina, a digitized iris, a digitized voice print, a digitized facial scan, a digitized written signature, or a digitized DNA sample. In such case, the device may include a biometric scanner for inputting of the verification data. The device also may prestore data for a plurality of different types of biometric data, whether for one person or for several persons.
- In other features of the present invention wherein a request is evaluated based on the identified verification status, verification data is required to be input into the device for each one of a particular type of request such as, for example, a financial transaction. Verification data may not be required to be input into the device for other types of requests. Verification data also may be required to be input into the device for a particular type of request, but only until an evaluation of the request results in an approval, and then verification data may not be required to be input into the device for additional requests of such type during a predefined period of time thereafter, such as the time between the approval of the request and a resetting of the device.
- Random numbers are utilized in may computer applications, such as in security protocols like secure socket layer (SSL) protocol and pretty good privacy (PGP) for the creation of session keys. Yet another feature of the present invention includes the generation of a digital signature using a digital signature algorithm, with the resulting digital signature being used in such an application as a random number.
- The device of the methods of the present invention preferably is a personal device of the sender of the EC. The device also preferably includes a device interface such as, for example, an alphanumeric keypad, an electrical contact, a touch screen display, a standard electronic interface with a computer bus, or an antenna. The device interface also may comprise a port the device, such as a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port. The device preferably is portable and of a handheld form factor. The device preferably includes a computer chip and/or integrated circuitry, and may be, for example, a cell phone, a PDA, a digitized key, a dongle, a subcutaneous implant, jewelry, an integrated circuit card (IC Card), a credit card, a debit card, smart card, a security card, an ID badge, or a computer.
- Other features of the present invention include: a device with a computer-readable medium having computer-executable instructions that perform one or more steps of a method of the present invention; integrated circuitry that performs one or more steps of a method of the present invention; and a computer chip that performs one or more steps of a method of the present invention.
- Benefits and further features of the present invention will be apparent from a detailed description of preferred embodiments thereof taken in conjunction with the following drawings, wherein like reference numbers refer to like elements, and wherein:
- FIG. 1 illustrates in block diagram a conceptual framework of the present invention;
- FIG. 2a illustrates a first preferred embodiment of the present invention;
- FIG. 2b illustrates a variation of the embodiment of FIG. 2a;
- FIG. 2c illustrates a variation of the embodiment of FIG. 2a;
- FIG. 3 illustrates a preferred mode of operation of the device of FIGS. 2a, 2 b, and 2 c;
- FIG. 4a illustrates a second preferred embodiment of the present invention;
- FIG. 4b illustrates a variation of the embodiment of FIG. 4a;
- FIG. 4c illustrates a variation of the embodiment of FIG. 4a;
- FIG. 5 illustrates a preferred mode of operation of the device of FIGS. 4a, 4 b, and 4 c;
- FIG. 6a illustrates a third preferred embodiment of the present invention;
- FIG. 6b illustrates a variation of the embodiment of FIG. 6a;
- FIG. 6c illustrates a variation of the embodiment of FIG. 6a;
- FIG. 7 illustrates a preferred mode of operation of the device of FIGS. 6a, 6 b, and 6 c;
- FIG. 8a illustrates a fourth preferred embodiment of the present invention;
- FIG. 8b illustrates a variation of the embodiment of FIG. 8a;
- FIG. 8c illustrates a variation of the embodiment of FIG. 8a;
- FIG. 8d illustrates a variation of the embodiment of FIG. 8a;
- FIG. 9 illustrates a preferred mode of operation of the device of FIGS. 8a, 8 b, and 8 c;
- FIG. 10a illustrates a fifth preferred embodiment of the present invention;
- FIG. 10b illustrates a variation of the embodiment of FIG. 10a;
- FIG. 10c illustrates a variation of the embodiment of FIG. 10a;
- FIG. 11 illustrates a preferred mode of operation of the device of FIGS. 10a, 10 b, and 10 c;
- FIG. 12a illustrates a sixth preferred embodiment of the present invention;
- FIG. 12b illustrates a variation of the embodiment of FIG. 12a;
- FIG. 12c illustrates a variation of the embodiment of FIG. 12a;
- FIG. 13 illustrates a preferred mode of operation of the device of FIGS. 12a, 12 b, and 12 c;
- FIG. 14a illustrates a seventh preferred embodiment of the present invention;
- FIG. 14b illustrates a variation of the embodiment of FIG. 14a;
- FIG. 14c illustrates a variation of the embodiment of FIG. 14a;
- FIG. 15 illustrates a preferred mode of operation of the device of FIGS. 14a, 14 b, and 14 c;
- FIG. 16a illustrates an eighth preferred embodiment of the present invention;
- FIG. 16b illustrates a variation of the embodiment of FIG. 16a;
- FIG. 16c illustrates a variation of the embodiment of FIG. 16a;
- FIG. 17 illustrates a preferred mode of operation of the device of FIGS. 16a, 16 b, and 16 c;
- FIG. 18a illustrates a ninth preferred embodiment of the present invention;
- FIG. 18b illustrates a variation of the embodiment of FIG. 18a;
- FIG. 18c illustrates a variation of the embodiment of FIG. 18a;
- FIG. 19 illustrates a preferred mode of operation of the device of FIGS. 18a, 18 b, and 18 c;
- FIGS. 20a, 20 b, and 20 c illustrate preferred formats of prestored data of the present invention;
- FIGS. 21a, 21 b, and 21 c illustrate preferred formats of verification data of the present invention;
- FIG. 22 illustrates a preferred comparison and verification status identification process;
- FIGS. 23a and 23 b illustrate preferred comparison and verification status identification processes;
- FIG. 24 illustrates a preferred comparison and verification status identification process;
- FIGS. 25a and 25 b illustrate preferred formats of identification markers of the present invention;
- FIG. 26 illustrates preferred formats of identification markers of the present invention;
- FIG. 27 illustrates a table of identification markers resulting from a hypothetical sequence of verification data inputs in accordance with the present invention;
- FIG. 28 illustrates a preferred data flowchart within an implementation of the present invention using a computer chip;
- FIG. 29 illustrates a first specific implementation of the present invention using an IC card;
- FIG. 30 illustrates a second specific implementation of the present invention using an IC card;
- FIG. 31 illustrates a third specific implementation of the present invention using an IC card;
- FIGS. 32a and 32 b illustrate fourth and fifth specific implementations of the present invention using an IC card; and
- FIG. 33 illustrates a sixth specific implementation of the present invention using an IC card.
- As a preliminary matter, it readily will be understood by those persons skilled in the art that, in view of the following detailed description of the devices, systems, and methods of the present invention, the present invention is susceptible of broad utility and application. Many embodiments and adaptations of the present invention other than those herein described, as well as many variations, modifications, and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and the following detailed description thereof, without departing from the substance or scope of the present invention. Furthermore, those of ordinary skill in the art will understand and appreciate that although steps of various processes may be shown and described in some instances as being carried out in a preferred sequence or temporal order, the steps of such processes are not necessarily to be limited to being carried out in such particular sequence or order. Rather, in many instances the steps of processes described herein may be carried out in various different sequences and orders, while still falling within the scope of the present invention. Accordingly, while the present invention is described herein in detail in relation to preferred embodiments, it is to be understood that this detailed description only is illustrative and exemplary of the present invention and is made merely for purposes of providing a full and enabling disclosure of the present invention. The detailed description set forth herein is not intended nor is to be construed to limit the present invention or otherwise to exclude any such other embodiments, adaptations, variations, modifications and equivalent arrangements of the present invention, the present invention being limited solely by the claims appended hereto and the equivalents thereof.
- A. Overview of the Present Invention
- Conceptually, the present invention is illustrated best in FIG. 1, wherein an
EC 110 including a message from asender 120 is received by arecipient 130. In accordance with the present invention, adevice 140 includes a verification component thereof that performs the functions of: receivinginput 150 representing verification data of thesender 120; identifying a current verification status of thedevice 140; and communicating the identified verification status (VS) 160 to therecipient 130 in association with theEC 110. The verification data represented by theinput 150 comprise a Secret or a biometric value. - In preferred embodiments of the present invention, discussed in detail below, the
verification status 160 preferably is identified within the device by maintaining prestored data of thesender 120 and by comparing the prestored data with the verification data that is input. Accordingly, the prestored data comprises a Secret or a biometric value, too. - In preferred embodiments, the
device 140 also includes a plurality of predefined verification statuses, each representing a relational correspondence between the verification data and the prestored data. None of the verification statuses, however, actually reveals the verification data or the prestored data; thus, there need be no “shared secret” between thesender 120 and therecipient 130. Thedevice 140 identifies one of the predefined verification statuses as being thecurrent verification status 160 based on the comparison of the verification data with the prestored data, and thedevice 140 communicates the identifiedverification status 160 to therecipient 130 by outputting from thedevice 140 an indicator of the identified verification status that then is transmitted to therecipient 130. The indicator may or may not actually comprise theverification status 160; however, the indicator does indicate to the recipient 130 (or enables therecipient 130 to determine) theverification status 160 identified within the device. - Additionally, the
device 140 preferably includes a predefined verification status representing that noinput 150 was received within a predefined period of time. Thedevice 140 identifies this verification status as being thecurrent verification status 160 if noinput 150 is received within such predefined period of time and, when appropriate, communicates such verification status to therecipient 130 in association with anEC 110. The predefined period of time may comprise, for example, the time since a resetting of thedevice 140 or simply a predetermined amount of time. Further, fordevices 140 that “power on” only when voltage or an appropriate signal is provided to the device 140 (e.g., voltage from an internal power supply, voltage from an external power supply, receipt of an RF signal, and the like), the predefined amount of time may comprise the time since thedevice 140 was, in fact, “powered on.” - Examples of possible verification statuses include “match” and “no match” between the verification data and the prestored data, and degrees of match or difference between the verification data and prestored data (e.g., when the verification data and prestored data comprises biometric values). The verification statuses also may further represent whether a verification status has been provided to the
recipient 130 within a predefined period of time. The predefined period of time may comprise, for example, the time since the last comparison of verification data with prestored data that resulted in a successful verification, the time since the last receipt ofinput 150 representing verification data, or simply a predetermined amount of time, as discussed above. - The
recipient 130 preferably has the ability of determining a level of risk associated with theEC 110 based on theverification status 160. Because of this determined level of risk associated with theEC 110, therecipient 130 is better able to evaluate the message of theEC 110. Therecipient 130 preferably is represented by an electronic apparatus that includes an interface for receiving the indicator transmitted fromdevice 140 and logic circuitry or software incorporating business logic for evaluating theEC 110 from thesender 120 based on the received indicator. The electronic apparatus may be located remote to thedevice 140 but disposed in electronic communication therewith, such as over an electronic communications network (e.g. Internet, intranet, wireless network, and the like). - It should be understood that, depending upon the context in which the
sender 120 andrecipient 130 are interacting, the message may be explicit or implicit. If implicit, the content of the message may be predefined. For example, the actual act of receiving an indicator of the verification status of thedevice 140 by therecipient 130 may, in itself, represent a message agreed upon between thesender 120 and therecipient 130. In such a case, noEC 110 containing a message need be sent. Furthermore, when anEC 110 actually is sent from thesender 120 to therecipient 130, part or all of theEC 110 may be composed and sent from thedevice 140, rather than separate from thedevice 140 as shown in FIG. 1. - B. Preferred Embodiments of the Present Invention
- 1. First Preferred Embodiment (Basic Model)
- A first
preferred embodiment 200 of the present invention is illustrated in FIG. 2a, wherein anEC 210 including a message from asender 220 is received by a recipient represented by anelectronic apparatus 230, and wherein adevice 240 receives input representing verification data (VD) 250 at adevice interface 252. Thedevice 240 includes a verification component therein that maintains data (PD) 270 of thesender 220 prestored inmemory 254 of thedevice 240. Theverification data 250 andprestored data 270 represent Secret or biometric values. - The verification component identifies at256 a current verification status of the
device 240 based on a comparison of theverification data 250 with theprestored data 270. Upon receipt of a signal (S) 280, the last identified (i.e., “current”) verification status of thedevice 240 is communicated to the recipient by outputting from thedevice 240 anindicator 260 that then is transmitted to the recipient in association with theEC 210. Thesignal 280 is sent to thedevice 240, which triggers thedevice 240 to output theindicator 260. Thesignal 280 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by thesender 220, by theelectronic apparatus 230, or by another apparatus (not shown). Thedevice interface 252 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 220; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port, or other wireless communications port. - The
device 240 also includes a set of predefined verification statuses each representing a relational correspondence between theverification data 250 and theprestored data 270. Verification statuses of the set further represent whether anindicator 260 has been output from thedevice 240 since the last successful verification or since the last receipt of input representing verification data. The set also contains one additional predefined verification status representing the lack of input representingverification data 250 since a resetting after a timeout or a powering on of thedevice 240. Theindicator 260 output from thedevice 240 is based on the last comparison of theverification data 250 with theprestored data 270, but only if input representingverification data 250 has been received since the resetting of thedevice 240. Otherwise, theindicator 260 indicates the lack of input representingverification data 250 since the resetting of thedevice 240. In either case, theindicator 260 is transmitted in association with theEC 210, whereby the recipient is able to identify theindicator 260 as relating to theEC 210. Theelectronic apparatus 230 includes an interface (not shown) capable of receiving theindicator 260 fromdevice 240, and also includes logic circuitry or software incorporating business logic therein for determining the verification status based on theindicator 260 and for evaluating theEC 210 received from thesender 220 based on the verification status of thedevice 240. - When the
verification data 250 and theprestored data 270 comprise a Secret, the predefined set of verification statuses includes at least four verification statuses, comprising: a first verification status representing the lack ofverification data 250 since a resetting of the device; a second verification status representing a match between theverification data 250 and theprestored data 270, and further representing noother indicator 260 being output from thedevice 240 since the match; a third verification status representing a failed match between theverification data 250 and theprestored data 270; and a fourth verification status representing a match between theverification data 250 and theprestored data 270, and further representing that anindicator 260 has been output since the match. Thedevice 240 preferably includes an identification marker (“IM”) 272 stored inmemory 274 and comprising one of four binary numbers that represents the current verification status identified by thedevice 240. The four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status. Furthermore, theindicator 260 output from thedevice 240 preferably includes the value of theidentification marker 272, with the correspondence of the value with the predefined verification statuses of thedevice 240 being previously known by the recipient. None of the verification statuses actually reveal theverification data 250 or theprestored data 270; thus, no “shared secret” is required between thesender 220 and the recipient. However, the recipient can infer correct knowledge of the Secret from the verification status. - Alternatively, when the
verification data 250 and theprestored data 270 comprise biometric values, the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between theverification data 250 andprestored data 270, together with a verification status representing the lack of input representingverification data 250 since a resetting of thedevice 240. For example, the predefined verification statuses comprising the percentage match of theverification data 250 with theprestored data 270 may comprise the set of percentages ranging from 0% to 100% in increments of 1%. Preferably each one of the verification statuses representing a percentage match also further represents whether anindicator 260 has been output from thedevice 240 since the last receipt of input representingverification data 250. Thedevice 240 preferably includes theidentification marker 272 for storing a value representing the verification status identified by thedevice 240 as the current verification status. Furthermore, theindicator 260 output from thedevice 240 preferably comprises the value of theidentification marker 272, with the correspondence of such value with the predefined verification statuses of the device being previously known by the recipient. - Again, none of the verification statuses actually reveal either of the
verification data 250 or theprestored data 270; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of thesender 220 from the reading of the biometric characteristic. - A variation based on the first
preferred embodiment 200 of FIG. 2a is shown in FIG. 2b, and includes an I/O support element 262 from which the input representing theverification data 250 is received at thedevice interface 252. The I/O support element 262 includes auser interface 258 from which input from the sender is received and an I/O interface 259 that communicates the input representing theverification data 250 to thedevice 240. Yet an additional variation thereof is shown in FIG. 2c, wherein the I/O support element 262 receives theindicator 260 output from thedevice 240 and, in turn, transmits theindicator 260 to theelectronic apparatus 230. - As shown, the
indicator 260 transmitted from the I/O support element 262 is the same as theindicator 260 output from thedevice 240. However, the indicator transmitted from the I/O support element 262 may be different from the indicator output from thedevice 240, so long as the recipient is able to determine the verification status as indicated by theindicator 260 output from thedevice 240. For instance, the indicator transmitted from the I/O support element 262 may indicate not only the verification status of thedevice 240, but also a verification status of the I/O support element 262 when the I/O support element 262 itself identifies a verification status. Furthermore, theindicator 260 transmitted from the I/O support element 262 may be packaged or embedded within another communication-including additional information that is digitally signed by the I/O support element 262. - In FIGS. 2a, 2 b, and 2 c, the
EC 210 is shown as being transmitted separate from theindicator 260. However, in the preferred embodiment of FIG. 2a and variations thereof, theindicator 260 equally may be associated with theEC 210 by being transmitted as part of theEC 210. Furthermore, theEC 210 may be output from thedevice 240, an associated I/O support element 262 (not shown in FIG. 2a), or other apparatus. - A
preferred mode 300 of operation of the device of FIGS. 2a, 2 b, and 2 c is illustrated in FIG. 3 and begins with aresetting Step 304 of the device following a timeout or powering on of the device at 302. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input representing verification data and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 306 and ends at 312 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. The first step in the loop preferably includes thedetermination Step 308 whether any input representing verification data (VD) is received by the device. If the determination inStep 308 is positive, the current verification status (VS) of the device is identifiedStep 314 by comparing the verification data (VD) with the data prestored (PD) in memory of the device. The verification status identified then is recorded by assigning Step 316 a value to the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing verification data is received in
Step 308 or after the value of the identification marker has been assigned inStep 316, a determination is then made of whether a signal (S) has been or is being received by the device. If a signal is not received, then the loop restartsStep 306. When a signal is received, the determination inStep 310 is positive and the indicator of the current verification status of the device isoutput Step 318. As set forth above, the indicator comprises the value of the identification marker maintained in memory within the device. Following the output of the indicator, the determination is madeStep 320 whether the indicator output is the first indicator output since receipt of input representing verification data. The loop restartsStep 306 if the determination inStep 320 is negative. If the determination inStep 320 is positive, then the verification status is newly recorded by assigning Step 322 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data was received inStep 308. The loop then restartsStep 306. - 2. Second Preferred Embodiment (Digital Signature for Indicator)
- A second
preferred embodiment 400 of the present invention is illustrated in FIG. 4a, wherein anEC 410 including a message from asender 420 is received by a recipient represented by anelectronic apparatus 430, and wherein adevice 440 receives input representing verification data (VD) 450 at adevice interface 452. Thedevice 440 includes a verification component therein that maintains data (PD) 470 of thesender 420 prestored inmemory 454 of thedevice 440. Theverification data 450 andprestored data 470 represent Secret or biometric values. - The verification component identifies at456 a current verification status of the
device 440 based on a comparison of theverification data 450 with theprestored data 470. Upon receipt of a signal (S) 480, the last identified (i.e., “current”) verification status of thedevice 440 is communicated to the recipient by outputting from thedevice 440 anindicator 460 that then is transmitted to the recipient in association with theEC 410. Also upon receipt of thesignal 480, a digital signature component of thedevice 440 originates a digital signature (DS) 482 for theindicator 460 by calculating a hash value for the indicator at 490 and then encrypting the hash value at 492 using aprivate key 495 of a public-private key pair. Thedigital signature 482 then is output from thedevice 440 and transmitted to the recipient with theindicator 460. For increased reliability and trust, theprivate key 495 is retained securely withinmemory 494 so that it is never exported from thedevice 440 and is not discoverable from outside of thedevice 440. - In this preferred embodiment, the digital signature is originated in accordance with an elliptical curve digital signature algorithm (ECDSA) as specified inFederal Information Processing Standards Publication 186-2, Digital Signature Standard, US DOC/NBS, Jan. 11, 1994 (hereinafter “FIPS PUB 186-2”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips. Accordingly, the
digital signature 482 is generated using a random number generator, and the hash function at 490 is performed using the secure hash algorithm (“SHA-1”), which generates a 20-byte output regardless of the size of the input received fromcomponent 456. The SHA-1 itself is specified in Federal Information Processing Standards Publication 180-1, Secure Hash Standard, US DOC/NBS, Apr. 17, 1995 (hereinafter “FIPS PUB 180-1”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips. - The
signal 480 is sent to thedevice 440, which triggers thedevice 440 to output theindicator 460. Thesignal 480 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by thesender 420, by theelectronic apparatus 430, or by another apparatus (not shown). Thedevice interface 452 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 420; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port. - The
device 440 also includes a set of predefined verification statuses each representing a relational correspondence between theverification data 450 and theprestored data 470. Verification statuses of the set further represent whether anindicator 460 has been output from the device since the last successful verification or since the last receipt of input representing verification data. The set also contains one additional predefined verification status representing the lack of input representingverification data 450 since a resetting after a timeout or a powering on of thedevice 440. Theindicator 460 output from thedevice 440 is based on the last comparison of theverification data 450 with theprestored data 470, but only if input representingverification data 450 has been received since the resetting of thedevice 440. Otherwise, theindicator 460 indicates the lack of input representingverification data 450 since the resetting of thedevice 440. In either case, theindicator 460 is transmitted with thedigital signature 482 therefor in association with theEC 410, whereby the recipient is able to identify theindicator 460 as relating to theEC 410. - The
electronic apparatus 430 includes an interface (not shown) capable of receiving theindicator 460 anddigital signature 482 fromdevice 440. Theelectronic apparatus 430 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on theindicator 460 and for evaluating theEC 410 received from thesender 420 based on the verification status of thedevice 440. Theelectronic apparatus 430 also decrypts thedigital signature 482 to confirm the authenticity of the indicator 460 (i.e., theelectronic apparatus 430 conducts Message Authentication with respect to the indicator 460). The decryption is performed using the public key, which corresponds to theprivate key 495 and which may be received in association with thedigital signature 482 or otherwise known or obtained beforehand by the recipient. - When the
verification data 450 and theprestored data 470 comprise a Secret, the predefined set of verification statuses includes at least four verification statuses, comprising: a first verification status representing the lack ofverification data 450 since a resetting of the device; a second verification status representing a match between theverification data 450 and theprestored data 470, and further representing noother indicator 460 being output from thedevice 440 since the match; a third verification status representing a failed match between theverification data 450 and theprestored data 470; and a fourth verification status representing a match between theverification data 450 and theprestored data 470, and further representing that anindicator 460 has been output since the match. Thedevice 440 preferably includes an identification marker (“IM”) 472 stored inmemory 474 and comprising one of four binary numbers that represents the current verification status identified by thedevice 440. The four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the ad first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status. Furthermore, theindicator 460 output from thedevice 440 preferably includes the value of theidentification marker 472, with the correspondence of the value with the predefined verification statuses of thedevice 440 being previously known by the recipient. None of the verification statuses actually reveal theverification data 450 or theprestored data 470; thus, no “shared secret” is required between thesender 420 and the recipient. However, the recipient can infer correct knowledge of the Secret from the verification status. - Alternatively, when the
verification data 450 and theprestored data 470 comprise biometric values, the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between theverification data 450 andprestored data 470, together with a verification status representing the lack of input representingverification data 450 since a resetting of thedevice 440. For example, the predefined verification statuses comprising the percentage match of theverification data 450 with theprestored data 470 may comprise the set of percentages ranging from 0% to 100% in increments of 1%. Each one of the verification statuses representing a percentage match also further represents whether anindicator 460 has been output from thedevice 440 since the last receipt of input representingverification data 450. Thedevice 440 preferably includes theidentification marker 472 for storing a value representing the verification status identified by thedevice 440 as the current verification status. Furthermore, theindicator 460 output from thedevice 440 preferably comprises the value of theidentification marker 472, and the correspondence of such value with the predefined verification statuses of the device is previously known by the recipient. Again, none of the verification statuses actually reveal either of theverification data 450 or theprestored data 470; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of thesender 420 from the reading of the biometric characteristic. - A variation based on the second
preferred embodiment 400 of FIG. 4a is shown in FIG. 4b, and includes an I/O support element 462 from which the input representing theverification data 450 is received at thedevice interface 452. The I/O support element 462 includes auser interface 458 from which input from thesender 420 is received and an I/O interface 459 that communicates the input representing theverification data 450 to thedevice 440. Yet an additional variation thereof is shown in FIG. 4c, wherein the I/O support element 462 receives theindicator 460 anddigital signature 482 therefor output from thedevice 440. The I/O support element 462, in turn, transmits theindicator 460 anddigital signature 482 to the externalelectronic apparatus 430. - As shown, the
indicator 460 transmitted from the I/O support element 462 is the same as theindicator 460 output from thedevice 440. However, the indicator transmitted from the I/O support element 462 may be different from the indicator output from thedevice 440, so long as the recipient is able to determine both the verification status as indicated by theindicator 460 output from thedevice 440, and the bit pattern of theindicator 460 for which the digital signature was originated by thedevice 440. For instance, the indicator transmitted from the I/O support element 462 may indicate not only the verification status of thedevice 440, but also a verification status of the I/O support element 462 when the I/O support element 462 itself identifies a verification status. Furthermore, theindicator 460 transmitted from the l/O support element 462 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 462. - Furthermore, in FIGS. 4a, 4 b, and 4 c, the
EC 410 is shown as being transmitted separate from theindicator 460 anddigital signature 482. However, in the preferred embodiment of FIG. 4a and any variations thereof, theindicator 460 anddigital signature 482 equally may be associated with theEC 410 by being transmitted as part of theEC 410. Furthermore, theEC 410 may be output from thedevice 440, an associated I/O support element 462 (not shown in FIG. 4a), or other apparatus. - A
preferred mode 500 of operation of the device of FIGS. 4a, 4 b, and 4 c is illustrated in FIG. 5 and begins with aresetting Step 504 of the device following a timeout or powering on of the device at 502. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input representing verification data and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 506 and ends at 512 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. The first step in the loop preferably includes thedetermination Step 508 whether any input representing verification data (VD) is received by the device. If the determination inStep 508 is positive, the current verification status (VS) of the device is identifiedStep 514 by comparing the verification data (VD) with the data prestored (PD) in memory of the device. The verification status identified then is recorded by assigning Step 516 a value to the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing verification data is received in
Step 508 or after the value of the identification marker has been assigned inStep 516, a determination is then made of whether a signal (S) has been or is being received by the device. If a signal is not received, then the loop restartsStep 506. When a signal is received, the determination inStep 510 is positive and a digital signature is originatedStep 518 for the indicator of the current verification status. The indicator and the digital signature therefor then areoutput Step 520. As set forth above, the indicator comprises the value of the identification marker maintained in memory within the device. Following the output of the indicator and digital signature, the determination is madeStep 522 whether the indicator output is the first indicator output since receipt of input representing verification data. The loop restartsStep 506 if the determination inStep 522 is negative. If the determination inStep 522 is positive, then the verification status is newly recorded by assigning Step 524 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data was received inStep 508. The loop then restartsStep 506. - 3. Third Preferred Embodiment (Digital Signature for Message)
- A third
preferred embodiment 600 of the present invention is illustrated in FIG. 6a, wherein anEC 610 including a message from asender 620 is received by a recipient represented by anelectronic apparatus 630, and wherein adevice 640 receives input representing verification data (VD) 650 at adevice interface 652. Thedevice 640 includes a verification component therein that maintains data (PD) 670 of thesender 620 prestored inmemory 654 of thedevice 640. Theverification data 650 andprestored data 670 represent Secret or biometric values. - The verification component identifies at656 a current verification status of the
device 640 based on a comparison of theverification data 650 with theprestored data 670. Upon receipt of a signal (S) 680, the last identified (i.e., “current”) verification status of thedevice 640 is communicated to the recipient by outputting from thedevice 640 anindicator 660 that then is transmitted to the recipient in association with theEC 610. Thesignal 680 is sent to thedevice 640, which triggers thedevice 640 to output theindicator 660. Thesignal 680 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by thesender 620, by theelectronic apparatus 630, or by another apparatus (not shown). Thedevice interface 652 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 620; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port. - The
device 640 receives at thedevice interface 652 data (MD) 622 representing the message of theEC 610. The message data may comprise the message itself, a message digest thereof, or the result of some other processing of the message (M). Thedevice 640 includes a digital signature component that, upon receipt of themessage data 622, originates a digital signature (DS) 686 for themessage data 622. Thedigital signature 686 is originated by calculating a hash value for themessage data 622 at 690 and then encrypting the hash value at 692 using aprivate key 695 of a public-private key pair. For increased reliability and trust, theprivate key 695 is retained securely withinmemory 694 so that it is never exported from thedevice 640 and is not discoverable from outside of thedevice 640. The digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 682 is generated using a random number generator, and the hash function at 690 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received. Thedigital signature 686 then is output from thedevice 640 and transmitted to the recipient with theindicator 660. - In alternative preferred embodiments, if the
message data 622 has already been hashed before it is received by thedevice 640, then the hash function is omitted. In such alternative embodiments, thedevice 640 is configured not to hash anymessage data 622 or not to hashmessage data 622 if a specific instruction, signal, or command is received. - The
device 640 also includes a set of predefined verification statuses each representing a relational correspondence between theverification data 650 and theprestored data 670. Verification statuses of the set further represent whether anindicator 660 has been output from thedevice 640 since the last successful verification or since the last receipt of input representing verification data. The set also contains one additional predefined verification status representing the lack of input representingverification data 650 since a resetting after a timeout or a powering on of thedevice 640. Theindicator 660 output from thedevice 640 is based on the last comparison of theverification data 650 with theprestored data 670, but only if input representingverification data 650 has been received since the resetting of thedevice 640. Otherwise, theindicator 660 indicates the lack of input representingverification data 650 since the resetting of thedevice 640. - In either case, the
indicator 660 is transmitted with thedigital signature 686 in association with theEC 610, whereby the recipient is able to identify theindicator 660 anddigital signature 686 as relating to theEC 610. Theelectronic apparatus 630 includes an interface (not shown) capable of receiving theindicator 660 anddigital signature 686 from thedevice 640. Theelectronic apparatus 630 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on the indicator, and for evaluating theEC 610 received from thesender 620 based on the determined verification status. Theelectronic apparatus 630 also decrypts thedigital signature 686 to confirm the authenticity of the message of theEC 610. The decryption is performed with the public key, which corresponds with theprivate key 695 and which may be received in association with thedigital signature 686 or known or obtained beforehand by the recipient. Of course, in calculating a hash value for comparison, theelectronic apparatus 630 performs any necessary processing to the message in order to produce the message data for which the digital signature was originated. - When the
verification data 650 and theprestored data 670 comprise a Secret, the predefined set of verification statuses includes at least four verification statuses, comprising: a first verification status representing the lack ofverification data 650 since a resetting of the device; a second verification status representing a match between theverification data 650 and theprestored data 670, and further representing noother indicator 660 being output from thedevice 640 since the match; a third verification status representing a failed match between theverification data 650 and theprestored data 670; and a fourth verification status representing a match between theverification data 650 and theprestored data 670, and further representing that anindicator 660 has been output since the match. Thedevice 640 preferably includes an identification marker (“IM”) 672 stored inmemory 674 and comprising one of four binary numbers that represents the current verification status identified by thedevice 640. The four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status. Furthermore, theindicator 660 output from thedevice 640 preferably includes the value of theidentification marker 672, with the correspondence of the value with the predefined verification statuses of the device being previously known by the recipient. None of the verification statuses actually reveal theverification data 650 or theprestored data 670; thus, no “shared secret” is required between thesender 620 and the recipient. However, the recipient can infer correct knowledge of the Secret from the verification status. - Alternatively, when the
verification data 650 and theprestored data 670 comprise biometric values, the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between theverification data 650 andprestored data 670, together with a verification status representing the lack of input representingverification data 650 since a resetting of thedevice 640. For example, the predefined verification statuses comprising the percentage match of theverification data 650 with theprestored data 670 may comprise the set of percentages ranging from 0% to 100% in increments of 1%. Preferably each one of the verification statuses representing a percentage match also further represents whether anindicator 660 has been output from thedevice 640 since the last receipt of input representingverification data 650. Thedevice 640 preferably includes theidentification marker 672 for storing a value representing the verification status identified by thedevice 640 as the current verification status. Furthermore, theindicator 660 output from thedevice 640 preferably comprises the value of theidentification marker 672, with the correspondence of such value with the predefined verification statuses of the device being previously known by the recipient. Again, none of the verification statuses actually reveal either of theverification data 650 or theprestored data 670; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of the sender from the reading of the biometric characteristic. - A variation based on the third
preferred embodiment 600 of FIG. 6a is shown in FIG. 6b, and includes an I/O support element 662 from which input representing theverification data 650 and input representing themessage data 622 are received by thedevice 640. The I/O support element 662 includes auser interface 658 from which input from thesender 620 is received and an I/O interface 659 that communicates the input representing theverification data 650 and input representing themessage data 622 to thedevice 640. Although themessage data 622 is shown coming from the I/O support element 662, it is possible for some or all of themessage data 622 to be composed within thedevice 640 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG. 6c, wherein the I/O support element 662 receives theindicator 660 anddigital signature 686 output from thedevice 640. The I/O support element 662, in turn, transmits theindicator 660 and thedigital signature 686 to theelectronic apparatus 630. - As shown, the
indicator 660 anddigital signature 686 transmitted from the I/O support element 662 are the same as theindicator 660 anddigital signature 686 output from thedevice 640. However, the indicator transmitted from the I/O support element 662 may be different from the indicator output from thedevice 640, so long as the recipient is able to determine the verification status as indicated by theindicator 660 output from thedevice 640. For instance, the indicator transmitted from the I/O support element 662 may indicate not only the verification status of thedevice 640, but also a verification status of the I/O support element 662 when the I/O support element 662 itself identifies a verification status. Furthermore, theindicator 660 anddigital signature 686 transmitted from the I/O support element 662 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 662. - Furthermore, in FIGS. 6a, 6 b, and 6 c, the
EC 610 is shown as being transmitted separate from theindicator 660 anddigital signature 686. However, in the preferred embodiment of FIG. 6a and any variations thereof, theindicator 660 anddigital signature 686 equally may be associated with theEC 610 by being transmitted as part of theEC 610. Furthermore, theEC 610 may be output from thedevice 640, an associated I/O support element 662 (not shown in FIG. 6a), or other apparatus. - A
preferred mode 700 of operation of the device of FIGS. 6a, 6 b, and 6 c is illustrated in FIG. 7 and begins with aresetting Step 704 of the device following a timeout or powering on of the device at 702. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input representing verification data and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 706 and ends at 714 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. The first step in the loop preferably includes thedetermination Step 708 whether any input representing verification data (VD) is received by the device. If the determination inStep 708 is positive, the current verification status (VS) of the device is identifiedStep 716 by comparing the verification data (VD) with the data prestored (PD) in memory of the device. The verification status identified then is recorded by assigning Step 718 a value to the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing verification data is received in
Step 708 or after the value of the identification marker is recorded inStep 718, the next step in the loop preferably includes thedetermination Step 710 whether any input representing message data (MD) is received by the device. If the determination inStep 710 is positive, the device originates Step 720 a digital signature for the message data. The digital signature for the message data is thenoutput Step 722 from the device. - If no input representing message data is received in
Step 710 or after the digital signature for the message data is output inStep 722, a determination is then made of whether a signal (S) has been or is being received by the device. If a signal is not received, then the loop restartsStep 706. When a signal is received, the determination inStep 712 is positive and the indicator of the current verification status of the device isoutput Step 724. As set forth above, the indicator comprises the value of the identification marker maintained in memory within the device. Following the output of the indicator, the determination is madeStep 726 whether the indicator output is the first indicator output since receipt of input representing verification data. The loop restartsStep 706 if the determination inStep 726 is negative. If the determination inStep 726 is positive, then the verification status is newly recorded by assigning Step 728 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data was received inStep 708. The loop then restartsStep 706. - 4. Fourth Preferred Embodiment (Digital Signature for Prestored Message)
- A fourth
preferred embodiment 800 of the present invention is illustrated in FIG. 8a, wherein adevice 840 includes message data (MD) 822 representing a predefined message that is maintained in memory of thedevice 840. Furthermore, it is preferred that the content of the predefined message be known in advance by the recipient, whereby the message is implicitly received by the recipient in the act of receiving adigital signature 886 for themessage data 822. However, in the event that the recipient does not have knowledge of the predefined message, thedevice 840 preferably includes the option of exporting themessage data 822 for communication to the recipient as shown by the dotted line in FIG. 8a. - The
device 840 includes a digital signature component that, upon receipt of a signal (SI) 898 at thedevice interface 852, originates thedigital signature 886 for themessage data 822 by calculating a hash value therefor at 890 and then encrypting the hash value at 892 using aprivate key 895 of a public-private key pair, and then outputs thedigital signature 886 for transmitting to the recipient. For increased reliability and trust, theprivate key 895 is retained securely withinmemory 894 so that it is never exported from thedevice 840 and is not discoverable from outside of thedevice 840. The digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 882 is generated using a random number generator, and the hash function at 890 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received. - The
signal 898 represents, for example, a request or command generated by thesender 820 for the communication of thedigital signature 886 to the recipient or, alternatively, thesignal 898 may simply comprise the receipt from thesender 820 of input representingverification data 850 by thedevice 840. In this regard, thedevice 840 receives input representing verification data (VD) 850 at adevice interface 852. Thedevice 840 includes a verification component therein that maintains data (PD) 870 of thesender 820 prestored inmemory 854 of thedevice 840. Theverification data 850 andprestored data 870 represent Secret or biometric values. The verification component of thedevice 840 identifies at 856 a current verification status of thedevice 840 based on a comparison of theverification data 850 with theprestored data 870. - Upon receipt of a signal (S2) 880, the last identified (i.e., “current”) verification status of the
device 840 is communicated to the recipient by outputting from thedevice 840 an indicator (IVS) 860 that then is transmitted to the recipient in association with thedigital signature 886. Thesignal 880 is sent to thedevice 840, which triggers thedevice 840 to output theindicator 860. Thesignal 880 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by thesender 820, by theelectronic apparatus 830, or by another apparatus (not shown). Alternatively, thesignal 880 may comprise the receipt of the input representing theverification data 850 itself; thus, it is possible for signal (S1) 898 and signal (S2) 880 to be the same signal. - The
device interface 852 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 820; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port. - The
device 840 includes a set of predefined verification statuses each representing a relational correspondence between theverification data 850 and theprestored data 870. Verification statuses of the set further represent whether anindicator 860 has been output from thedevice 840 since the last successful verification or since the last receipt of input representingverification data 850. The set also contains one additional predefined verification status representing the lack of input representingverification data 850 since a resetting after a timeout or a powering on of thedevice 840. Theindicator 860 output from thedevice 840 is based on the last comparison of theverification data 850 with theprestored data 870, but only if input representingverification data 850 has been received since the resetting of thedevice 840. Otherwise, theindicator 860 indicates the lack of input representingverification data 850 since the resetting of thedevice 840. - In either case, the
indicator 860 is transmitted with thedigital signature 886, whereby the recipient is able to identify theindicator 860 as relating to thedigital signature 686. Theelectronic apparatus 830 includes an interface (not shown) capable of receiving theindicator 860 anddigital signature 886. Theelectronic apparatus 830 also includes logic circuitry or software incorporating business logic therein for determining the verification status of thedevice 840 based on theindicator 860, and for evaluating the implicit (or explicit) message received from thesender 820 based on the determined verification status. Theelectronic apparatus 830 also decrypts thedigital signature 886 to confirm the authenticity of the message. The decryption is performed with the public key, which corresponds with theprivate key 895 and which may be received in association with thedigital signature 886 or known or obtained beforehand by the recipient. - When the
verification data 850 and theprestored data 870 comprise a Secret, the predefined set of verification statuses includes at least four verification statuses, comprising: a first verification status representing the lack ofverification data 850 since a resetting of the device; a second verification status representing a match between theverification data 850 and theprestored data 870, and further representing noother indicator 860 being output from thedevice 840 since the match; a third verification status representing a failed match between theverification data 850 and theprestored data 870; and a fourth verification status representing a match between theverification data 850 and theprestored data 870, and further representing the output of anindicator 860 since the match. Thedevice 840 preferably includes an identification marker (“IM”) 872 stored inmemory 874 and comprising one of four binary numbers that represents the current verification status identified by thedevice 840. The four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status. Furthermore, theindicator 860 output from thedevice 840 preferably includes the value of theidentification marker 872, with the correspondence of the value with the predefined verification statuses of the device being previously known by the recipient. None of the verification statuses actually reveal theverification data 850 or theprestored data 870; thus there is no “shared secret” between thesender 820 and the recipient. However, the recipient can infer correct knowledge of the Secret from the verification status. - Alternatively, when the
verification data 850 and theprestored data 870 comprise biometric values, the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between theverification data 850 andprestored data 870, together with a verification status representing the lack of input representingverification data 850 since a resetting of thedevice 840. For example, the predefined verification statuses comprising the percentage match of theverification data 850 with theprestored data 870 may comprise the set of percentages ranging from 0% to 100% in increments of 1%. Preferably each one of the verification statuses representing a percentage match also further represents whether anindicator 860 has been output from thedevice 840 since the last receipt of input representingverification data 850. Thedevice 840 preferably includes theidentification marker 872 for storing a value representing the verification status identified by thedevice 840 as the current verification status. Furthermore, theindicator 860 output from thedevice 840 preferably comprises the value of theidentification marker 872, and the correspondence of such value with the predefined verification statuses of the device is previously known by the recipient. Again, none of the verification statuses actually reveal either of theverification data 850 or theprestored data 870; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of the sender from the reading of the biometric characteristic. - A variation based on the fourth
preferred embodiment 800 of FIG. 8a is shown in FIG. 8b, and includes an I/O support element 862 from which input representing theverification data 850 is received by thedevice 840. The I/O support element 862 includes auser interface 858 from which input from thesender 820 is received and an I/O interface 859 that communicates the input representing theverification data 850 to thedevice 840. Yet an additional variation thereof is shown in FIG. 8c, wherein the I/O support element 862 receives theindicator 860 and digital signature 886 (and optionally the message data 822) output from thedevice 840. The I/O support element 862, in turn, transmits theindicator 860 and the digital signature 886 (and optionally the message data 822) to theelectronic apparatus 830. - As shown, the
indicator 860 anddigital signature 886 transmitted from the I/O support element 862 are the same as theindicator 860 anddigital signature 886 output from thedevice 840. However, the indicator transmitted from the I/O support element 862 may be different from the indicator output from thedevice 840, so long as the recipient is able to determine the verification status as indicated by theindicator 860 output from thedevice 840. For instance, the indicator transmitted from the I/O support element 862 may indicate not only the verification status of thedevice 840, but also a verification status of the I/O support element 862 when the I/O support element 862 itself identifies a verification status. Furthermore, theindicator 860 anddigital signature 886 transmitted from the I/O support element 862 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 862. - A further variation based on the fourth
preferred embodiment 800 of FIG. 8a is shown in FIG. 8d, in which themessage data 822 stored in thedevice 840 is a calculated hash value of the predefined message. In this case, thedevice 840 generates adigital signature 886 for the predefined message by directly encrypting themessage data 822 at 892, and thecomponent 890 for calculating the hash value in FIG. 8a is omitted from the device of FIG. 8d. In this example, it is assumed that the recipient knows the predefined message corresponding to themessage data 822 stored within thedevice 840; thus, there is no need to communicate the message (or message data 822) from thedevice 840 to the recipient. - A
preferred mode 900 of operation of the device of FIGS. 8a, 8 b, 8 c, and 8 d is illustrated in FIG. 9 and begins with a resetting Step 904 of the device following a timeout or powering on of the device at 902. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input representing verification data and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 906 and ends at 914 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. The first step in the loop preferably includes thedetermination Step 908 whether any input representing verification data (VD) is received by the device. If the determination inStep 908 is positive, the current verification status (VS) of the device is identifiedStep 916 by comparing the verification data (VD) with the data prestored (PD) in memory of the device. The verification status identified then is recorded by assigning Step 918 a value to the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing verification data is received in
Step 908 or after the value of the identification marker is recorded inStep 918, the next step in the loop preferably includes thedetermination Step 910 whether any signal S1 is received by the device. If the determination inStep 910 is positive, the device originates Step 920 (or generates, as applicable) a digital signature for the predefined message data. The digital signature for the predefined message data is thenoutput Step 922 from the device. If signal S1 is not received inStep 910 or after the digital signature for the predefined message data is output inStep 922, a determination is then made of whether a signal S2 has been or is being received by the device. If a signal S2 is not received, then the loop restartsStep 906. When a signal S2 is received, the determination inStep 912 is positive and the indicator of the current verification status of the device isoutput Step 924. As set forth above, the indicator comprises the value of the identification marker maintained in memory within the device. Following the output of the indicator, the determination is madeStep 926 whether the indicator output is the first indicator output since receipt of input representing verification data. The loop restartsStep 906 if the determination inStep 926 is negative. If the determination inStep 926 is positive, then the verification status is newly recorded by assigning Step 928 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data was received inStep 908. The loop then restartsStep 906. - 5. Fifth Preferred Embodiment (Secret and Biometric Verification Data)
- A fifth
preferred embodiment 1000 of the present invention is illustrated in FIG. 10a, wherein anEC 1010 including a message from asender 1020 is received by a recipient represented by anelectronic apparatus 1030, and wherein adevice 1040 receives input representing verification data for a Secret (SVD) 1051 and input representing verification data for a biometric characteristic (BVD) 1053 at adevice interface 1052. Thedevice 1040 includes a verification component therein that maintains data of thesender 1020 prestored in memory of thedevice 1040. The prestored data (SPD) 1042 is located inmemory 1041 and comprises a value for a Secret, and the prestored data (BPD) 1044 is located inmemory 1043 and comprises a value for a biometric characteristic. - The verification component identifies at1056 a current verification status of the
device 1040 based on respective comparisons of theverification data prestored data device 1040 is communicated to the recipient by outputting from thedevice 1040 anindicator 1060 that is transmitted to the recipient in association with theEC 1010. Thesignal 1080 is sent to thedevice 1040, which triggers thedevice 1040 to output theindicator 1060. Thesignal 1080 represents, for example, a request or command for the provision of the verification status to the recipient and is generated by thesender 1020, by theelectronic apparatus 1030, or by another apparatus (not shown). Thedevice interface 1052 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 1020; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port. - The
device 1040 also receives at thedevice interface 1052 data (MD) 1022 representing the message of theEC 1010. Themessage data 1022 may comprise the message (M) itself, a message digest thereof, or the result of some other processing of the message. Thedevice 1040 includes a digital signature component that, upon receipt of themessage data 1022, originates a digital signature (DS) 1086 for themessage data 1022 by calculating a hash value therefor at 1090 and then encrypting the hash value at 1092 using aprivate key 1095 of a public-private key pair. For increased reliability and trust, theprivate key 1095 is retained securely withinmemory 1094 so that it is never exported from thedevice 1040 and is not discoverable from outside of thedevice 1040. Thedigital signature 1086 then is output from thedevice 1040 and transmitted to the recipient with theindicator 1060. The digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, the digital signature 1082 is generated using a random number generator, and the hash function at 1090 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received. - In alternative preferred embodiments, if the
message data 1022 has already been hashed before it is received by thedevice 1040, then the hash function is omitted. In such alternative embodiments, thedevice 1040 is configured not to hash anymessage data 1022 or not to hashmessage data 1022 if a specific instruction, signal, or command is received. - The
device 1040 also includes a set of predefined verification statuses each representing a relational correspondence between theverification data prestored data indicator 1060 has been output from thedevice 1040 since the last successful verification or since the last receipt of input representing verification data. The set also contains one additional predefined verification status representing the lack of input representingverification data 1051 since a resetting after a timeout or a powering on of thedevice 1040, and one predefined verification status representing the lack of input representingverification data 1053 since a resetting after a timeout or a powering on of thedevice 1040. Theindicator 1060 output from thedevice 1040 is based on the last comparison of each of verification data 1051 (if received) withprestored data 1042 and of verification data 1053 (if received) withprestored data 1044. Otherwise, theindicator 1060 indicates the lack of input representingverification data device 1040. - In either case, the
indicator 1060 is transmitted with thedigital signature 1086 in association with theEC 1010, whereby the recipient is able to identify theindicator 1060 anddigital signature 1086 as relating to theEC 1010. Theelectronic apparatus 1030 includes an interface (not shown) capable of receiving theindicator 1060 anddigital signature 1086. Theelectronic apparatus 1030 also includes logic circuitry or software incorporating business logic therein for determining the verification status of thedevice 1040 based on theindicator 1060, and for evaluating theEC 1010 received from thesender 1020 based on the determined verification status. Theelectronic apparatus 1030 also decrypts thedigital signature 1086 to confirm the authenticity of the message of theEC 1010. The decryption is performed with the public key, which corresponds with theprivate key 1095 and which may be received in association with thedigital signature 1086 or known or obtained beforehand by the recipient. In calculating a hash value for comparison, theelectronic apparatus 1030 also performs any necessary processing to the message in order to produce the message digest for which the digital signature was originated. -
Verification data 1051 andprestored data 1042 represent a Secret, and a comparison ofverification data 1051 received with theprestored data 1042 produces a result preferably out of four possible outcomes, including: a first outcome representing the lack of verification data 1050 since a resetting of thedevice 1040; a second outcome representing a match between theverification data 1051 and theprestored data 1042, and further representing noother indicator 1060 being output from thedevice 1040 since the match; a third outcome representing a failed match between theverification data 1051 and theprestored data 1042; and a fourth outcome representing a match between theverification data 1051 and theprestored data 1042, and further representing the output of anindicator 1060 since the match. -
Verification data 1053 andprestored data 1044 represent a biometric characteristic, and a comparison ofverification data 1053 received with theprestored data 1044 produces a result preferably out of a predefined number of possible outcomes. Each outcome represents a possible percentage of match—or degree of difference—between theverification data 1053 andprestored data 1044 that is allowed, together with a verification status representing the lack of input forverification data 1053 since a resetting of thedevice 1040. For example, the predefined outcomes comprising the percentage match of theverification data 1053 with theprestored data 1044 may comprise the set of percentages ranging from 0% to 100% in increments of 1%. Preferably each one of the outcomes representing a percentage match also further represents whether anindicator 1060 has been output from thedevice 1040 since the last receipt of input representingverification data 1053. - The
device 1040 preferably includes an identification marker (“IM”) 1072 stored inmemory 1074 and comprising one of the set of predefined verification statuses of the device. The set of predefined verification statuses preferably comprises all of the possible combinations of outcomes from the comparison of theverification data 1051 with theprestored data 1042 in addition to all of the possible outcomes from the comparison of theverification data 1053 with theprestored data 1044. Furthermore, theindicator 1060 output from thedevice 1040 preferably includes the value of theidentification marker 1072, with the correspondence of the value of the identification marker with the predefined verification statuses of thedevice 1040 being previously known by the recipient. None of the verification statuses actually reveal any of theverification data prestored data sender 1020 and the recipient, and no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer correct knowledge of the Secret and correct input of a biometric value from the verification status. - A variation based on the fifth
preferred embodiment 1000 of FIG. 10a is shown in FIG. 10b, and includes an I/O support element 1062 from which input representing theverification data message data 1022 is received by thedevice 1040. The I/O support element 1062 includes auser interface 1058 from which input from thesender 1020 is received and an I/O interface 1059 that communicates the input representing theverification data device 1040. Although themessage data 1022 is shown coming from the I/O support element 1062, it is possible for some or all of themessage data 1022 to originate with thedevice 1040 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG. 10c, wherein the I/O support element 1062 receives theindicator 1060 anddigital signature 1086 output from thedevice 1040. The I/O support element 1062, in turn, transmits theindicator 1060 and thedigital signature 1086 to theelectronic apparatus 1030. - As shown, the
indicator 1060 anddigital signature 1086 transmitted from the I/O support element 1062 are the same as theindicator 1060 anddigital signature 1086 output from thedevice 1040. However, the indicator transmitted from the I/O support element 1062 may be different from the indicator output from thedevice 1040, so long as the recipient is able to determine the verification status as indicated by theindicator 1060 output from thedevice 1040. For instance, the indicator transmitted from the I/O support element 1062 may indicate not only the verification status of thedevice 1040, but also a verification status of the I/O support element 1062 when the I/O support element 1062 itself identifies a verification status. Furthermore, theindicator 1060 anddigital signature 1086 transmitted from the I/O support element 1062 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 1062. - Furthermore, in FIGS. 10a, 10 b, and 10 c, the
EC 1010 is shown as being transmitted separate from theindicator 1060 anddigital signature 1086. However, in the preferred embodiment of FIG. 10a and any variations thereof, theindicator 1060 anddigital signature 1086 equally may be associated with theEC 1010 by being transmitted as part of theEC 1010. Furthermore, theEC 1010 may be output from thedevice 1040, an associated I/O support element 1062 (not shown in FIG. 10a), or other apparatus. - A preferred
mode 1100 of operation of the device of FIGS. 10a, 10 b, and 10 c is illustrated in FIG. 11 and begins with aresetting Step 1104 of the device following a timeout or powering on of the device at 1102. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input for verification data for either a Secret or a biometric characteristic and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 1106 and ends at 1116 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. - Still referring to FIG. 11, the first step in the loop preferably includes the
determination Step 1108 whether any input representing verification data for the Secret (SVD) is received by the device. If the determination inStep 1108 is positive, the current verification status (VS) of the device is identifiedStep 1118 by comparing the Secret verification data (SVD) with the data for the Secret (SPD) prestored in the memory of the device. The verification status identified then is recorded by assigningStep 1120 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing verification data for the Secret is received in
Step 1108 or after the value of the identification marker is assigned inStep 1120, the next step in the loop preferably includes thedetermination Step 1110 whether any input representing verification data for the biometric characteristic (BVD) is received by the device. If the determination inStep 1110 is positive, the current verification status (VS) of the device is identifiedStep 1122 by comparing the biometric verification data (BVD) with the biometric data (BPD) prestored in the memory of the device. The verification status identified then is recorded by assigningStep 1124 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing verification data for the biometric characteristic is received in
Step 1110 or after the value of the identification marker is recorded inStep 1124, the next step in the loop preferably includes thedetermination Step 1112 whether any input representing message data (MD) is received by the device. If the determination inStep 1112 is positive, the device originates Step 1126 a digital signature for the message data. The digital signature for the message data is thenoutput Step 1128 from the device. - If no input representing message data is received in
Step 1112 or after the digital signature for the message data is output inStep 1128, a determination is then madeStep 1114 of whether a signal (S) has been or is being received by the device. If a signal is not received, then the loop restartsStep 1106. When a signal is received, the determination inStep 1114 is positive and the indicator of the current verification status of the device isoutput Step 1130. As set forth above, the indicator comprises the value of the identification marker maintained in memory within the device. Following the output of the indicator, the determination is madeStep 1132 whether the indicator output is the first indicator output since receipt of input representing verification data for the Secret. - If the determination in
Step 1132 is positive, then the verification status is newly recorded by assigning Step 1136 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data for the Secret was received inStep 1108. If the determination inStep 1132 is negative or after the value of the identification marker is newly recorded inStep 1136, the determination is madeStep 1134 whether the indicator output is the first indicator output since receipt of input representing verification data for the biometric characteristic. - If the determination in
Step 1134 is positive, then the verification status is newly recorded by assigning Step 1138 a value to the identification marker that further represents the fact that an indicator has been output since input representing verification data for the biometric characteristic was received inStep 1110. If the determination inStep 1134 is negative or after the value of the identification marker is newly recorded inStep 1138, then the loop restartsStep 1106. - 6. Sixth Preferred Embodiment (Digital Signature as the Indicator)
- A sixth
preferred embodiment 1200 of the present invention is illustrated in FIG. 12a, wherein anEC 1210 including a message from asender 1220 is received by a recipient represented by anelectronic apparatus 1230, and wherein adevice 1240 receives input representing verification data (VD) 1250 at adevice interface 1252. Thedevice interface 1252 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 1220; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port. - The
device 1240 includes a verification component therein that maintains data (PD) 1270 of thesender 1220 prestored inmemory 1254. Theverification data 1250 andprestored data 1270 represent Secret or biometric values. The verification component identifies at 1256 a current verification status of thedevice 1240 based on a comparison of theverification data 1250 with theprestored data 1270 and records the last identified (i.e., “current”) verification status of thedevice 1240 by assigning a value to an identification marker (IM) 1272 that is stored inmemory 1274. - The
device 1240 also receives at thedevice interface 1252 data (MD) 1222 representing the message of theEC 1210. The message data may comprise the message itself, a message digest thereof, or the result of some other processing of the message (M). Thedevice 1240 includes a digital signature component that, upon receipt of themessage data 1222, obtains the value for theidentification marker 1272 and modifies the message data at 1277 as a function of this value (as used herein, “function” may include the possible function f(x)=x for a particular value of x). - The digital signature component then originates a
digital signature 1299 for the modified message data (MD′) by calculating a hash value therefor at 1290 and then encrypting the hash value at 1292 using aprivate key 1295 of a public-private key pair. For increased reliability and trust, theprivate key 1295 is retained securely withinmemory 1294 so that it is never exported from thedevice 1240 and is not discoverable from outside of thedevice 1240. The digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, thedigital signature 1299 is generated using a random number generator, and the hash function at 1290 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received. Thedigital signature 1299 then is output from thedevice 1240 for transmitting to the recipient as theindicator 1260 of the verification status of thedevice 1240. Thedigital signature 1299 output from thedevice 1240 actually comprises the indicator of the verification status (IVS) 1260 as a result of the modification process. Theindicator 1260 then is transmitted to the recipient in association with theEC 1210, whereby the recipient is able to identify theindicator 1260 as pertaining to theEC 1210. - The
device 1240 includes a set of predefined verification statuses each representing a relational correspondence between theverification data 1250 and theprestored data 1270. Verification statuses of the set further represent whether anindicator 1260 has been output from thedevice 1240 since the last successful verification or since the last receipt of input representing verification data. The set also contains an additional predefined verification status representing the lack of input representingverification data 1250 since a resetting after a timeout or a powering on of thedevice 1240. Theindicator 1260 output from thedevice 1240 is based on the last comparison of theverification data 1250 with theprestored data 1270, but only if input representingverification data 1250 has been received since the resetting of thedevice 1240. Otherwise, theindicator 1260 indicates the lack of input representingverification data 1250 since the resetting of thedevice 1240. - The
electronic apparatus 1230 includes an interface (not shown) capable of receiving theindicator 1260. Theelectronic apparatus 1230 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on theindicator 1260 and for evaluating theEC 1210 received from thesender 1220 based on the determined verification status. In this regard, theelectronic apparatus 1230 decrypts the digital signature with the public key, which corresponds to theprivate key 1295 and which may be received in association with the digital signature or known or obtained beforehand by the recipient. The recipient also modifies—and then calculates a hash value for—the message for each one of the predefined verification statuses of the device until the calculated hash value equals the hash value of the decrypted digital signature. In calculating a hash value for comparison, theelectronic apparatus 1230 also performs any necessary processing to the message in order to produce the message data that was modified within thedevice 1240. When the hash value calculated by the recipient equals the hash value of the decrypted digital signature, the recipient thereby determines the current verification status of thedevice 1240. This determination also confirms the authenticity of the message of theEC 1210. Furthermore, in order to minimize consumption of resources, the set of verification statuses of the device is predefined to contain only a limited number of verification statuses when thisparticular device 1240 of thepreferred embodiment 1200 is used. - When the
verification data 1250 and theprestored data 1270 comprise a Secret, the predefined set of verification statuses includes four verification statuses, comprising: a first verification status representing the lack ofverification data 1250 since a resetting of the device; a second verification status representing a match between theverification data 1250 and theprestored data 1270, and further representing noother indicator 1260 being output from thedevice 1240 since the match; a third verification status representing a failed match between theverification data 1250 and theprestored data 1270; and a fourth verification status representing a match between theverification data 1250 and theprestored data 1270, and further representing the output of anindicator 1260 since the match. Theidentification marker 1272 stored inmemory 1274 preferably comprises one of four binary numbers that represents the current verification status identified by thedevice 1240. Of course, the correspondence between the values of theidentification marker 1272 and the predefined verification statuses of the device should be previously known by the recipient. - The four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status. Furthermore, the modification of the
message data 1222 at 1277 preferably includes the embedding of the value of theidentification marker 1272 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data. As also will be appreciated, the “modification” of the message data for one of the verification statuses may include not modifying the message data, such as when theidentification marker 1272 equals “00.” Even in this case, however, thedigital signature 1299 identifies the verification status of the device as representing the lack ofverification data 1250 being received since a resetting of the device. Furthermore, it will be appreciated that thedigital signature 1299 for the modified message neither reveals theverification data 1250 nor theprestored data 1270; thus, no “shared secret” is required between the sender and the recipient in thepreferred embodiment 1200. However, the recipient can infer correct knowledge of the Secret from the verification status. - Alternatively, when the
verification data 1250 and theprestored data 1270 comprise biometric values, the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between theverification data 1250 andprestored data 1270, together with a verification status representing the lack of input representingverification data 1250 since a resetting of thedevice 1240. For example, the predefined verification statuses comprising the percentage match of theverification data 1250 with theprestored data 1270 may comprise the set of percentages ranging from 0% to 100% in increments of, in this embodiment, 20%. Preferably each one of the verification statuses representing a percentage match also further represents whether anindicator 1260 has been output from thedevice 1240 since the last receipt of input representingverification data 1250. Theidentification marker 1272 stored inmemory 1274 preferably comprises the percentage match plus a flag regarding the output of theindicator 1260 as identified by thedevice 1240. Of course, the correspondence between the values of theidentification marker 1272 and the predefined verification statuses of thedevice 1240 should be previously known by the recipient. Also, in this case, the modification of themessage data 1222 at 1277 preferably includes the embedding of the value of theidentification marker 1272 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data. As also will be appreciated, the “modification” of the message data for one of the verification statuses may include not modifying the message data, such as when noverification data 1250 has been received since a resetting of thedevice 1240. Even in this case, however, thedigital signature 1299 identifies the verification status of thedevice 1240 as representing the lack ofverification data 1250 being received since a resetting of thedevice 1240. Furthermore, it will be appreciated that thedigital signature 1299 for the modified message neither reveals theverification data 1250 nor theprestored data 1270; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of thesender 1220 from the reading of the biometric characteristic. - A variation based on the sixth
preferred embodiment 1200 of FIG. 12a is shown in FIG. 12b, and includes an I/O support element 1262 from which input representing theverification data 1250 and input representing themessage data 1222 is received by thedevice 1240. The I/O support element 1262 includes auser interface 1258 from which input from thesender 1220 is received and an I/O interface 1259 that communicates the input representing theverification data 1250 and input representing themessage data 1222 to thedevice 1240. Although themessage data 1222 is shown coming from the I/O support element 1262, it is possible for some or all of themessage data 1222 to originate with thedevice 1240 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG. 12c, wherein the I/O support element 1262 receives theindicator 1260 being output from thedevice 1240. The I/O support element 1262, in turn, transmits theindicator 1260 to theelectronic apparatus 1230. As shown, theindicator 1260 transmitted from the I/O support element 1262 is the same as theindicator 1260 output from thedevice 1240. However, theindicator 1260 transmitted from the I/O support element 1262 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 1262.Furthermore, in FIGS. 12a, 12 b, and 12 c, theEC 1210 is shown as being transmitted separate from theindicator 1260. However, in the preferred embodiment of FIG. 12a and any variations thereof, theindicator 1260 equally may be associated with theEC 1210 by being transmitted as part of theEC 1210. Furthermore, theEC 1210 may be output from thedevice 1240, an associated I/O support element 1262 (not shown in FIG. 12a), or other apparatus. - A preferred
mode 1300 of operation of the device of FIGS. 12a, 12 b, and 12 c is illustrated in FIG. 13 and begins with a resetting Step 1304 of the device following a timeout or powering on of the device at 1302. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input of verification data and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 1306 and ends at 1312 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. - Still referring to FIG. 13, the first step in the loop preferably includes the
determination Step 1308 whether any input representing verification data is received by the device. If the determination inStep 1308 is positive, the current verification status (VS) of the device is identifiedStep 1314 by comparing the verification data (VD) with the data (PD) prestored in the memory of the device. The verification status identified then is recorded by assigningStep 1316 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing verification data is received in
Step 1308 or after the value of the identification marker is recorded inStep 1316, the next step in the loop preferably includes thedetermination Step 1310 whether any input representing message data (MD) is received by the device. If the determination inStep 1310 is negative, the loop restartsStep 1306. - If the determination in
Step 1310 is positive, the device then modifiesStep 1318 the message data based on the identification marker. Next, the device originates Step 1320 a digital signature for the modified message data. The digital signature for the modified message data is thenoutput Step 1322 from the device. Following the output of the digital signature for the modified message, the determination is madeStep 1324 whether the digital signature output is the first digital signature output since receipt of input for verification data inStep 1308. The loop restartsStep 1306 if the determination inStep 1324 is negative. If the determination inStep 1324 is positive, then the verification status is newly recordedStep 1326 by assigning a value to the identification marker that represents the verification status indicated by the digital signature output inStep 1322, and that further represents the fact that the digital signature has been output. The loop then restartsStep 1306. - 7. Seventh Preferred Embodiment (Message and Indicator Digitally Signed)
- A seventh
preferred embodiment 1400 of the present invention is illustrated in FIG. 14a, wherein anEC 1410 including a message from asender 1420 is received by a recipient represented by anelectronic apparatus 1430, and wherein adevice 1440 receives input representing verification data (VD) 1450 at adevice interface 1452. Thedevice interface 1452 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 1420; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port. - The
device 1440 includes a verification component therein that maintains data (PD) 1470 of thesender 1420 prestored inmemory 1454. Theverification data 1450 andprestored data 1470 represent Secret or biometric values. The verification component identifies at 1456 a current verification status of thedevice 1440 based on a comparison of theverification data 1450 with theprestored data 1470 and records the last identified (i.e., “current”) verification status of thedevice 1440 by assigning a value to an identification marker (IM) 1472 that is stored inmemory 1474. - The
device 1440 also receives at thedevice interface 1452 message data (MD) 1422 representing the message (M) of theEC 1410. Themessage data 1422 may comprise the message itself, a message digest thereof, or the result of some other processing of the message. Thedevice 1440 includes a digital signature component that, upon receipt of themessage data 1422, obtains the value for theidentification marker 1472 and modifies the message data at 1477 as a function of this value (as used herein, “function” may include the possible function f(x)=x for a particular value of x). The digital signature component then originates adigital signature 1499 for the modified message data (MD′) by calculating a hash value therefor at 1490 and then encrypting the hash value at 1492 using aprivate key 1495 of a public-private key pair. For increased reliability and trust, theprivate key 1495 is retained securely withinmemory 1494 so that it is never exported from thedevice 1440 and is not discoverable from outside of thedevice 1440. The digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, thedigital signature 1499 is generated using a random number generator, and the hash function at 1490 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received. Thedigital signature 1499 then is output from thedevice 1440 together with the value of theidentification marker 1472 as theindicator 1460 of the verification status (IVS) of thedevice 1440 for transmitting to the recipient. Thedigital signature 1499 and theindicator 1460 then are transmitted to the recipient in association with theEC 1410, whereby the recipient is able to identify theindicator 1460 as pertaining to theEC 1410. - The
device 1440 includes a set of predefined verification statuses each representing a relational correspondence between theverification data 1450 and theprestored data 1470. Verification statuses of the set further represent whether anindicator 1460 has been output from thedevice 1440 since the last successful verification or since the last receipt of input representing verification data. The set also contains an additional predefined verification status representing the lack of input representingverification data 1450 since a resetting after a timeout or a powering on of thedevice 1440. Theindicator 1460 output from thedevice 1440 is based on the last comparison of theverification data 1450 with theprestored data 1470, but only if input representingverification data 1450 has been received since the resetting of thedevice 1440. Otherwise, theindicator 1460 indicates the lack of input representingverification data 1450 since the resetting of thedevice 1440. - The
electronic apparatus 1430 includes an interface (not shown) capable of receiving theindicator 1460. Theelectronic apparatus 1430 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on theindicator 1460 and for evaluating theEC 1410 received from thesender 1420 based on the determined verification status. In this regard, theelectronic apparatus 1430 decrypts the digital signature with the public key, which corresponds to theprivate key 1495 and which may be received in association with thedigital signature 1499 or known or obtained beforehand by the recipient. The recipient also modifies—and then calculates a hash value for—the message based on the verification status identified by theindicator 1460. In calculating a hash value for comparison, theelectronic apparatus 1430 also performs any necessary processing to the message in order to produce the message data that was modified within thedevice 1440. When the hash value calculated by the recipient equals the hash value of the decrypted digital signature, the recipient confirms the authenticity of the current verification status of thedevice 1440 as indicated by theindicator 1460 as well as confirms the authenticity of the message of theEC 1410. - When the
verification data 1450 and theprestored data 1470 comprise a Secret, the predefined set of verification statuses includes four verification statuses, comprising: a first verification status representing the lack ofverification data 1450 since a resetting of the device; a second verification status representing a match between theverification data 1450 and theprestored data 1470, and further representing noother indicator 1460 being output from thedevice 1440 since the match; a third verification status representing a failed match between theverification data 1450 and theprestored data 1470; and a fourth verification status representing a match between theverification data 1450 and theprestored data 1470, and further representing the output of anindicator 1460 since the match. Theidentification marker 1472 stored inmemory 1474 preferably comprises one of four binary numbers that represents the current verification status identified by thedevice 1440. Of course, the correspondence between the values of theidentification marker 1472 and the predefined verification statuses of the device should be previously known by the recipient. - The four binary numbers respectively correspond to the four verification statuses and include: “00” identifying the first verification status; “01” identifying the second verification status; “10” identifying the third verification status; and “11” identifying the fourth verification status. Furthermore, the modification of the
message data 1422 at 1477 preferably includes the embedding of the value of theidentification marker 1472 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data. As also will be appreciated, the “modification” of the message data for one of the verification statuses may include not modifying the message data, such as when theidentification marker 1472 equals “00.” Even in this case, however, thedigital signature 1499 identifies the verification status of the device as representing the lack ofverification data 1450 being received since a resetting of the device. Furthermore, it will be appreciated that neither thedigital signature 1499 for the modified message nor theindicator 1460 reveals theverification data 1450 or theprestored data 1470; thus, no “shared secret” is required between thesender 1420 and the recipient in thepreferred embodiment 1400. However, the recipient can infer correct knowledge of the Secret from the verification status. - Alternatively, when the
verification data 1450 and theprestored data 1470 comprise biometric values, the set of predefined verification statuses comprises the possible percentages of match—or degrees of difference—between theverification data 1450 andprestored data 1470, together with a verification status representing the lack of input representingverification data 1450 since a resetting of thedevice 1440. For example, the predefined verification statuses comprising the percentage match of theverification data 1450 with theprestored data 1470 may comprise the set of percentages ranging from 0% to 100% in increments of 1%. Preferably each one of the verification statuses representing a percentage match also further represents whether anindicator 1460 has been output from thedevice 1440 since the last receipt of input representingverification data 1450. Theidentification marker 1472 stored inmemory 1474 preferably comprises the percentage match plus a flag regarding the output of theindicator 1460 as identified by thedevice 1440. Of course, the correspondence between the values of theidentification marker 1472 and the predefined verification statuses of thedevice 1440 should be previously known by the recipient. - Also, in this case, the modification of the
message data 1422 at 1477 preferably includes the embedding of the value of theidentification marker 1472 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data. As also will be appreciated, the “modification” of the message data for one of the verification statuses may include not modifying the message data, such as when noverification data 1450 has been received since a resetting of thedevice 1440. Even in this case, however, thedigital signature 1499 identifies the verification status of thedevice 1440 as representing the lack ofverification data 1450 being received since a resetting of thedevice 1440. Furthermore, it will be appreciated that neither thedigital signature 1499 for the modified message nor theindicator 1460 reveals theverification data 1450 or theprestored data 1470; thus, no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status the presence of thesender 1420 from the reading of the biometric characteristic. - A variation based on the seventh
preferred embodiment 1400 of FIG. 14a is shown in FIG. 14b, and includes an I/O support element 1462 from which input representing theverification data 1450 and input representing themessage data 1422 is received by thedevice 1440. The I/O support element 1462 includes auser interface 1458 from which input from thesender 1420 is received and an I/O interface 1459 that communicates the input representing theverification data 1450 and input representing themessage data 1422 to thedevice 1440. Although themessage data 1422 is shown coming from the I/O support element 1462, it is possible for some or all of themessage data 1422 to originate with thedevice 1440 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG. 14c, wherein the I/O support element 1462 receives theindicator 1460 anddigital signature 1499 output from thedevice 1440. The I/O support element 1462, in turn, transmits theindicator 1460 and thedigital signature 1499 to theelectronic apparatus 1430. - As shown, the
indicator 1460 anddigital signature 1499 transmitted from the I/O support element 1462 are the same as theindicator 1460 and digital signature 1486 output from thedevice 1440. However, the indicator transmitted from the I/O support element 1462 may be different from the indicator output from thedevice 1440, so long as the recipient is able to determine both the verification status as indicated by theindicator 1460 output from thedevice 1440, as well as the bit pattern of theidentification marker 1472 based on which the message was modified. For instance, the indicator transmitted from the I/O support element 1462 may indicate not only the verification status of thedevice 1440, but also a verification status of the I/O support element 1462 when the I/O support element 1462 itself identifies a verification status. Furthermore, theindicator 1460 anddigital signature 1499 transmitted from the I/O support element 1462 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 1462. - Furthermore, in FIGS. 14a, 14 b, and 14 c, the
EC 1410 is shown as being transmitted separate from theindicator 1460 anddigital signature 1499. However, in the preferred embodiment of FIG. 14a and any variations thereof, theindicator 1460 anddigital signature 1499 equally may be associated with theEC 1410 by being transmitted as part of theEC 1410. Furthermore, theEC 1410 may be output from thedevice 1440, an associated I/O support element 1462 (not shown in FIG. 14a), or other apparatus. - A preferred
mode 1500 of operation of the device of FIGS. 14a, 14 b, and 14 c is illustrated in FIG. 15 and begins with a resetting Step 1504 of the device following a timeout or powering on of the device at 1502. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input of verification data and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 1506 and ends at 1512 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. - Still referring to FIG. 15, the first step in the loop preferably includes the
determination Step 1508 whether any input representing verification data is received by the device. If the determination inStep 1508 is positive, the current verification status (VS) of the device is identifiedStep 1514 by comparing the verification data (VD) with the data (PD) prestored in the memory of the device. The verification status identified then is recorded by assigningStep 1516 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing verification data is received in
Step 1508 or after the value of the identification marker is recorded inStep 1516, the next step in the loop preferably includes thedetermination Step 1510 whether any input representing message data (MD) is received by the device. If the determination inStep 1510 is negative, the loop restartsStep 1506. - If the determination in
Step 1510 is positive, the device then modifiesStep 1518 the message data based on the identification marker. Next, the device originates Step 1520 a digital signature for the modified message data. The digital signature for the modified message data and the value of the identification marker are thenoutput Step 1522 from the device. Following the output of the digital signature for the modified message and value of the identification marker, the determination is madeStep 1524 whether the value of the identification marker output is the first value thereof output since receipt of input representing verification data inStep 1508. The loop restartsStep 1506 if the determination inStep 1524 is negative. If the determination inStep 1524 is positive, then the verification status is newly recordedStep 1526 by assigning a value to the identification marker that represents the verification status identified by the value of the identification marker output inStep 1522, and that further represents the fact that the value of the identification marker has been output. The loop then restartsStep 1506. - 8. Eighth Preferred Embodiment (Multiple Verification Data With Indicator And Message Digitally Signed)
- An eighth
preferred embodiment 1600 of the present invention is illustrated in FIG. 16a, wherein anEC 1610 including a message from asender 1620 is received by a recipient represented by anelectronic apparatus 1630, and wherein adevice 1640 receives input representing first verification data (VD1) 1651 and input representing second verification data (VD2) 1653 at adevice interface 1652. Thedevice interface 1652 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 1620; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port. - The
device 1640 includes a verification component therein that maintains data prestored in memory of thedevice 1640. The first prestored data (PD1) 1642 is located inmemory 1641, and the second prestored data (PD2) 1644 is located inmemory 1643. The verification component identifies at 1656 a current verification status of thedevice 1640 based on a comparison of thefirst verification data 1651 with thefirst prestored data 1642 and thesecond verification data 1653 with thesecond prestored data 1644, and records the latest (i.e., “current”) verification status of thedevice 1640 by assigning a value to an identification marker (IM) 1672 stored inmemory 1674. - The
device 1640 also receives at thedevice interface 1652 message data (MD) 1622 representing the message (M) of theEC 1610. Themessage data 1622 may comprise the message itself, a message digest thereof, or the result of some other processing of the message. Thedevice 1640 includes a digital signature component that, upon receipt of themessage data 1622, obtains the value for theidentification marker 1672 and modifies the message data at 1677 as a function of this value (as used herein, “function” may include the possible function f(x)=x for a particular value of x). The modification of the message preferably includes the embedding of the value of theidentification marker 1672 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data. As also will be appreciated, the “modification” of the message data for one of the verification statuses may include not modifying the message data. - The digital signature component then originates a
digital signature 1699 for the modified message data (MD′) by calculating a hash value therefor at 1690 and then encrypting the hash value at 1692 using aprivate key 1695 of a public-private key pair. - For increased reliability and trust, the
private key 1695 is retained securely withinmemory 1694 so that it is never exported from thedevice 1640 and is not discoverable from outside of thedevice 1640. The digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, thedigital signature 1699 is generated using a random number generator, and the hash function at 1690 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received. Thedigital signature 1699 then is output from thedevice 1640 together with the value of theidentification marker 1672 as theindicator 1660 of the verification status (IVS) of thedevice 1640 for transmitting to the recipient. Thedigital signature 1699 and theindicator 1660 then are transmitted to the recipient in association with theEC 1610, whereby the recipient is able to identify theindicator 1660 as pertaining to theEC 1610. - The
device 1640 includes a set of predefined verification statuses each representing a relational correspondence between theverification data prestored data indicator 1660 has been output from thedevice 1640 since the last successful verification based on either or both of the first andsecond verification data second verification data second verification data device 1640. Theindicator 1660 output from thedevice 1640 is based on the last respective comparison of verification data with the prestored data, but only if input representing the respective verification data has been received since the resetting of thedevice 1640. Otherwise, theindicator 1660 indicates the lack of input for both the first andsecond verification data device 1640. - The
electronic apparatus 1630 includes an interface (not shown) capable of receiving theindicator 1660. Theelectronic apparatus 1630 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on theindicator 1660 and for evaluating theEC 1610 received from thesender 1620 based on the determined verification status. In this regard, theelectronic apparatus 1630 decrypts the digital signature with the public key, which corresponds to theprivate key 1695 and which may be received in association with thedigital signature 1699 or known or obtained beforehand by the recipient. The recipient also modifies—and to then calculates a hash value for—the message based on the verification status identified by theindicator 1660. In calculating a hash value for comparison, theelectronic apparatus 1630 also performs any necessary processing to the message in order to produce the message data that was modified within thedevice 1640. When the hash value calculated by the recipient equals the hash value of the decrypted digital signature, the recipient confirms the authenticity of the current verification status of thedevice 1640 as indicated by theindicator 1660 as well as confirms the authenticity of the message of theEC 1610. - When either of the first or
second verification data device 1640; a second outcome representing a match between the verification data and the prestored data, and further representing noother indicator 1660 being output from thedevice 1640 since the match; a third outcome representing a failed match between the verification data and the prestored data; and a fourth outcome representing a match between the verification data and the prestored data, and further representing the output of anindicator 1660 since the match. - When either of the first or
second verification data device 1640. For example, the predefined outcomes comprising the percentage match of the verification data with the prestored data may comprise the set of percentages ranging from 0% to 100% in increments of 1%. Preferably each one of the outcomes representing a percentage match also further represents whether anindicator 1660 has been output from thedevice 1640 since the last receipt of input representing verification data. - The
identification marker 1672 is stored inmemory 1674 and comprises a value representing one of the set of predefined verification statuses of thedevice 1640. The set of predefined verification statuses preferably comprises all of the possible combinations of outcomes from the respective comparisons for the first andsecond verification data identification marker 1672 with the predefined verification statuses of thedevice 1640 should be previously known by the recipient. Moreover, none of the verification statuses actually reveal any of theverification data prestored data sender 1620 and the recipient, and no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status both the correct knowledge of the Secret and the presence of the sender from the reading of the biometric characteristic. - A variation based on the eighth
preferred embodiment 1600 of FIG. 16a is shown in FIG. 16b, and includes an I/O support element 1662 from which input representing the first andsecond verification data message data 1622 is received by thedevice 1640. The I/O support element 1662 includes auser interface 1658 from which input from thesender 1620 is received and an I/O interface 1659 that communicates the input representing the first andsecond verification data message data 1622 to thedevice 1640. - Although the
message data 1622 is shown coming from the I/O support element 1662, it is possible for some or all of themessage data 1622 to originate with thedevice 1640 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG. 16c, wherein the I/O support element 1662 receives theindicator 1660 anddigital signature 1699 output from thedevice 1640. The I/O support element 1662, in turn, transmits theindicator 1660 and thedigital signature 1699 to theelectronic apparatus 1630. - As shown, the
indicator 1660 anddigital signature 1699 transmitted from the I/O support element 1662 are the same as theindicator 1660 and digital signature 1686 output from thedevice 1640. However, the indicator transmitted from the I/O support element 1662 may be different from the indicator output from thedevice 1640, so long as the recipient is able to determine both the verification status as indicated by theindicator 1660 output by thedevice 1640, as well as the bit pattern of theidentification marker 1672 based on which the message was modified. For instance, the indicator transmitted from the I/O support element 1662 may indicate not only the verification status of thedevice 1640, but also a verification status of the I/O support element 1662 when the I/O support element 1662 itself identifies a verification status. Furthermore, theindicator 1660 anddigital signature 1699 transmitted from the I/O support element 1662 may be packaged or embedded within another communication—including additional information that is digitally signed by the I/O support element 1662. - Furthermore, in FIGS. 16a, 16 b, and 16 c, the
EC 1610 is shown as being transmitted separate from theindicator 1660 anddigital signature 1699. However, in the preferred embodiment of FIG. 16a and any variations thereof, theindicator 1660 anddigital signature 1699 equally may be associated with theEC 1610 by being transmitted as part of theEC 1610. Furthermore, theEC 1610 may be output from thedevice 1640, an associated I/O support element 1662 (not shown in FIG. 16a), or other apparatus. - A preferred
mode 1700 of operation of the device of FIGS. 16a, 16 b, and 16 c is illustrated in FIG. 17 and begins with a resetting Step 1704 of the device following a timeout or powering on of the device at 1702. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input of any verification data and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 1706 and ends at 1714 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. - Still referring to FIG. 17, the first step in the loop preferably includes the
determination Step 1708 whether any input representing the first verification data (VD1) is received by the device. If the determination inStep 1708 is positive, the current verification status (VS) of the device is identifiedStep 1716 by comparing the first verification data (VD1) with the first data (PD1) prestored in the memory of the device. The verification status identified then is recorded by assigningStep 1718 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. If no input representing the first verification data is received inStep 1708 or after the value of the identification marker is recorded inStep 1718, the next step in the loop preferably includes thedetermination Step 1710 whether any input representing the second verification data (VD2) is received by the device. If the determination inStep 1710 is positive, the current verification status (VS) of the device is identifiedStep 1720 by comparing the second verification data (VD2) with the second data (PD2) prestored in the memory of the device. The verification status identified then is recorded by assigningStep 1722 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing the second verification data is received in
Step 1710 or after the value of the identification marker is recorded inStep 1722, the next step in the loop preferably includes thedetermination Step 1712 whether any input representing message data (MD) is received by the device. If the determination inStep 1712 is negative, the loop restartsStep 1706. - If the determination in
Step 1712 is positive, the device then modifiesStep 1724 the message data based on the identification marker. Next, the device originates Step 1726 a digital signature for the modified message data. The digital signature for the modified message data and the value of the identification marker are thenoutput Step 1728 from the device. Following the output of the digital signature for the modified message and value of the identification marker, the determination is madeStep 1730 whether the value of the identification marker output is the first value thereof output since receipt of input representing the first verification data inStep 1708. - If the determination in
Step 1730 is positive, then the verification status is newly recordedStep 1734 by assigning a value to the identification marker that represents the verification status identified by the value of the identification marker output inStep 1728, and that further represents the fact that the value of the identification marker has been output. If the determination inStep 1730 is negative or after the value of the identification marker is newly recorded inStep 1734, the next step in the loop preferably includes thedetermination Step 1732 whether the value of the identification marker output is the first value thereof output since receipt of input representing the second verification data inStep 1710. - If the determination in
Step 1732 is positive, then the verification status is newly recordedStep 1736 by assigning a value to the identification marker that represents the verification status identified by the value of the identification marker output inStep 1728, and that further represents the fact that the value of the identification marker has been output. If the determination inStep 1732 is negative or after the value of the identification marker is newly recorded inStep 1736, the loop then restartsStep 1706. - 9. Ninth Preferred Embodiment (Multiple Verification Data With Digital Signature as Indicator)
- A ninth
preferred embodiment 1800 of the present invention is illustrated in FIG. 18a, wherein anEC 1810 including a message from asender 1820 is received by a recipient represented by anelectronic apparatus 1830, and wherein adevice 1840 receives input representing first verification data (VD1) 1851 and input representing second verification data (VD2) 1853 at adevice interface 1852. Thedevice interface 1852 includes, as appropriate, one or more of the following: a user interface such as an alphanumeric keypad, a touch screen display, or a biometric scanner for receiving input directly from thesender 1820; an electrical contact; a standard electronic interface with a computer bus; an antenna; or a communications port, such as a serial port, USB port, parallel port, infrared port or other wireless communications port. - The
device 1840 includes a verification component therein that maintains data prestored in memory of thedevice 1840. The first prestored data (PD1) 1842 is located inmemory 1841, and the second prestored data (PD2) 1844 is located inmemory 1843. The verification component identifies at 1856 a current verification status of thedevice 1840 based on a comparison of thefirst verification data 1851 with thefirst prestored data 1842 and thesecond verification data 1853 with thesecond prestored data 1844, and records the latest (i.e., “current”) verification status of thedevice 1840 by assigning a value to an identification marker (IM) 1872 stored inmemory 1874. In this case wherein comparisons of more than one input of verification data is made, theidentification marker 1872 comprises a value assigned to a first comparison marker representing the result of the first comparison and a value assigned to a second comparison marker representing the result of the second comparison. - The
device 1840 also receives at thedevice interface 1852 message data (MD) 1822 representing the message (M) of theEC 1810. Themessage data 1822 may comprise the message itself, a message digest thereof, or the product of some other processing of the message. Thedevice 1840 includes a digital signature component that, upon receipt of themessage data 1822, obtains the value for theidentification marker 1872 and modifies the message data at 1877 as a function of this value (as used herein, “function” may include the possible function f(x)=x for a particular value of x). The modification of the message preferably includes the embedding of the value of theidentification marker 1872 within the message data, including insertion of the value at a predefined location within, or at the beginning or end of, the message data. As also will be appreciated, the “modification” of the message data for one of the verification statuses may include not modifying the message data. - The digital signature component then originates a
digital signature 1899 for the modified message data (MD′) by calculating a hash value therefor at 1890 and then encrypting the hash value at 1892 using aprivate key 1895 of a public-private key pair. For increased reliability and trust, theprivate key 1895 is retained securely withinmemory 1894 so that it is never exported from thedevice 1840 and is not discoverable from outside of thedevice 1840. The digital signature is originated in accordance with the ECDSA as specified in FIPS PUB 186-2. Accordingly, thedigital signature 1899 is generated using a random number generator, and the hash function at 1890 is performed using SHA-1, which generates a 20-byte output regardless of the size of the input received. Thedigital signature 1899 then is output from thedevice 1840 as theindicator 1860 of the verification status (IVS) of thedevice 1840 for transmitting to the recipient. Thedigital signature 1899 output from thedevice 1840 actually comprises the indicator of the verification status (IVS) 1860 as a consequence of the modification process. The current outcome of the first comparison (results of VD1 and PD1 comparison) is also output as a result (R) 1896. Theindicator 1860 and result 1896 then are transmitted to the recipient in association with theEC 1810, whereby the recipient is able to identify theindicator 1860 and result 1896 as pertaining to theEC 1810. - The
device 1840 includes a set of predefined verification statuses each representing a relational correspondence between theverification data prestored data indicator 1860 has been output from thedevice 1840 since the last successful verification based on either or both of the first andsecond verification data second verification data second verification data device 1840. Theindicator 1860 output from thedevice 1840 is based on the last respective comparisons of verification data with the prestored data, but only if input representing verification data has been received since the resetting of thedevice 1840. Otherwise, theindicator 1860 indicates the lack of input for both the first andsecond verification data device 1840. - The
electronic apparatus 1830 includes an interface (not shown) capable of receiving theindicator 1860. Theelectronic apparatus 1830 also includes logic circuitry or software incorporating business logic therein for determining the verification status of the device based on theindicator 1860 and for evaluating theEC 1810 received from thesender 1820 based on the determined verification status. In this regard, theelectronic apparatus 1830 decrypts the digital signature with the public key, which corresponds to theprivate key 1895 and which may be received in association with thedigital signature 1899 or known or obtained beforehand by the recipient. The recipient also modifies—and then calculates a hash value for—the message based on theresult 1896 and for each possible outcome of the second comparison until the calculated hash value equals the hash value of the decrypted digital signature. In calculating a hash value for comparison, theelectronic apparatus 1830 also performs any necessary processing to the message in order to produce the message data that was modified within thedevice 1840. When the hash value calculated by the recipient equals the hash value of the decrypted digital signature, the recipient thereby determines the current verification status of thedevice 1840. This determination also confirms the authenticity of the message of theEC 1810. Furthermore, in order to minimize consumption of resources, the second set of outcomes for the second comparison (VD2 with PD2) is predefined to contain only a limited number of outcomes. For instance, the first verification data and prestored data therefor A preferably represent a biometric characteristic, and the second verification data and prestored data therefor preferably represent a Secret. - When either of the first or
second verification data device 1840; a second outcome representing a match between the verification data and the prestored data, and further representing noother indicator 1860 being output from thedevice 1840 since the match; a third outcome representing a failed match between the verification data and the prestored data; and a fourth outcome representing a match between the verification data and the prestored data, and further representing the output of anindicator 1860 since the match. - When either of the first or
second verification data device 1840. For example, the predefined outcomes comprising the percentage match of the verification data with the prestored data may comprise the set of percentages ranging from 0% to 100% in increments of 1%. Preferably each one of the outcomes represents a percentage match also further represents whether anindicator 1860 has been output from thedevice 1840 since the last receipt of input representing verification data. - The
identification marker 1872 is stored inmemory 1874 and comprises a value representing one of the set of predefined verification statuses of thedevice 1840. The set of predefined verification statuses preferably comprises all of the possible combinations of outcomes from the respective comparisons for the first andsecond verification data identification marker 1872 with the predefined verification statuses of thedevice 1840 should be previously known by the recipient. Moreover, none of the verification statuses actually reveal any of theverification data prestored data sender 1820 and the recipient, and no biometric value representing the sender's irreplaceable biometric characteristic is communicated to the recipient. However, the recipient can infer from the verification status both the correct knowledge of the Secret and the presence of the sender. - A variation based on the ninth
preferred embodiment 1800 of FIG. 18a is shown in FIG. 18b, and includes an I/O support element 1862 from which input representing the first andsecond verification data message data 1822 is received by thedevice 1840. The I/O support element 1862 includes auser interface 1858 from which input from thesender 1820 is received and an I/O interface 1859 that communicates the input representing the first andsecond verification data message data 1822 to thedevice 1840. Although themessage data 1822 is shown coming from the I/O support element 1862, it is possible for some or all of themessage data 1822 to originate with thedevice 1840 or another apparatus (not shown). Yet an additional variation thereof is shown in FIG. 18c, wherein the I/O support element 1862 receives theindicator 1860 and theresult 1896 output from thedevice 1840. The I/O support element 1862, in turn, transmits theindicator 1860 and theresult 1896 to theelectronic apparatus 1830. - As shown, the
indicator 1860 and result 1896 transmitted from the I/O support element 1862 are the same as theindicator 1860 and result 1896 output from thedevice 1840. However, the result transmitted from the I/O support element 1862 may be different from the result output from thedevice 1840, so long as the recipient is able to determine the bit pattern of theresult 1872 based in part on which the message was modified. For instance, the result transmitted from the I/O support element 1862 may indicate not only the result of the comparison of the first verification data input into thedevice 1840, but also a verification status of the I/O support element 1862 when the I/O support element 1862 itself identifies a verification status. Furthermore, theindicator 1860 and result 1896 transmitted from the I/O support element 1862 may be packaged or embedded within another communication-including additional information that is digitally signed by the I/O support element 1862. - Furthermore, in FIGS. 18a, 18 b, and 18 c, the
EC 1810 is shown as being transmitted separate from theindicator 1860 andresult 1896. However, in the preferred embodiment of FIG. 18a and any variations thereof, theindicator 1860 and result 1896 equally may be associated with theEC 1810 by being transmitted as part of theEC 1810. Furthermore, theEC 1810 may be output from thedevice 1840, an associated I/O support element 1862 (not shown in FIG. 18a), or other apparatus. - A preferred
mode 1900 of operation of the device of FIGS. 18a, 18 b, and 18 c is illustrated in FIG. 19 and begins with a resetting Step 1904 of the device following a timeout or powering on of the device at 1902. During the reset, the identification marker is assigned a value corresponding to a verification status representing the receipt of no input of any verification data and further representing the fact that that no indicator has yet been output. The device then enters a repeating loop that begins at 1906 and ends at 1914 and continues within this loop until the device is reset, is powered off, or deactivates after a predetermined amount of time. - Still referring to FIG. 19, the first step in the loop preferably includes the
determination Step 1908 whether any input representing the first verification data (VD1) is received by the device. If the determination inStep 1908 is positive, the current verification status (VS) of the device is identifiedStep 1916 by comparing the first verification data (VD1) with the first data (PD1) prestored in the memory of the device. The verification status identified then is recorded by assigningStep 1918 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. If no input representing the first verification data is received inStep 1908 or after the value of the identification marker is recorded inStep 1918, the next step in the loop preferably includes thedetermination Step 1910 whether any input representing the first verification data (VD1) is received by the device. If the determination inStep 1910 is positive, the current verification status (VS) of the device is identifiedStep 1920 by comparing the second verification data (VD2) with the second data (PD2) prestored in the memory of the device. The verification status identified then is recorded by assigningStep 1922 the identification marker stored within the memory of the device equal to the predefined value corresponding to the identified verification status. - If no input representing the second verification data is received in
Step 1910 or after the value of the identification marker is recorded inStep 1922, the next step in the loop preferably includes thedetermination Step 1912 whether any input representing message data (MD) is received by the device. If the determination inStep 1912 is negative, the loop restartsStep 1906. - If the determination in
Step 1912 is positive, the device then modifiesStep 1924 the message data based on the identification marker. Next, the device originates Step 1926 a digital signature for the modified message data. The digital signature for the modified message data and the value of the result for the first comparison are thenoutput Step 1928 from the device. Following the output of the digital signature for the modified message and value of the result of the first comparison, the determination is madeStep 1930 whether the digital signature is the first output since receipt of input representing the first verification data inStep 1908. If the determination inStep 1930 is positive, then the verification status is newly recordedStep 1934 by assigning a value to the identification marker that represents the verification status identified by the digital signature marker output inStep 1928, and that further represents the fact that the digital signature has been output. - If the determination in
Step 1930 is negative or after the value of the identification marker is newly recorded inStep 1934, the next step in the loop preferably includes thedetermination Step 1932 whether the digital signature is the first output since receipt of input representing the second verification data inStep 1910. If the determination inStep 1932 is positive, then the verification status is newly recordedStep 1936 by assigning a value to the identification marker that represents the verification status identified by the digital signature output inStep 1928, and that further represents the fact that the digital signature has been output. If the determination inStep 1932 is negative or after the value of the identification marker is newly recorded inStep 1936, the loop then restartsStep 1906. - C. Data Formats, Embodiments, and Implementations of the Present Invention
- In accordance with all of the aspects of the present invention, the device comprises hardware, software and/or firmware and, specifically, comprises a computer chip, an integrated circuit, a computer—readable medium having suitable software therein, or a combination thereof. The device further may comprise a physical object such as a hardware token or an embedded token, the token containing such a computer chip, integrated circuitry, software, or combination thereof. If the device is a hardware token, it preferably takes the form of a ring or other jewelry; a dongle; an electronic key; a card, such as an IC card, smart card, debit card, credit card, ID badge, security badge, parking card, or transit card; or the like. If the device is an embedded token, it preferably takes the form of a cell phone; a telephone; a television; a personal digital assistant (PDA); a watch; a computer; computer hardware; or the like. The device preferably includes a device interface comprising a port—including a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port—or some other physical interface for communicating with at least an external electronic apparatus, whether contact or contactless. The device also may include a trusted platform module (TPM) comprising hardware and software components providing increased trust in a platform, as set forth and described in the TCPA Documents cited above. Some of the above devices require use of an I/O support element to enable the device to receive message data or verification data. Some of the devices require an I/O support element to receive specific types of verification data but not others. Some of the devices require use of an I/O support element to transmit information regarding verification statuses, digital signatures, and messages to recipients of the ECs. Some of the devices are self-contained, which means that they can generate and transmit messages, digital signatures, and indicators of verification status without the use of external apparatuses; some devices, although self-contained, are capable of interacting with such external apparatuses, such as an I/O support element, if desired. An I/O support element may take the form of any number of different apparatuses, depending upon the particular application in which it is used and depending upon the type of device with which it interacts.
- For higher security applications, the device—or the device in combination with an I/O support element—preferably includes the following components: a keypad (alphanumeric), interactive display, or other type of user data entry mechanism (collectively referred to herein as “User Interface”) that allows the sender of an EC to compose or modify a message; a User Interface for inputting Secret verification data (it should be noted that the User Interface for generating or modifying a message may, but does not have to, be the same as the User Interface for the entry of the Secret verification data); a display for showing the message and/or Secret to the sender of the EC using the device; a scanner or reader for receiving at least one type of biometric verification data; memory for securely storing the Secret(s), prestored biometric data, and the private key (PrK); a processor or circuitry for performing the various comparisons and for identifying a verification status of the device; a processor or circuitry for generating or originating digital signatures; and a means for outputting information from the device and transmitting it to the electronic apparatus. Preferably, the device also includes memory for storing and exporting the public key (PuK) associated with the particular private key (PrK), and for storing additional user information such as account information, user ID's, and the like. For lower security applications, not all of the above elements are necessary.
- To this point, the discussion of the present invention has focused on the flow of data into and out of the device and the manipulation of such data performed by components within the device or in communication with the device. This section provides further detail regarding, for example, preferred database formats and exemplary data values and structures for verification data, prestored data, verification statuses, and identification markers and indicators of verification status. This section also illustrates preferred methodologies for identifying verification statuses when verification data represents a Secret, biometric characteristic, or a combination of both. Additionally, this section illustrates the functional aspects of a preferred computer chip that may be used as the device or as part of a device of the present invention. Finally, this section provides several specific implementations of a device—in this case an IC card—adapted for use in accordance with the present invention.
- 1. Prestored Data, Verification Data, and Indicators of Verification Status
- a. Record Formats for Prestored Data
- As shown in FIGS. 20a, 20 b, and 20 c, the prestored data of an authorized user of a device (generally referred to as PD) may be maintained in
suitable records PIN 2003,record 2000 a would simply contain the “value” 2005 for the Secret Prestored Data (SPD) 2042 (or referred to generically as PD 2070). As shown in FIG. 20b, for slightly more complex applications in which the device is adapted to receive and process only one specifiedtype 2002 ofbiometric data 2007,record 2000 b would simply contain the “value” 2009 for the applicable Biometric Prestored Data (BPD) 2044 (also referred to generically as PD 2070). - As shown in FIG. 20c, for other applications in which the device is adapted to receive and process more than one specified type of verification data, the
record 2000 c includes a list of the possibleverification data types 2002 representing both a Secret and a biometric characteristic. Eachtype 2002 of verification data (whether Secret or biometric) has associated therewith a correspondingpre-set identifier 2004 and a corresponding unique value 2006 comprising the prestored data 2070 therefor. Thespecific identifiers 2004 associated withparticular data types 2002, as shown in FIG. 20c, are arbitrary and may be formatted or established to conform with any industry standard or convention now or hereinafter developed (such as, for example, the standards set forth in Biometric Information Management and Security for the Financial Services Industry, Document Number X9.84-2000 WD, American National Standards Institute, 2000, which is incorporated herein by reference and which is available for download at http://webstore.ansi.org). Further, the list oftypes 2002 of data shown in FIG. 20c, is only intended to be exemplary and, in practice,record 2000 c may include more, less, or differentspecific types 2002 of data. - In addition, although the
types 2002 of data are shown inrecords types 2002 actually be maintained in these records if the relationship between eachdata type 2002 and itscorresponding identifier 2004 is otherwise known. Except for the prestored data (values 2005,2008) for the PINs, which is conventionally includes a 4-10 digit alphanumeric string, thevalues 2009,2010 associated with eachtype 2002 of biometric data will generally be a numeric value corresponding to a digital representation of an authorized user's biometric characteristic. For example, the current F.B.I. standard for electronic fingerprint scans is “40 point minutiae.” Such a value may be obtained by an appropriate and conventional biometric scanner capable of scanning and converting such scan into a digital representation of the particularbiometric data type 2002. Generally, for any particularbiometric data type 2002, it is preferably that the same standard, scale, or convention be used at both the personalization stage of the device, when such data is input into the device for the purpose of creating the prestored data, as well as each time verification data is later input into the device for the purpose of identifying a verification status. If no data has been prestored for comparison with aparticular type 2002 of data, then the correspondingvalue 2012 for thatdata type 2002 is set to zero, null, or comparable equivalent value. - b. Verification Data Formats Input Into the Device
- As shown in FIG. 21a, for simple applications in which the device is adapted to receive and process only a Secret (again, such as a PIN), it is preferable that the
verification data 2150 comprise Secret Verification Data (SVD) 2151 having avalue 2102 input by the sender of an EC when using the device. As shown in FIG. 21b, for slightly more complex applications in which the device is adapted to receive and process only one specified type of biometric verification data, it is preferable that theverification data 2150 comprise Biometric Verification Data (BVD) 2153 having avalue 2104 input in response to a scan of a biometric characteristic provided by the sender when using the device. Finally, as shown in FIG. 21c, for other applications in which the device is adapted to receive and process more than one specified type of verification data, whether Secret or biometric, it is preferable that theverification data 2150 comprise both anidentifier 2106 and acorresponding value 2108. Theidentifier 2106 indicates the type of verification data being input into the device, and, hence, indicates the prestored data the device will need to reference for comparison purposes. Although not shown, it should be understood that instead of using identifiers, it is possible to use software or device commands or instructions in combination with the input ofverification data 2150 to notify the device of the particular type of theverification data 2150 being input. - c. Comparison Process and Identification of Verification Status
- Referring now to FIGS. 22, 23a, 23 b, and 24, several exemplary processes by which a device compares the verification data with prestored data and thereby identifies the verification status are set forth in greater detail. Again, as shown in FIG. 22, and referring initially to simple applications in which the device is adapted to receive and process only verification data for a Secret, the device first determines if input representing verification data (e.g. as shown in
Step 308 in FIG. 3) has in fact been received and, if so, determines (Step 2202) whether such verification data is for a Secret. If verification data for the Secret is not received, then the device maintainsStep 2204 the current verification status (the start-up default value of which is “No PIN entered”). - If verification data for a Secret is received, then the device retrieves
Step 2206 the corresponding prestored data (SPD), e.g., value 2005 from record 2000 a in FIG. 20a. Next, the device comparesStep 2208 the input value with the prestored data value. If the result (Rs) of the comparison is that the values are equal, then the device identifiesStep 2210 the verification status as “PIN match.” If the result (Rs) of the comparison is that the values are not equal, then the device identifiesStep 2212 the verification status as “PIN no match.” Furthermore, although FIG. 22 shows the verification statuses in a descriptive format (e.g., “No PIN entered;” “PIN match;” and “PIN no match”), it should be understood that the device, preferably, sets an identification marker (IM) to an arbitrary value that directly maps to a respective verification status which, in this simple example, is also equal to the result of the comparison (Rs). A few possible examples of equivalent identification marker values are illustrated in FIG. 25a. Nevertheless, it should be obvious to one skilled in the art that innumerable different types, conventions, or formats for suitable equivalent verification statuses corresponding to those listed in FIG. 25a may be chosen within the scope of the present invention. As shown in FIG. 25a, a first identification marker comprising a Secret verification result (Rs1)) 2502 is in cardinal number format. A second identification marker comprising a Secret verification result (Rs2) 2504 is in binary format. Additionally, a third identification marker comprising a Secret verification result (Rs3) 2506 that is shown is merely a different character string representation of the verification statuses listed in the first column of FIG. 25a. Referring back to FIG. 22, the resulting identification marker values shown inSteps - Referring now to FIGS. 23a and 23 b, for slightly more complex applications in which the device is adapted to receive and process only one specified type of biometric verification data, the device first determines
Step 2302 that biometric verification data has, in fact, been received. If no biometric verification data has been received, then the device maintainsStep 2304 the current verification status (the start-up default value of which is “No BIO input”). If the device has received biometric verification data, then the device retrievesStep 2306 the corresponding prestored data (BVD) (e.g. value 2009 fromrecord 2000 b in FIG. 20b). In biometric data comparisons, unlike in Secret data comparisons, it is preferred that the result (Rb) of the comparison comprise the degree or percentage of match (or difference) between the verification data and the prestored data. Thus, in preferred embodiments, the device identifies Step 2308 a a verification status by dividing the biometric verification data by the prestored data to obtain a percentage match between the two values and assigning the result (Rb) to the identification marker. - As shown in FIG. 23b, the device may alternatively obtain a percentage difference between the two values by calculating
Step 2308 b the absolute value of the difference between the two values and dividing that number by the prestored data, and then assigning the result (Rb) to the identification marker. Several examples of equivalent biometric identification marker values are illustrated in FIG. 26; however, it should be obvious to one skilled in the art that many different types, conventions, or formats for identification marker values showing degree or percentage of match or difference between the biometric verification data and the prestored data (e.g., such as those set forth in FIG. 26) may be chosen within the scope of the present invention. For example, a first identification marker comprising a biometric verification result (Rb1) 2602 is a percentage value (to 2 digits) corresponding to the degree of match or difference between the two values (with the calculated number substituted for the “##”). A second identification marker comprising a biometric verification result (Rb2) 2604 is a decimal value (to 2 digits) corresponding to the degree of match or difference between the two values. A third identification marker comprising biometric verification result (Rb3) 2606 is a character string associated with the corresponding verification status in the first column of the figure. - As has been described previously, in the preferred embodiment, the device outputs an indicator of the verification status based on biometric verification data in the form of a degree (or percentage) of match or degree (or percentage) of difference between the biometric verification data and the prestored data. By providing the verification status in this manner, the electronic apparatus (or recipient) is allowed to determine, based on its own logic or business rules, whether the degree of match obtained and provided by the device meets a required security threshold for a particular business purpose or application. This enables the device to be used easily with different recipients, each with its own threshold requirements for biometric verification data. Alternatively, it should be understood that the device itself could be pre-programmed or pre-hardwired to determine within the device whether the biometric verification data qualifies as a “match” or “no match” with the prestored data relative to an arbitrarily determined threshold-in which case, its identification marker would be similar merely to that for a comparison of verification data for a Secret.
- Referring now to FIG. 24, for other applications in which the device is adapted to receive and process Secret and biometric verification data, the device first initiates Step2402 a loop for the purpose of processing each input for those applications in which more than one type of verification data is received. In the first step within the loop, the device determines
Step 2404 whether verification data has been received. If verification data has not been received, then the device maintainsStep 2406 the current verification status (which at start-up is “No PIN entered; No BIO entered”). If verification data has been received, then the device retrievesStep 2410 the prestored data (2006 from FIG. 2000c) corresponding with the identifier (2106 from FIG. 21c) for such verification data. As an aside and as stated previously, another embodiment allows a device or computer command sent with the verification data to indicate the type of verification data being input without the use of an identifier 2106 (as shown in FIG. 21c). Next, the device determinesStep 2412, based on the identifier (or command input), whether the verification data represents a Secret or a biometric characteristic. - If the verification data represents a Secret, then the device compares
Step 2414 the verification data with the corresponding prestored data for such Secret. If the values are equal, then the device identifiesStep 2416 the result of the comparison as a “match” and, in this example, sets Rs equal to a value of “01” (using the binary convention from FIG. 25a). The loop then restartsStep 2408. If the values are not equal, then the device identifiesStep 2416 the results of the comparison as a “no match” and, in this example, sets Rs equal to a value of “10” (again using the binary convention from FIG. 25a). The loop then restarts atStep 2408. On the other hand, if the device determines that the verification data represents a biometric characteristic, then the device identifiesStep 2420 the verification status by comparing the verification data with the corresponding prestored data and calculating a percentage match therebetween. In this regard, the device sets Rb for the particular type of biometric verification data (designated by ###) equal to the value of the percentage match. The loop then restarts atStep 2408. In this example, the value of the identification marker (IM) corresponding with the verification status includes the value for Rs as well as the values for each Rb for each biometric verification type. - Several examples using specific numbers will help explain this process. In the first example, suppose a PIN and one type of biometric verification data, such as a right handprint, is entered into the device by a sender of an EC who is using the device. In this example (using the conventions discussed above with regard to FIGS. 20c and 21 c and with regard to
column 2504 of FIG. 25a and column 2702 of FIG. 26) a suitable verification status is represented by an identification marker including the following value: - 001,10,012,90 (with or without the commas)
- This identification marker indicates a verification status in which an incorrect PIN was received and a right handprint having a 90% degree of match was received.
- In a second example, suppose three types of biometric verification data (a right thumb, a left thumb, and a right iris scan) are entered. In this second example (again using the same conventions), a suitable verification status is represented by an identification marker including the following value:
- 002,95,007,93,018,87 (with or without the commas)
- This identification marker indicates a verification status in which a right thumbprint had a 95% match, a left thumbprint had a 93% match, and a right iris scan produced an 87% match.
- In an alternate embodiment, after performing the above steps, the device identifies the verification status as an identification marker containing every possible identifier2004 (or some subset thereof from FIG. 20c) followed by its corresponding Rs or Rb value. Thus, even though an input is not provided for every single type of verification data, the identification marker nevertheless includes all
identifiers 2004 and their corresponding Rs and Rb values. For those types for which no input is received, the corresponding value for Rs or Rb is its default value preferably comprising zero or null, or a suitable equivalent. In this third example, a suitable verification status is represented as an identification marker of: - 001,01,002,00,003,00,004,0.25,005,00,006,0.96, . . . 024,0.95
- Assuming that the “ . . . ” merely includes each identifier between 007 and 023 followed by a “00” (i.e., no verification data inputs corresponding with
identifiers 007 through 023), the identification marker in this example indicates a verification status in which a correct PIN was input, a right middle fingerprint had a 25% match, a right pinky fingerprint had a 96% match, and a DNA scan had a 95% match. Just for comparison purposes, unlike the previous examples, this example uses the conventions for Rb discussed above with regard tocolumn 2604 of FIG. 26. - In another alternative embodiment, it is possible to eliminate all of the
identifiers 2004 from the identification marker if the recipient knows what convention is used by the device, including the sequence of presenting each verification data type within the identification marker value or data stream. For example, using both conventions as described above for all twenty three identifiers (column 2504 of FIG. 25a for the Rs value andcolumn 2602 of FIG. 26 for the Rb values in the first identification marker below, andcolumn 2504 of FIG. 25a for the Rs value andcolumn 2604 of FIG. 26 for the Rs values in the second identification marker below) and assuming that the order of verification data types is the same as the twenty-threeidentifiers 2004 in FIG. 20c, the identification marker for the above-described verification status could be presented, alternatively, as follows: - 0100000.25000.9600000000000000000000000000000000000.95
- or
- 010000250096000000000000000000000000000000000095
- Each identification marker above identifies a verification status in which a correct PIN was input, a right middle fingerprint had a 25% match, a right pinky fingerprint had a 96% match, and a DNA scan had a 95% match.
- 2. Associating Specific Sender Approval for EC
- It is also possible and advantageous for the device to provide additional information to the recipient of an EC as to whether the verification status of the device is in a “persistent” state or whether the verification status applies specifically to the EC with which the indicator of verification status is associated. Such information can be used by the recipient to determine whether the sender of the EC input the correct Secret for a previous message or whether the correct Secret was input as specific approval or authorization of the transaction or request contained within the EC that is digitally signed. The same advantages apply in the case of a biometric characteristic.
- For example, as stated above, for devices configured only to receive verification data for a Secret, such as a PIN, there are three verification statuses, or “states”, that can be identified by the identification marker using the format of FIG. 25a: no PIN entered (Rs=00); correct PIN (Rs=01); and incorrect PIN (Rs=10). In accordance with this additional feature of the present invention, an additional “state” is added to these three as shown more fully in FIG. 25b. This additional state represents that a correct PIN was entered, but that since then, an indicator of the verification status was output or a digital signature was generated in association with an EC. This fourth state may be shown using any of the formats previously discussed, including a cardinal number format shown in
column 2508 of FIG. 25b; a binary format shown incolumn 2510 of FIG. 25b; and a character string format shown incolumn 2512 of FIG. 25b. Using the binary format, the fourth state is identified whenever an indicator is output or a digital signature is generated with the identification marker equaling “01” by setting, thereafter, the identification marker equal to “11”. - Alternatively, the device maintains a counter or “digital signature flag” (referred to hereinafter generically as “DSFlag”). In this regard, the DSFlag is initially set to zero and counts to one or more each time an indicator of verification status is output from or a digital signature is generated by the device. Thereafter, the DSFlag remains at one (or continues counting by one) for each indicator output or digital signature generated until verification data again is received by the device, after which the DSFlag is reset to zero. In this case, the value of the DSFlag is incorporated into the value of the identification marker as an additional bit of information. For example, possible values of an identification marker thus include the following, wherein “/” separates the binary value of Rs and the corresponding DSFlag value for purposes of illustration: 00/0 (no PIN input; no IVS or DS output); 00/1 (no PIN input; IVS or DS output); 01/0 (PIN match; no IVS or DS output since PIN match); 01/1 (PIN match; IVS or DS output since PIN match); 10/0 (PIN no match; no IVS or DS output); and 10/1 (PIN no match; IVS or DS output).
- For a device configured to receive one type of biometric verification data only, the device preferably includes a DSFlag as part of the identification marker in similar manner to the methodology just described. For example, for a device that originates digital signatures and is only capable of receiving and processing one particular type of biometric verification data, the identification marker includes the degree of match as well as the value of the DSFlag. Thus, if the sender of an EC had submitted a thumbprint, which was determined to have a 90% match, and if no digital signature had been generated, a suitable value of the identification marker is “90/0” (with the “/” merely to indicate the separation of the two values), with the value of “90” for Rb indicating the degree of match and the value of “0” for the DSFlag indicating that no digital signature had been generated since last receipt of verification data. Conversely, in the above example, if one or more digital signatures have been generated by the device since the thumbprint scan was submitted to the device, the identification marker would be “90/1” (or in the case of a counter, “90/x” where “x” is any number greater than 0).
- For devices capable of receiving multiple types of verification data input (Secret and/or biometric), it is preferable for each comparison result (R) for each type of verification data to have its own DSFlag. In this situation, every time a digital signature is originated, all of the DSFlags are set to one (or otherwise incremented as described above); however, each time additional verification data is received by the device, the DSFlag for that particular type of verification data is set to zero. For transmission of information to the electronic apparatus in this scenario, it is preferred to include the particular identifier, as discussed previously. Using the example from the previous section, a suitable identification marker appears as:
- 001,01,1,002,00,1,003,00,1,004,0.25,0,005,00,1,006,0.96,1, . . . 024,0.95,1
- This identification marker indicates a verification status in which a correct Secret was input, a right middle fingerprint had a 25% match, a right pinky fingerprint had a 96% match, a DNA scan had a 95% match, and the right middle fingerprint was entered since the last digital signature was generated by the device.
- Turning now to FIG. 27, a table illustrates a hypothetical series of actions (primarily inputs of different types of verification data) into a device of the present invention and the resulting change (if any) to the value of the identification marker. In this example, the device maintains a PIN, a digitized value for the right thumbprint (identifier=002) of an authorized user of the device, and a digitized version of the right retina (identifier=016) of an authorized user of the device. In addition, in this example, the identification marker (IM) of the device comprises the Rs value, the Rb(002) value, DSFlag(002) value, Rb(016) value, and DSFlag(016) value. The identification marker uses the two digit binary convention for the value of Rs (i.e., from
column 2510 from FIG. 25b), a two-digit percentage match convention for the values of Rb(002) and Rb(016) (fromcolumn 2602 from FIG. 26), and binary values for the DSFlag associated with each biometric verification data type. Thus, the DSFlag values are either “0”—indicating no generation of a digital signature or output of an indicator of the verification status since the particular type of biometric verification data was received, or “1”—indicating generation of a digital signature or output of an indicator since the particular type of biometric verification data was received. - A series of thirteen actions is illustrated in sequence in the first column of the table of FIG. 27. The impact of each of these actions upon the device and, more specifically, upon the identification marker of the device, which identifies the current verification status of the device, is shown horizontally across the remaining columns of the table. In the first action, the device is activated, turned on, or otherwise reset. This action causes each of the values that make up the identification marker to reset to their default values of zero, as shown. In the second action, an incorrect PIN is entered, which causes the value of Rs to change to “10.” A subsequent correct PIN entry into the device, switches the Rs value to “01.” The generation of a digital signature, output of the value of the identification marker, or other output of the verification status of the device causes the value of Rs to switch to “11” and both of the DSFlags to toggle to “1.” It should be noted that the value of Rs that was included within the output of the fourth action step was the “01” (from the previous row of the table, which was the “current” value of Rs at the time of the output). As illustrated by the fifth action, a second generation of a digital signature, output of the value of the identification marker, or other output of the verification status of the device has no effect upon the value of identification marker; however, it should be noted that the value of Rs and of the DSFlags will be different from the values that were output during the fourth action.
- A correct PIN input as the sixth action sets the value of Rs to “01,” but noticeably has no impact on the DSFlags for the right thumbprint and right retina. In the seventh action, a right thumbprint is provided to the device and results in an 85% match with the to prestored right thumbprint value. This causes the value of Rb(002) to be set to “85” and the value of DSFlag(002) to be set to “0.” In the eighth action, a right retina scan result is provided to the device and results in a 90% match with the prestored value. This causes the value of Rb(016) to be set to “90” and also the value of DSFlag(016) to be set to “0.”
- Still referring to FIG. 27, the ninth action is a third generation of a digital signature, output of the identification marker, or other output of the verification status of the device including the identification marker that was in effect after the eighth action, which causes Rs to switch to “11” and both of the DSFlags to toggle back to “1.” In the tenth action, a second right thumbprint is provided to the device, which results in an 88% match, which changes the value of Rb(002) to “88” and the value of DSFlag(002) to “0.” An incorrect PIN entry at this point, in the eleventh action, merely changes the value of Rs to “10.” In the twelfth action, the fourth generation of a digital signature, output of the identification marker, or other output of the verification status of the device causes DSFlag(002) to toggle back to “1” but has not effect upon the Rs value or upon the DSFlag(016) value, which is already set to “1.” In the thirteenth action, a second right retina provided to the device, which results in an 89% match, changes the value of Rb(016) to “89” and switches the value of DSFlag(016) back to “0.” In the fourteenth action (not specifically shown), a reset signal to the device resets all of the values back to those shown after the first action.
- Additional features and benefits of the present invention, including those relating to identification markers and indicators of verification status, will become apparent from the following discussions regarding specific devices and implementations of the present invention.
- 3. Computer Chip Design
- Turning now to FIG. 28, a
preferred computer chip 50 that may be used in conjunction with an IC card, PDA, cell phone, personal computer, or other device in accordance with the present invention is illustrated. As shown, thecomputer chip 50 receivespower 52, aclock input 54, and a reset or masterclear input 56 from anexternal source 90. Thecomputer chip 50 is also connected to ground 58 and exchanges input andoutput data 60 throughexternal source 90. Theexternal source 90 may be part of the IC card, PDA, cell phone, personal computer or other device in which thecomputer chip 50 is installed or it may be part of an I/O support element (not shown) with which the IC card, PDA, cell phone, personal computer, or other device is in communication, as the case may be. - Internally, the computer chip50 includes an I/O router 62, a central controller 64, a memory location 66 for securely storing a private key of a public-private key pair, a memory location 68 for storing the corresponding public key of the public/private key pair, a dedicated public/private key generator circuit 70, a private key destruction circuit 72, a memory location 65 for storing a default prestored message, a digital signature circuit 71 (which includes a hash function circuit 73, a random number generator 74, and an encryption circuit 75), a memory location 76 for prestoring data (Secret and/or biometric data), a selection multiplexer 78 for retrieving selected prestored data from memory location 76, a memory location 80 for storing various account and other user information, a selection multiplexer 82 for retrieving selected information from memory location 80, a memory location 83 for storing the current verification status (preferably in the form of an identification marker (IM)) of the computer chip 50, which includes the value of Rs (for the Secret) and the values for each Rb (for each biometric verification data type stored within the device 50) and the values for the DSFlags corresponding with the Rs and Rb values), and a selection multiplexer 84 for reading and writing to the memory location 83.
- Preferably, the
computer chip 50 is designed with the following capabilities: the ability to store data securely and permanently (especially the private key); the ability to create a public-private key pair on the chip on a one-time only basis using a random number produced within the chip from therandom number generator 74; and the ability to originate digital signatures, when requested, using a random number produced within the chip from therandom number generator 74 in accordance with FIPS PUB 186-2. Thecomputer chip 50 further preferably is resistant to tampering and is immune to Differential Power Attacks and other physical analysis. The prestored data for the Secret preferably also is protected from exhaustive search attacks. One method of “protecting” the private key is by designing thecomputer chip 50 with thedestruct circuit 72, which destroys the private key when triggered by any tampering or attempted theft of the private key by electronic, physical, and other known means. Under such circumstances, thedestruct circuit 72 renders thecomputer chip 50 useless by preventing thecomputer chip 50 from being able to generate further digital signatures and by destroying the information retained inmemory location 66. - Still referring to FIG. 28, the
computer chip 50 also includes non-modifiable operating software either loaded into the chip during manufacture or permanently etched into read-only memory (ROM) on thechip 50. Such software enables thecomputer chip 50 to respond to and act upon a specific set of commands. Such commands enable, for example, thecomputer chip 50 to be personalized. Personalization includes the input and prestoring of data for a Secret, a biometric characteristic, user name, and account number(s). Preferably, the prestored data for the Secret is capable of being changed, upon successful input of the current Secret verification data. The biometric prestored data, however, preferably is permanent once loaded into memory. - The software further includes a command that causes the
key generation circuit 70 to create a unique public-private key pair directly within thecomputer chip 50 on a one-time only basis. As stated previously, the private key is stored securely inmemory location 66. The public key is stored inmemory location 68. The software includes a command that enables the public key to be exported from thecomputer chip 50. The command to export the public key may be executable multiple times or one time only, depending upon whether strict control over access to the public key is desired. The software also includes a command that notifies thecomputer chip 50 that verification data is being input. Optionally, separate commands (or separate information included with the command) are used to indicate whether the verification data being input is for a Secret or a biometric characteristic and, if for a biometric characteristic, the biometric type. Preferably, thecomputer chip 50 also automatically identifies a verification status whenever it receives verification data. - The software further includes a command that notifies the
computer chip 50 that message data is being input. In many situations, it is necessary or desirable for the message data input or provided to thecomputer chip 50 to incorporate specific account information or other user data maintained inmemory location 80 on thecomputer chip 50. There are generally two techniques for extracting such information frommemory location 80 and including it within the message data sent to thecomputer chip 50. - In the first technique, all of the account and other user information is extracted from the
computer chip 50 and the user is prompted through a display to select the appropriate account or user information to be included as part of the message to be digitally signed using thecomputer chip 50. A message data command then is sent to thecomputer chip 50 for the origination of a digital signature, with the selected account or user information included in the message data. For example, when thecomputer chip 50 is used in an IC card in conjunction with a reader or other I/O support element, the I/O support element sends a command to thecomputer chip 50 for the extraction of all account and user information. The user then selects the appropriate account or user information from a display provided by the I/O support element to be included as part of the message to be digitally signed using thecomputer chip 50. Thereafter a message data command is sent to thecomputer chip 50 for the origination of a digital signature, with the selected account or user information included in the message data. - In the second technique, the message data command provided to the
computer chip 50 includes one or more “null fields” or other appropriate “tags” which identify a particular account field or user information field, but in which no value is supplied. In response to the tag, thecomputer chip 50 searches content addressable memory to identify a corresponding field maintained in memory. Upon location of the corresponding field, thecomputer chip 50 supplies the value of such field in the message data in substitution for the null value of the tag. With this methodology, each data cell containing account or user information inmemory location 80 has its own tag or content address. Preferably, such tags or content addresses are standardized so that account or user information can be correctly stored inmemory location 80 and easily retrieved using a tag when later needed. Such tags may include XML tags. - For example, a message data command could be sent to the
computer chip 50 in which the message data contains a null field or tag requesting that <user name> be inserted into a particular location within the text of the message data. Whenever such message data is provided to thecomputer chip 50, thecomputer chip 50 automatically completes the message data by inserting, in this case, the “user name” stored in the third cell ofmemory location 80 of thechip 50. Preferably, a tag could be used to extract and insert any of the various field values (e.g., credit card account number; banking account number; user name; employer account number; web site account number, etc.) maintained inmemory location 80 of thecomputer chip 50. - Once the message data is “completed” with all requested account and user information using one of the above techniques, such message data is then ready for: modification by the current verification status of the computer chip (using the value of IM); calculation of the hash value for the modified message data; encryption of the hash value to generate a digital signature; and output of the digital signature.
- Alternatively, the
computer chip 50 generates a digital signature in the same manner using a prestored message inmemory location 65—rather than imported message data—in response to a suitable command to generate a digital signature. - As will be appreciated, a computer chip including components and functionality described above, and which is used in providing a verification status in accordance with the present invention, is itself novel and nonobvious and, accordingly, such a computer chip indeed comprises an aspect of the present invention.
- 4. Specific Implementations of the Present Invention
- FIGS.29-33 (with frequent reference back to FIG. 28) illustrate how a
single IC card 95, configured to function in accordance with the present invention and containing a suitable computer chip 50 (such as described above with reference to FIG. 28), may be used in many different applications and settings by asuspect user 46 of theIC card 95. The structure of theIC card 95 is conventional in that it has thecomputer chip 50 embedded therein and surface contacts for enabling communication between an IC card reader and thecomputer chip 50 in theIC card 95. The surface contacts are ISO/IEC 7816 compliant. It is also possible to have an ISO/IEC 14443 compliant proximity card or a combination card capable of both 7816 and 14443 operations. - For purposes of these examples, it is assumed that the computer chip50 (as shown in FIG. 28) already contains a unique public/private key pair created in the manner previously described. It is further assumed that a PIN (the Secret in these examples) and digitized versions of the authorized user's right thumbprint, right retina, and voice print have been input and prestored in memory location 76 (
cells memory location 80 for access as needed using an appropriate tag contained within message data provided to theIC card 95 from an external source, as discussed above. Additionally, it is assumed that the public key stored on thecomputer chip 50 has been provided to the authorized user's employer, credit card account company, bank, and broker, each of which has, in turn, associated in its own database the public key with the authorized user's account. For purposes of the present examples, we will also assume that thecomputer chip 50 outputs the value for the identification marker (IM), which is a data string containing the value of Rs using the convention as set forth incolumn 2504 of FIG. 25a (i.e., no PIN (Rs=00), correct PIN and not used for IVS or DS (Rs=01), and incorrect PIN (Rs=10). The value for the identification marker further includes the type identifier (0xx) and the value of Rb (in the format of a two-digit percentage match (xx) as set forth incolumn 2602 of FIG. 26) for every biometric verification data type. Furthermore, the identification marker includes a respective DSFlag associated with the Rs value and with each Rb value. - Now, referring specifically to FIG. 29, a first example illustrates the
IC card 95 being used by thesuspect user 46. In this first example, thesuspect user 46 presents theIC card 95 to gain access to aparking area 2902. Theparking area 2902 is secured by aparking gate 2904, which has anarm 2906 and which is controlled by aparking gate controller 2908. In turn, theparking gate controller 2908 is in communication with anIC card reader 2910. Although shown as separate from theparking gate 2904, thecontroller 2908 and theIC card reader 2910 could, in fact, be physically installed within the housing of theparking gate 2904. - To get the
arm 2906 to lift, thesuspect user 46 inserts theIC card 95 into the reader 2910 (or positions the card near the reader in case of 14443 operations). As this is a relatively lowsecurity parking area 2902, theIC card reader 2910 does not have an associated keypad or biometric scanner; thus, there is no means by which thesuspect user 46 can input any verification data. Correspondingly, access to the parking area is not dependent upon any particular verification status of theIC card 95. Theparking gate controller 2908 opens theparking gate 2906 merely upon proper presentation of theIC card 95, which is pre-registered with theparking gate controller 2908. Preferably, pre-registration involves the authorized user of the card providing his name (“user name”) as retained in the memory 80 (as shown in FIG. 28) of thecomputer chip 50 to theparking gate controller 2908 or, conversely, having the operator of the parking gate 2904 (e.g., the authorized user's employer or agent) “approve” theIC card 95 for use with the parking gate system by inputting an employee account number into memory location 80 (as shown in FIG. 28) of thecomputer chip 50. For improved security, the authorized user of thecard 95 also provides his public key (retained on the chip 50) to theparking gate controller 2908, which associates the user's name or employee account number (hereinafter generally referred to as “user information”) therewith. - When the
IC card 95 is inserted into the card reader 2910 (or brought into proximity to the card reader 2910), thecard reader 2910 is initialized. Initialization of thecard reader 2910 is conventional and is accomplished either by thecard reader 2910 physically detecting anIC card 95, or by theIC card 95 outputting a “reset” message to thecard reader 2910 as part of its start-up protocol when it first receives power from thecard reader 2910. Once theIC card 95 receives power, the identification marker and all DSFlags for the PIN and each applicable biometric type are reset. Alternatively, all such values may be reset when power is removed from thecard 95. - Following initialization, the
card reader 2910 sends a message input command to theIC card 95. At a minimum, the message input command includes a tag requesting user information, such as “user name” or “employee account number” from the appropriate data field in memory location 80 (as shown in FIG. 28). In this example, there is no additional message data other than the tag. - Once the message input command is received by the
IC card 95, the computer chip 50 (as shown in FIG. 28) on theIC card 95 retrieves the requested user information from memory location 80 (as shown in FIG. 28), with such user information becoming part of the message data; retrieves the current value of the identification marker; modifies the message data with the value of the identification marker by pre-pending the value to the message data; calculates a hash value of the modified message data; encrypts the hash value to generate a digital signature; and exports the digital signature, requested user information, and value of the identification marker to thecard reader 2910, which forwards such data on to thecontroller 2908 for processing. - Thereafter, the
controller 2908 first compares the requested user information (name or employee account number) received from theIC card 95 with a list of authorized names or authorized employee account numbers maintained in its database. For low security having no regard for authentication, thecontroller 2908 opens theparking gate 2906 if the user information received from theIC card 95 matches one of the authorized names or authorized employee account numbers in its database. For higher security to guard against a counterfeit IC card, thecontroller 2908 decrypts the digital signature received from theIC card 95 using the public key associated with the matching user information. If the decrypted hash value from the digital signature matches a hash value calculated based on the user information (i.e., message data) provided by theIC card 95, as modified by the value of the identification marker received from theIC card 95, then thecontroller 2908 determines that theIC card 95 from which the digital signature is received contains the unique private key associated with the user who pre-registered with the operator of theparking gate 2904, and lifts theparking gate arm 2906—the decision in this case to raise the gate being based on Factor A Entity Authentication. - Turning now to FIGS. 30 and 31, the
same IC card 95 may be used by thesuspect user 46 first to gain access intosecure building 3002 and then intosecure room 3102, which is located within thesecure building 3002. As shown in FIG. 30, oneIC card reader 3004 is mounted next to thesecure entrance 3010 into thebuilding 3002. ThisIC card reader 3004 includes analphanumeric keypad 3006 and adisplay screen 3008. TheIC card reader 3004 is in electronic communication with abuilding security controller 3014, which controls thelocking mechanism 3012 of theentrance 3010. Inside the building, as shown in FIG. 31, anotherIC card reader 3104 is mounted on the wall next to securedoor 3110. ThisIC card reader 3104 includes aretina scanner 3106 and adisplay 3108. Likewise, thisIC card reader 3104 is in electronic communication with thebuilding security controller 3114, which controls thelocking mechanism 3112 of thedoor 3110. If the parking area 2902 (from FIG. 29) is part of the same facility assecure building 3002, it is possible thatparking gate controller 2908 andbuilding security controllers IC card 95. - First, with regard to FIG. 30, for access into the
secure building 3002, theIC card 95 is inserted into the IC card reader 3004 (or brought into proximity to the card reader 3004). Thereader 3004 is initialized in much the same way as thecard reader 2910 in FIG. 29. The identification marker and all DSFlags are reset when power is first supplied to theIC card 95. - Once initialized, the
card reader 3004, using thedisplay 3008, prompts thesuspect user 46 to input a PIN. Once the PIN is entered using thekeypad 3006, thecard reader 3004 transmits the same, not to thebuilding security controller 3014, but directly to theIC card 95. - Once the
IC card 95 receives the PIN verification data, thecontroller 64 on the computer chip 50 (as shown in FIG. 28) retrieves the prestored PIN data from memory location 76 (cell 001) and compares the two values (Factor B Entity Authentication). A match/no-match determination is made by thecontroller 64, which identifies the verification status as either Rs=01 (match) or Rs=10 (no match). - After a suitable but brief delay, which is programmed into the controls of the
card reader 3304, thecard reader 3004 sends a message input command to theIC card 95. As was described previously in relation to FIG. 29, the message input command includes a “tag” requesting user information (e.g. “user name” or “employee account number”) from the appropriate data field in memory location 80 (as shown in FIG. 28). Again, it is assumed that the message data comprises the tag only and no additional information. - Once the message input command is received by the
IC card 95, thecomputer chip 50 on theIC card 95 retrieves the requested user information from memory location 80 (as shown in FIG. 28); retrieves the current value of the identification marker; modifies the user information (i.e., message data) with the value of the identification marker by pre-pending the value to the user information; calculates a hash value of the modified user information to generate a digital signature; encrypts the hash value; and exports the digital signature, requested user information, and value of the identification marker to thecard reader 3004. The computer chip 50 (as shown in FIG. 28) then increments the value of all of the DSFlags to “1”. Equivalently, thecomputer chip 50 only increments the value of the DSFlags to “1” for the specific verification data types for which any verification data input has been received since powering on of thecard 95. - The digital signature, value of the identification marker, and user information received by the
card reader 3004 are communicated to thebuilding security controller 3014. Thebuilding security controller 3014 first confirms that the user information matches either an authorized name or an authorized employee account number for access to thebuilding 3002. If so, thebuilding security controller 3014 then decrypts the digital signature using the public key associated with the matching authorized user information. If the decrypted hash value from the digital signature matches a hash value calculated based on the user information received from theIC card 95, as modified by the value of the identification marker received from theIC card 95, then thebuilding security controller 3014 determines that theIC card 95 from which the digital signature is received contains the unique private key. Finally, thebuilding security controller 3014 checks the verification status indicated by the value of the identification marker to determine whether thesuspect user 46 of theIC card 95 is in fact the authorized user of theIC card 95. If the indicated verification status represents a match (i.e., value of Rs=01), thebuilding security controller 3014 infers that thesuspect user 46 is the authorized user, and then sends a signal to thelocking mechanism 3012 to unlock the entrance and/or open thedoor 3010. - For access into the
secure room 3102 of FIG. 31, theIC card 95 is inserted into the IC card reader 3104 (or brought into proximity to the card reader 3104). Thereader 3104 is initialized in much the same way as thecard reader 3004, with the identification marker and all DSFlags being reset when power is first supplied to theIC card 95. Once initialized, thecard reader 3104, using thedisplay 3108, prompts thesuspect user 46 to place his right eye before thescanner 3106. Theretina scanner 3106 scans the right eye of thesuspect user 46 and obtains a digitized version thereof. Thecard reader 3104 then transmits the biometric verification data (which includes an identifier and a value of the digitized scan of the right retina), not to thebuilding security controller 3114, but to theIC card 95 for comparison. - Once the biometric verification data is received by the
IC card 95, the controller 64 (as shown in FIG. 28) determines the type of biometric verification data received (based on the identifier), retrieves the corresponding prestored biometric data for the authorized user's right retina from memory location 76 (cell 016), and compares the two values (Factor C Entity Authentication). A degree of match determination/calculation is made by thecontroller 64, which sets Rb(016) to a two-digit number corresponding with the percentage match (again, as shown in FIG. 28). - After a suitable but brief delay, the
card reader 3104 sends a message input command to theIC card 95. As was described previously, the message input command includes a tag requesting user information from the appropriate data field inmemory location 80. Again, it is assumed that the message data comprises the tag only and no additional information. - Once the message input command is received by the
IC card 95, thecomputer chip 50 on theIC card 95 retrieves the requested user information frommemory location 80; retrieves the current value of the identification marker (including therein the value of Rb(016) and the value of the DSFlag(016), which was reset to zero when the card was inserted into the card reader 3104); modifies the user information with the value of the identification marker by pre-pending the value to the user information, calculates a hash value of the modified user information; encrypts the hash value to generate a digital signature; and exports the digital signature, requested user information, and value of the identification marker to thecard reader 3104. Thecomputer chip 50 then increments the value of all of the DSFlags to “1.” - The digital signature, user information, and value of the identification marker received from the
IC card 95 are then communicated by thecard reader 3104 to thebuilding security controller 3114. Thebuilding security controller 3114 first confirms that the user information received from theIC card 95 matches an authorized user name or employee account number for access to theroom 3102. If so, thebuilding security controller 3114 then decrypts the digital signature using the public key associated with the matching user information. If the decrypted hash value from the digital signature matches a hash value calculated based on the user information received from theIC card 95, as modified by the value of the identification marker received from theIC card 95, then thebuilding security controller 3114 determines that theIC card 95 from which the digital signature is received contains the unique private key. Finally, thebuilding security controller 3114 checks the verification status indicated by the value of the identification marker to determine whether thesuspect user 46 is in fact the authorized user of theIC card 95. In this regard, if the degree of match between the value for the scanned retina and the prestored value for the retina of the authorized user meets a threshold requirement (e.g. 90% match or better) set by thebuilding security controller 3114, then thebuilding security controller 3114 infers that thesuspect user 46 is the authorized user and sends a signal to thelocking mechanism 3112 to unlock and/or open thedoor 3110. - The
building security controller 3114 may include business logic that denies access to theroom 3102 if there is a “perfect” or 100% match between the scanned retina and the prestored retina, since such a comparison likely indicates a fraudulently input verification data. If the degree of match received from thecard 95 does not exceed the required threshold set by thebuilding security controller 3114 for thisroom 3102, an additional retina scan may be requested and the above procedure repeated. If theIC card 95 was not removed from thecard reader 3104, and if theIC card 95 generates a digital signature before a new retina scan is taken or successfully transmitted into theIC card 95, the verification status output by thecard 95 will include the DSFlag for the right retina set to a value of “1,” which signals thebuilding security controller 3114 that a new retina scan was not input or correctly received by theIC card 95. When a new retina scan is taken and transmitted to theIC card 95, the DSFlag for the right retina (DSFlag(016)) is reset to zero. Since retina scans of the same eye will generally vary slightly with each scan (as do most scans of other types of biometric information), thebuilding security controller 3114 will be alert to the potential of a fraudulent biometric verification data received by theIC card 95 when a new degree of match determination is exactly identical to a previous determination for the same biometric characteristic from thesame IC card 95. - Even if the initial degree of match received from the
card 95 exceeds the required threshold set by thebuilding security controller 3114 for thisroom 3102, thebuilding security controller 3114 may nevertheless request a follow-up retina scan from thesuspect user 46 simply for the purpose of determining if the biometric input was fraudulent (i.e., is the follow-up degree of match identical to the initial degree of match?). Thebuilding security controller 3114 may also include business logic that denies access to theroom 3102 if there is a “perfect” or 100% match between the scanned retina and the prestored retina, since such a comparison also likely indicates a fraudulently input verification data. Referring to FIG. 32a, thesuspect user 46 now sits at his desk to access hispersonal computer 3202. Thecomputer 3202 is conventional in that it includes akeyboard 3204, amonitor 3206, and amouse 3208. Thecomputer 3202 also includes acard reader 3210, which exchanges data with thecomputer 3202 through a suitable port (e.g., serial, parallel, USB, etc.) of thecomputer 3202. Thecard reader 3210 is similar to those discussed above and is capable of exchanging information with anIC card 95 when inserted therein (or brought within proximity thereof. In the present example, thecomputer 3202 also includes amicrophone 3212 for receipt of audio input, such as the voice of thesuspect user 46. Although it is possible to prevent thecomputer 3202 from powering on without aproper IC card 95 inserted into thecard reader 3210, the present example assumes that thecomputer 3202 will power on and “boot up” to a security screen (using suitable software installed on the computer 3202), but that no substantive access, such as to programs or databases maintained on, or to the operating system of, thecomputer 3202 is enabled until thesuspect user 46 is authenticated. Alternatively, thebuilding security controller 3114 may also request additional PIN and/or bio input if there suspicion of fraudulent input. - After powering on, the
computer 3202 prompts, on a security screen displayed on themonitor 3206, thesuspect user 46 to insert theIC card 95 intocard reader 3210, to enter a PIN into a suitable data entry window also displayed on the screen, and to state (audibly) his name—first name, middle initial, and last name—for the purpose of obtaining a voiceprint. - When the
IC card 95 is inserted into thereader 3210, thereader 3210 is initialized (as described previously) and the power supplied to thecard 95 causes the identification marker and all of the DSFlags on thecomputer chip 50 to be reset. Once the PIN has been entered using thekeyboard 3204 and once thesuspect user 46 states his name into themicrophone 3212, thecomputer 3202 transmits both the PIN and a digitized version of the voiceprint, via thecard reader 3210, to theIC card 95. Thecard reader 3210 transmits the value of the PIN and digitized voiceprint along with an identifier (e.g., 001 for the PIN and 020 for the voiceprint) for each to identify to thecard 95 the type and order of the verification data input. - Upon receipt of the PIN and biometric verification data by the
IC card 95, thecontroller 64 on the computer chip 50 (referring back to FIG. 28) first determines the type of verification data received based on the identifiers and then retrieves the appropriate prestored data frommemory location 76. In this example, thecontroller 64 first retrieves the prestored data for the PIN from memorylocation data cell 001 inmemory location 76, and then compares the value with the value of the PIN verification data received from the card reader 3210 (Factor B Entity Authentication). A match/no-match determination is made by thecontroller 64, which sets the value of the Rs as either “01” (match) or “10” (no match). Next, thecontroller 64 retrieves the prestored data for the authorized user's voiceprint fromdata cell 020 inmemory location 76, and then compares this value with the digitized voiceprint received from the card reader 3210 (Factor C Entity Authentication). A degree of match determination/calculation is made by thecontroller 64, which sets the value of Rb(020) to a two-digit number corresponding to the percentage match. - After a suitable but brief delay, the
computer 3202 then sends a message input command to theIC card 95 via thecard reader 3210. In this case, the message input command includes a tag requesting user information from the appropriate data field in memory location 80 (again, as shown in FIG. 28). Again, it is assumed that the message data comprises the tag only and no additional information. - Once the message input command is received by the
IC card 95, thecomputer chip 50 on theIC card 95 retrieves the requested authorized user information (as the message data) frommemory location 80; retrieves the current value of the identification marker (which includes the value of Rs and the value of DSFlag(001), which was reset to zero when the card was inserted into thecard reader 3210, and which also includes the value of Rb(020) and the value of the DSFlag(020), which was also reset to zero), modifies the message data with the identification marker by pre-pending the value to the message data, calculates a hash value of the modified message data, encrypts the hash value to generate a digital signature, and exports the digital signature, requested user information, and value of the identification marker to thecard reader 3210. Thecomputer chip 50 then increments the value of all of the DSFlags on thecomputer chip 50 to “1” (at a minimum, the DSFlags for the PIN and for the voiceprint, namely DSFlag(001) and DSFlag(020), are incremented to “1”). - The digital signature, user information, and value of the identification marker received by the
card reader 3210 are then communicated to thecomputer 3202 for processing. If thecomputer 3202 is a stand-alone computer, processing is performed within thecomputer 3202 itself. More likely, however,computer 3202 will be networked and in communication with a server (not shown), which will actually determine whether thesuspect user 46 will gain access to thecomputer 3202. - Assuming a server is involved, the server first confirms that the user information received from the
IC card 95 matches an authorized user name or employee account number for access to and use of thespecific computer 3202. The server then decrypts the digital signature using the public key associated with the matching user information. If the decrypted hash value from the digital signature matches a hash value calculated based on the user information received from theIC card 95, as modified by the value of the identification marker received from theIC card 95, then the server determines that theIC card 95 from which the digital signature is received contains the unique private key. Finally, the server checks the verification status indicated by the value of the identification marker to determine whether thesuspect user 46 is in fact the authorized user of theIC card 95. This is a two-step process since two different types of verification data have been received by theIC card 95 and used to identify the verification status of thecard 95. In the first step, if the value of Rs is “01” (match), then the server infers that thesuspect user 46 is the authorized user. In the second step, the server uses business logic or a rule base to determine if the voiceprint provided by thesuspect user 46 is sufficiently similar to the voiceprint of the authorized user stored on theIC card 95 so as to infer again that thesuspect user 46 is the authorized user. - The business logic and rule base of the server may be programmed to accept varying combinations of Rs and Rb values (PIN and voiceprint) to infer that the
suspect user 46 is the authorized user. For example, a correct PIN by itself, a correct PIN plus at least a 70% match of voiceprint, an incorrect PIN if the voiceprint exceeds 95%, and an incorrect PIN but two voiceprints exceeding 90% are all different types of verification statuses that may be sufficient for the server to infer that thesuspect user 46 is the authorized user and grant access to thecomputer 3202. Obviously, the business logic or rule base can vary widely, depending upon the necessary security desired. - Turning now to FIG. 32b, the
IC card 95 may also be used by thesuspect user 46 in accessing a secure website over an insecure network, such as theInternet 3222. In this further example, we will assume that thesuspect user 46 is accessing thesecure website 3224 of hisbroker 3220, with whom he already has an established account. Thebrokerage company 3220 that operates thewebsite 3224 already has the authorized user's public key from theIC card 95 stored in itsaccount database 3225 and associated with the authorized user's account. We will also assume that thesuspect user 46 is accessing thewebsite 3224 usingcomputer 3202 from FIG. 32a and that thecard 95 has not been removed from thecard reader 3210 since it was used to gain access to thecomputer 3202; thus, the DSFlags remain set to “1”. - When accessing the
website 3224, thesuspect user 46 enters a user ID in a login screen for the website. The user ID enables thebrokerage company 3220 readily to locate the appropriate account of the user, as is conventional. However, rather than encrypting the user ID together with a password and then sending the encrypted information over the Internet, thecomputer 3202 sends the user ID to theIC card 95 via thecard reader 3210. The process by which thewebsite 3224 instructs thecomputer 3202 to send the user ID to theIC card 95 rather than directly over the Internet to thewebsite 3224 is beyond the scope of this invention; however, it may be readily accomplished in several different manners. In one example, thewebsite 3224 has a dedicated login page for use only by users having a suitable IC card 95 (or other device of the present invention), in which case, entry of the user ID into such login page automatically instructs thecomputer 3202 to send the user ID to theIC card 95 for processing. Alternatively, the login page for thewebsite 3224 could enable the user to select a conventional login using an ID and password or to login using hisIC card 95. In either of the above examples, the user ID could actually be prestored in a “cookie” in memory on thecomputer 3202, as is conventional, which would enable the user merely to click one button on the login page of thewebsite 3224, which causes thecomputer 3202 to send the user ID to theIC card 95. - Once a message input command comprising the user ID is received by the
IC card 95, thecomputer chip 50 on theIC card 95 retrieves the current value of the identification marker, modifies the user ID received from thecard reader 3210 with the value of the identification marker by pre-pending the value to the user ID, calculates a hash value of the modified user ID, encrypts the hash value to generate a digital signature, and returns the digital signature and the value of the identification marker to thecomputer 3202 via thecard reader 3210. In this case, the values of the DSFlags are not incremented since they are already set to a value of “1.” - The user ID, the digital signature, and value of the identification marker then are communicated in an EC by the
computer 3202 over theInternet 3222 to thewebsite 3224 for processing. Computer programming associated with thewebsite 3224 first confirms that thesuspect user 46 maintains an account with the brokerage company by matching the user ID with an account. If an account with a matching user ID is found, then the computer programming next decrypts the digital signature using the public key associated with the identified account. If the decrypted hash value from the digital signature matches a hash value calculated based on the user ID received from theIC card 95, as modified by the value of the identification marker received from theIC card 95, then it is determined that theIC card 95 from which the digital signature is received contains the unique private key corresponding with the account of the user. Finally, the computer programming associated with thewebsite 3224 checks the verification status indicated by the value of the identification marker to determine whether thesuspect user 46 is in fact the authorized user of theIC card 95. - Preferably, the computer programming extracts only the value of the Rs from the value of the identification marker for initial evaluation. If the value of Rs is “00” (no PIN input), then the
website 3224 sends a request data back to thecomputer 3202 requesting input of the user's PIN. If the value of Rs is “10” (incorrect PIN), then thewebsite 3224 sends a request for thesuspect user 46 to reenter the PIN. In either case, a suitable screen is displayed on themonitor 3206 of thecomputer 3202 to enable thesuspect user 46 to enter the PIN. It should again be emphasized that such PIN will be transmitted by a keyboard of thecomputer 3202 to thecard 95 but not transmitted over theInternet 3222. If the value of Rs is “01” (correct PIN), then thewebsite 3224 infers that thesuspect user 46 is in fact the authorized user and grants access to thewebsite 3224. Thus, for mere access to thewebsite 3224, it is not necessary that the PIN be entered just prior to the generation of the digital signature for the user ID—previous entry of a correct PIN is satisfactory for access to thewebsite 3224. - On the other hand, if after perusing the
website 3224, the “now-authorized” user requests a transaction, such as purchase of stock, then thewebsite 3224 transmits a detailed confirmation of the requested transaction and specifically requests entry of a PIN to confirm specific approval for the purchase order. Once the PIN has been input by thesuspect user 46, thecomputer 3202 provides the same to theIC card 95. - Upon receipt of the PIN, the
controller 64 first retrieves the prestored data for the PIN from memorylocation data cell 001 inmemory location 76 and compares it with the PIN received from thecomputer 3202. A match/no-match determination then is made by thecontroller 64, and the value of Rs is set to either “01” representing a match or to “10” representing a failed match, and the DSFlag(001) also is set to “0”. - After a suitable but brief delay, the
computer 3202 then sends a message input command (which contains the purchase order) to theIC card 95. Thecomputer chip 50 on theIC card 95 retrieves the current value of the identification marker (including therein the value of Rs and DSFlag(001)); modifies the message data received from thecomputer 3202 with the value of the identification marker by pre-pending the value to the message data; calculates a hash value of the modified message data; encrypts the hash value to generate a digital signature; and exports the digital signature and value of the identification marker to thecomputer 3202, which then forwards the same on to thewebsite 3224. Thecomputer chip 50 then increments the value of all of the DSFlags to “1.” In this example, thewebsite 3224 will only approve the requested transaction when the value of the identification marker includes therein a value of Rs of “01” and a value of DSFlag(001) as “0”. - If desired, the communication between the
computer 3202 and thewebsite 3224 may be performed using a Secure Socket Layering (SSL) protocol, as is conventional. Such a protocol is set forth, for example, in U.S. Pat. No. 5,848,161, which is incorporated herein by reference. In such protocol, it is customary for thecomputer 3202 to generate a random number for use in creating a session key for the SSL communication. In accordance with a further feature of the present invention, theIC card 95 is used for the provision of the random number for creation of the session key. In particular, a digital signature is originated by theIC card 95 and used as the random number itself for the purpose of creating the session key. An indirect result of the DSA and ECDSA specified in FIPS PUB 186-2 is that the resulting digital signature itself is a random number. A session key for communication using pretty good privacy (PGP) encryption also may be created based on the digital signature of theIC card 95. - Turning now to FIG. 33, use of the
IC card 95 at a point of sale location is illustrated. A point ofsale card reader 3308 includes analphanumeric keypad 3310, adisplay 3314, and, in this case, athumbprint reader 3312. The point ofsale card reader 3308 is in communication viadata connector 3306 with a merchant cash register/terminal 3302, which has itsown display 3304. The point ofsale card reader 3308 is also in communication over an insecure network, such as theInternet 3322, with abanking authority 3320. Thebanking authority 3320 is either a financial institution that maintains a banking or credit card account on behalf of the authorized user of theIC card 95 or is an authorized approval agent or clearance authority for such a financial institution. In either case, thebanking authority 3320 maintains a database 3325, which associates the public key of thecard 95 with the corresponding account of the authorized user of theIC card 95, and has the authority to approve or disapprove online transactions requested against such account. - When an item is purchased by the
suspect user 46, the merchant “rings up” the item on the merchant cash register/terminal 3302 and the total balance due is displayed to thesuspect user 46 on thedisplay 3304. To pay, thesuspect user 46 inserts theIC card 95 into the point of sale card reader 3308 (or brings theIC card 95 into proximity to the card reader 3308). Upon insertion (or approach), the point ofsale card reader 3308 is initialized in a manner similar to the card readers previously described. The identification marker and all the DSFlags on thecomputer chip 50 of theIC card 95 are reset when power is first supplied to thecard 95 by the point ofsale card reader 3308. - Next, the merchant cash register/terminal3302 transmits the balance due to the point of
sale card reader 3308 viadata connector 3306. The point ofsale card reader 3308 displays the balance due ondisplay 3314. In one embodiment, thedisplay 3314 also prompts thesuspect user 46 to select whether he wants to pay using either a debit account or a credit card account. In an alternative embodiment, the point ofsale card reader 3308 sends a “retrieve account information” command to theIC card 95, which returns a list of all available checking, credit card, or other accounts maintained inmemory location 80 on thecomputer chip 50 from which payment may be made. In this alternative embodiment, thedisplay 3314 prompts thesuspect user 46 to select one of the retrieved accounts for payment. Thedisplay 3314 next prompts thesuspect user 46 to enter a PIN using thealphanumeric keypad 3310 and to place his right thumb on thethumbprint scanner 3312. Once the PIN and thumbprint have been input, the point ofsale card reader 3308 transmits both the PIN and a digitized version of the thumbprint to theIC card 95. Thecard reader 3308 transmits the value of the PIN and digitized thumbprint along with an identifier (e.g., 001 for the PIN and 002 for the thumbprint) for each so that thecard 95 “knows” the type and order of the verification data input. - Upon receipt of the PIN and digitized version of the thumbprint by the
IC card 95, thecomputer chip 50 on thecard 95 identifies the verification status of theIC card 95 in the manner previously described. After a suitable but brief delay, the point ofsale card reader 3308 then sends a message input command to theIC card 95. In this case, the message input command includes message data comprising a receipt for the item purchased, the total balance due, and the payment account specified by thesuspect user 46. In the first embodiment, the account would be retrieved from memory location 80 (on the computer chip 50) and inserted into the message data using a suitable “tag,” indicating whether the primary debit account or primary credit card account number should be used. In the alternative embodiment, the account number for the account specifically selected by thesuspect user 46 from the list of available accounts displayed ondisplay 3314 is included in the message data received from thecard reader 3308. - Once the message input command is received by the
IC card 95, thecomputer chip 50 on theIC card 95 retrieves the current value of the identification marker (including therein the value of Rs and DSFlag(001), and including therein the values of Rb(002) and DSFlag(002)), modifies the message data received from the point ofsale card reader 3308 with the value of the identification marker by pre-pending the value to the message data, calculates a hash value of the modified message data, encrypts the hash value to generate a digital signature, and exports the digital signature and value of the identification marker to the point ofsale card reader 3308. Thecomputer chip 50 then increments the value of all of the DSFlags to “1.” The digital signature, value of the identification marker, and message data (including account number and amount of the purchase) are then communicated by the point ofsale card reader 3308 tobanking authority 3320 for processing. - The
banking authority 3320 first confirms that the specified account number is a valid account number. Thebanking authority 3320 then decrypts the digital signature using the public key associated with the identified account number in the database 3325. If the decrypted hash value from the digital signature matches a hash value of the message data, as modified by the value of the identification marker received from theIC card 95, then it is determined that theIC card 95 from which the digital signature is received contains the unique private key and that the message data containing the receipt and total balance due has not been modified since it was digitally signed. - Next, the
banking authority 3320 checks the verification status indicated by the value of the identification marker provided by theIC card 95 to determine whether thesuspect user 46 is in fact the authorized user of theIC card 95. This is a two-step process as two different types of verification data are received by theIC card 95 and used to identify the verification status of theIC card 95. In the first step, if the value of Rs is “01” (match), then thebanking authority 3320 infers that thesuspect user 46 is the authorized user. In the second step, thebanking authority 3320 uses business logic or a rule base to determine if the thumbprint provided by thesuspect user 46 is sufficiently similar to the thumbprint of the authorized user stored on thecard 95 so as to infer again that thesuspect user 46 is the authorized user. - The business logic and rule base of the
banking authority 3320 is such that it may rely upon varying combinations of values for Rs (PIN) and Rb(002) (thumbprint) in accepting thesuspect user 46 as the authorized user. For example, a correct PIN by itself, a correct PIN plus at least a 60% match of thumbprint, an incorrect PIN if the thumbprint exceeds 96%, and an incorrect PIN but two thumbprints exceeding 90% (but not identical) are all different types of verification statuses that may be sufficient for thebanking authority 3320 to accept Factors B and C Entity Authentication of thesuspect user 46 by thecard 95. - Finally, if the specified account has a sufficient balance or credit to cover the requested purchase amount and there are no other factors (e.g. card reported stolen, duplicate request, etc.) that would warrant refusal of the transaction, the
banking authority 3320 grants approval of the transaction and transmit confirmation of the same back to the point ofsale card reader 3308. Obviously, the business logic, rule base, and other factors that are taken into consideration by thebanking authority 3320 can vary widely, depending upon the necessary level of security desired by thebanking authority 3320. - 5. Additional Security and Privacy Measures
- a. Protecting Against Fraudulent Displays
- A risk of using a device, such as the
IC card 95, in conjunction with the example given in FIG. 33 is the fact that the user of theIC card 95 must rely upon thedisplay 3314 of thecard reader 3308, which is under the control of the point of sale merchant, to present an actual representation of the message displayed for generating a digital signature with theIC card 95. It is possible for an unscrupulous merchant, for example, to display a purchase price of one amount but have the message data that is transmitted by thecard reader 3308 to theIC card 95 to have a higher purchase price. To minimize the risk of such fraud, it is preferable for thecomputer chip 50, described in FIG. 28, to be installed in a more sophisticated device, such as a PDA or cell phone, which has its own display (presumably under the control of the owner of the device). Since a PDA or cell phone could be programmed to display the full text of message data accurately prior to the generation of a digital signature thereof with the device, it would be more difficult for a merchant to “present” one purchase price to the customer but actually have a different purchase price included within the message to be digitally signed. - b. Protecting Account Information
- Unlike an
IC card 95, a PDA or cell phone also provides the user with much greater flexibility and privacy. For example, continuing with the illustration from FIG. 33, rather than having the point ofsale reader 3308 prompt the user to select from only a limited number of primary payment accounts, a PDA or cell phone enables the user to store and select from all payment accounts stored on the device. In addition, rather than having the point ofsale reader 3308 actually retrieve all available payment accounts from theIC card 95, which potentially raises some privacy concerns, a PDA or cell phone allows the user to select an account from a list presented by the device and not by the point of sale merchant. Thus, the point of sale merchant never becomes privy to the list of account numbers maintained by the device. - c. Protecting Against Replay Attacks
- In all of the examples illustrated in FIGS.29-33, the party receiving the digital signature generated by the
IC card 95 is potentially subject to a replay attack. A replay attack occurs when an original digital signature from a device is copied and then reused in an unauthorized manner. Since both the original and copy of a digital signature will decrypt with the appropriate public key, the party receiving the digital signature needs to have some way of distinguishing between the original and a later copy. - To prevent the acceptance of recorded digital signatures, it is merely necessary for the party guarding against the replay attack to include a random number or unique message (e.g., time of day, date, and counter combination) as part of each message input command sent to a device for originating a digital signature and require that the random number or unique message be included in what is digitally signed. The party receiving back the digital signature thereby is able to confirm, upon Message Authentication, that the digital signature received from the device was actually generated by the device in direct response to the corresponding message input command. Such techniques are set forth, for example, inFederal Information Processing Standards Publication 196, Entity Authentication Using Public Key Cryptography, US DOC/NBS, Feb. 18, 1997 (hereinafter “FIPS PUB 196”), which is incorporated herein by reference and which is available for download at http://csrc.nist.gov/publications/fips.
- For applications in which the party receiving the digital signature (e.g., a card reader or associated controller) is involved in only one authentication session at any given time and when a response is expected substantially contemporaneously (e.g. while the device is in or near a reader), it is only necessary to maintain the random number or unique message in computer memory long enough to ensure that the digital signature received back within the expected time interval contains the appropriate random number or unique message. This random number or unique message is good for only one digital signature and it is assumed that the first digital signature received by the party is the original and that subsequent identical digital signatures, if any, are fraudulent copies and handled as such.
- For applications in which the party receiving the digital signature is involved in more than one authentication session at any given time, such as, for example, a website that is entertaining simultaneous requests from multiple users for entry to the site and/or for transactions through the site, it is necessary for the party to maintain a log of all random numbers or unique messages that have been sent out to all devices for the generation of digital signatures. It is also necessary for the party to link or otherwise associate each such random number or unique message with the particular session in which it is used. Thus, when a digital signature is received back within a particular session, the party can confirm that the correct random number was received and digitally signed for such session
- The generation of random numbers may be performed, for example, using any of the random number generators specified in
appendix 3 of FIPS PUB 186-2. - From the above description, it will be understood and appreciated that a secure chip manufactured to operative in accordance with the present inventions may sign a computed SHA-1 hash on the data transmitted to the chip for signature, even if the transmitted data is itself already a hash value. A “double” SHA-1 leaves no ambiguity regarding whether the consumer's MDS device was presented the raw data stream, computed the SHA-1, and signed it, or whether the device was presented a precomputed SHA-1.
- It will also be appreciated that in the preferred embodiments of the invention, the digital signature is always in accordance with the digital signature standard (DSS), i.e., a new random number is computed for every digital signature operation. Thus, even consecutive signing of the same exact data will always result in different DSS results.
- It will also be understood that the basic functions of a secure chip constructed in accordance with the invention comprises one or more of the following functions:
- Generate key-pair
- This operation is normally “latched” by discrete latching components or circuits so that it is only performed once per chip. Care should be taken to handle the situation where the latch is reset if the chip has been zeroized. Preferably, when latched, subsequent execution of this function returns an invalid indication.
- Export public key
- Preferably, the private key is never available outside of the signing environment.
- However, for some applications the public key needs to be exported after initial generation. This operation may be optionally latched to minimize vulnerability to brute-force attacks. Preferably, when latched, subsequent execution of this function returns an invalid indication.
- Perform DSS signature
- A data stream is provided to the digital signature signing environment, in response to which the secure chip performs a SHA-1 on the data stream and then signs the calculated SHA-1. Procedures for doing streaming SHA-1 calculations are preferably verified (i.e. a mechanism is preferably provided for calculating SHA-1 on a data stream larger than local available memory. Accordingly, the preferred secure chip may include optional service enhancements for additional operations as part of signing a data stream.
- For PIN-activated devices (Factor B Entity Authentication) constructed in accordance with the invention, one or more of the following functions may be provided:
- Initialize PIN
- Personalization services may ship an uninitialized PIN card to a consumer. It is specifically contemplated that there can be a combination process where the consumer both initializes the device PIN for the first time and activates use of their device with their service provider and/or financial institution.
- Enter PIN
- For PIN-activated devices, preferably entering a PIN will enable the operation of the digital signature function. To address brute-force offline attacks, the digital signature function will preferably always return a reasonable result, regardless of whether the correct PIN has been entered, an incorrect PIN has been entered, or no PIN has been entered. This is an important issue to take into consideration, because the normal range of PIN values in many consumer applications are four digits, which is readily susceptible to an offline brute-force attack on a stolen device (i.e., it is computationally easy to mount a brute force attack on a device that only provides approximately 2**10 possible values).
- For biometric-activated devices (Factor C Entity Authentication) constructed in accordance with the invention, one or more of the following functions may be provided:
- Initialize biometric
- Similar considerations to those discussed above in connection with “Initialize PIN” are applicable here as well.
- Enter Biometric
- Similar to the Enter PIN function described above. Biometric features with >2**100 possible values are less prone to brute force offline attacks, so some of attack considerations for PINs might not apply.
- In considering PIN offline brute force attacks, a stolen PIN-only activated device is susceptible to brute-force offline attacks, especially when the range of possible values is <2*100). To thwart this attack, it is preferred to construct the secure chip so that there will be no obvious differentiation between digital signature results using incorrect or correct PINs (i.e., digital signature operations when activated with an invalid PIN should be invalid in non-obvious ways). Since DSS is used in preferred embodiments of the invention, even consecutive signatures on the same data using valid PINs are not the same, so all signature results should be different regardless of what PIN is used).
- One way that an attacker can distinguish valid signatures from invalid signatures is if the attacker possesses the public key and can directly verify the signature. (To thwart this mechanism, users may of course choose to not make the public key readily available.) A simple method for generating an apparently good signature when a bad PIN has been entered is to modify the raw data as its SHA-1 is being calculated, and then generate a valid signature using the private key. This can be done in a random way and/or in a very predictable way. Those skilled in the art will understand that to support future Internet and POS transaction environments the X9.59 transaction format may be employed for transactions that are generated using the processes and systems of the present invention. Those skilled in the art will appreciate that the present invention may be employed in conjunction with the presently defined
version 0 X9.59 ASN.1 encoded signed format, and with the contemplatedversion 1 X9.59 signed format that uses all the same fields asversion 0 but with the emerging XML format (e.g. with FSML deterministic encoding considerations).The same process can be used to implement specialized support for other types of tagged objects, adding information to be singed from data previously saved in the device for this purpose. - For an XML X9.59 implementation, when the raw data stream is transmitted to a signing device constructed as described herein for digital signing, the signing device may recognize the object being signed and perform special functions. The X9.59 signed object data stream is defined as being from the “<” (less than) symbol of the <x9.59v-doc> tag to the “>” greater than of the </x9.59v-doc> tag (not including the trailing newline character; alternatively, it may be easier to just include the trailing new-line character). End-of-line within the body of an X9.59 signed object is a single new-line character (SHA-1 treats the data a single sequential bit-stream regardless of any textual meanings and/or delimiters).
- Added value X9.59 features in this environment can overlay some tag field value with a value stored in the signing device (or optionally insert a field value only when the supplied value is null). Exemplary fields in the X9.59 message format for which this might be done include: “prc_c”, “date_e”, and “luid”. The enhanced x9.59 services can support the saving of X9.59 field values and/or management of X9.59 field values. This may require spare memory in the device for field values. This will allow a device to be used for X9.59 financial transactions in environments where it is not necessary to know the consumer's account number (and/or expiration date).
- Another possible enhanced X9.59 function is for the signing device to keep track of transactions executed by supplying the “luid” field and incrementing the value after each X9.59 signature operation. It will be appreciated that any fields supplied and/or overlayed in this manner by the enhanced X9.59 functions are preferably returned as part of the signature results provided by the secure chip upon executing the digital signature function.
- As further measures for thwarting brute-force attacks on stolen PIN-activated signing devices that utilize the disclosed secure chip, enhanced X9.59 services can offer specific operations. Given that many forms of attacks are thwarted by various measures, attackers are left with attempting valid online transactions. While the basic process employed in the disclosed secure chip for thwarting attacks is to return a signature on data other than provided, enhanced X9.59-compatible services can codify the way the data has been modified, given the online service hints as to an attack being in progress.
- It should also be appreciated that a secure chip constructed as described herein may be utilized for transactions that satisfy the ISO 8385 message standard. In mapping the functions of an X9.59-compatible transaction to ISO 8583, the X9.59 object type field is preferably never transmitted since it is always assumed to be a fixed value for an authorization request. When the online service is operative to recreate the original signed object and verify the signature, it typically plugs in a fixed value into the object type field before calculating the SHA-1 on the reconstructed object. X9.59 enhanced services can always choose to modify this specific field using a proscribed convention when a valid PIN has not been entered. When the object is reconstructed, the signature will fail because the object actually signed was not a bit-for-bit duplicate of the reconstructed object.
- In this regard, the following is a contemplated modification convention for enhanced X9.59 services that are operative in conjunction with the disclosed secure digital signature device:
- valid PIN: OBJECT_TYPE
- no PIN:
OBJECT_TYPE+ 1 - invalid PIN:
OBJECT_TYPE+ 2 - The online service, when an invalid signature is encountered, can modify the reconstructed data with the different possibilities and attempt to re-verify the signature.
- The following is a contemplated exemplary sample X9.59 tagged format for transactions that are compatible with the disclosed embodiments of the invention:
- <x9.59v-doc>
- <std_ver>nnn . . .
- <object_type>nnn . . .
- <paycode>nnn . . .
- <prc_c>nnn . . .
- <luid>nnn . . .
- <prc_m>nnn . . .
- <paydata_c>nnnn.nn:nnn
- <date_s>nnn..
- <date_e>nnn...
- <shs>hhhhh...
- </x959v-doc>
- <sig>hhh . . . :hhh . . .
- where,
- nnn . . . is numeric data,
- hhh . . . is hexadecimal representation of binary data,
- a colon is used to separate amount and currency type in paydata_c,
- a colon is used to separate DSS r and s values,
- <shs> is the SHS of the order detail document, and
- <sig> is the DSS signature of the tagged elements.
- It will now be understood and appreciated that a device constructed in accordance with the present invention preferably has the following aspects: high integrity, tempested, immune to all known chip card attacks, having true random number generator, can generate ECC key pair in less than1 _second, on-chip ECC key pair generation, and the private key never leaves the chip. Such a device can be configured as an independent hardware token or embedded in other devices, such as: contact chip cards, contactless chip cards, rings, watches, PDAs, cellphones, USB tokens, etc. The basic functions supported are:
PKCS # 11 EC/DSS digital signing, PIN/biometric initialization, PIN/biometric activation or comparison analysis, key pair generation, and export public key. - Normally the digital signing function is performed on some message that is associated with some identifier (e.g., account number, userID, employee ID, or other information). The identifying information, formatting the message, and computation of the SHA-1 (FIPS-180) secure hash of the message may be performed by some supporting personal computing device (personal PC, cellphone, PDA, other I/O support element, etc.), but may also be computed within the device itself. In applications involving nonpersonal computing device applications (e.g. point-of-sale merchant devices, employee building entry devices, etc.), a “stand-alone” computing chip (not operated in conjunction with a personal computing device like a PDA or cellphone) requires additional functions to supply the ID information (account number, user ID, employee ID, chip ID, etc.) that is part of a digital signature authentication function.
- In the case of personally owned computing devices, such devices can typically be relied on to provide the appropriate ID for the specific application requiring authentication.
- For non-personally owned devices, the identifying information preferably needs to be provided directly by the device. Non-personally owned devices typically read-ID information from the device, create a message with identifying information, compute the SHA-1 hash of the message, write the hash to the device, and read DSS signature from the device. To support certain business processes, load-ID and read-ID functions are required. There are multiple ID architectures possible. One architecture is a single load-ID operation that is latched so that it can only be executed once. This ID would either be 1) business-process unique ID (e.g., limiting the device to a specific “ID” related function), or 2) device unique—allowing the device to be used in multiple different business processes, but requiring the business process to map the device unique ID to a business process specific ID, for example, an employee ID for building and corporate data process access. Preferably, the actual employee ID is loaded into the device, or a device-unique ID is loaded and the employee access function maps a card unique ID into a employee ID. Another architecture is multiple ID slots that carry a “tag” identifying the associated use. Each slot is latched so that it is only initialized once.
- The latter architecture arrangement more easily allows multiple application specific IDs to be carried in the device, as opposed to relying on a device-specific ID and the application mapping the card ID to an application-specific ID. This requires that the read-ID function supply an application specific tag to select the ID-slot to be read. The load-ID function preferably specifies an ID-tag and ID-value and the device returns a message indicating that the slot is not available if there are no unallocated slots.
- From the foregoing, it will be appreciated that the described multiple-slot load-ID and read-ID functions are extendable to simple “offline purse” applications. First, some specific “non-latched” slots are needed so that the load/write-ID function is not only initialized to an unused slot, but also used in subsequent updates to the same slot. The known typical offline purse applications have almost all the logic in the device reader and assume little or no capability in the device (other than perhaps allowing a value to be read and written). A slight expansion of this capability is the known Mondex and GSM applications where there is an infrastructure-wide shared secret in every card and the chip performs encryption. A simpler offline purse application has the infrastructure shared secret located in the reader and the card/chip is only used to carry the current (encrypted) value for the card. All the readers are assumed to be the trusted entities, which may not apply in many circumstances.
- Accordingly, it readily will be understood by those persons skilled in the art that, in view of the above detailed description of the preferred embodiments, devices, and methods of the present invention, the present invention is susceptible of broad utility and application. Many methods, embodiments, and adaptations of the present invention other than those herein described, as well as many variations, modifications, and equivalent arrangements, will be apparent from or reasonably suggested by the present invention and the following detailed description thereof, without departing from the substance or scope of the present invention. Furthermore, those of ordinary skill in the art will understand and appreciate that although steps of various processes may be shown and described in some instances as being carried out in a preferred sequence or temporal order, the steps of such processes are not necessarily to be limited to being carried out in such particular sequence or order. Rather, in many instances the steps of processes described herein may be carried out in various different sequences and orders, while still falling within the scope of the present invention. Accordingly, while the present invention is described herein in detail in relation to preferred methods and devices, it is to be understood that this detailed description only is illustrative and exemplary of the present invention and is made merely for purposes of providing a full and enabling disclosure of the invention. The detailed description set forth herein is not intended nor is to be construed to limit the present invention or otherwise to exclude any such other embodiments, adaptations, variations, modifications and equivalent arrangements of the present invention, the present invention being limited solely by the claims appended hereto and the equivalents thereof.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/923,075 US20020016913A1 (en) | 2000-08-04 | 2001-08-06 | Modifying message data and generating random number digital signature within computer chip |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US22307600P | 2000-08-04 | 2000-08-04 | |
US09/923,075 US20020016913A1 (en) | 2000-08-04 | 2001-08-06 | Modifying message data and generating random number digital signature within computer chip |
Publications (1)
Publication Number | Publication Date |
---|---|
US20020016913A1 true US20020016913A1 (en) | 2002-02-07 |
Family
ID=22834916
Family Applications (15)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/923,075 Abandoned US20020016913A1 (en) | 2000-08-04 | 2001-08-06 | Modifying message data and generating random number digital signature within computer chip |
US09/923,213 Expired - Fee Related US7500272B2 (en) | 2000-08-04 | 2001-08-06 | Manufacturing unique devices that generate digital signatures |
US10/312,164 Expired - Lifetime US7200749B2 (en) | 2000-08-04 | 2001-08-06 | Method and system for using electronic communications for an electronic contract |
US10/248,604 Expired - Lifetime US7143284B2 (en) | 2000-08-04 | 2003-01-31 | ABDS method and verification status for authenticating entity access |
US10/248,605 Expired - Lifetime US6938156B2 (en) | 2000-08-04 | 2003-01-31 | ABDS system and verification status for authenticating entity access |
US10/248,603 Expired - Lifetime US6851054B2 (en) | 2000-08-04 | 2003-01-31 | Account-Based digital signature (ABDS) system for authenticating entity access to controlled resource |
US10/248,606 Expired - Lifetime US6950940B2 (en) | 2000-08-04 | 2003-01-31 | ABDS method utilizing security information in authenticating entity access |
US10/248,627 Expired - Lifetime US6892302B2 (en) | 2000-08-04 | 2003-02-01 | Incorporating security certificate during manufacture of device generating digital signatures |
US10/248,625 Expired - Lifetime US6915430B2 (en) | 2000-08-04 | 2003-02-01 | Reliably identifying information of device generating digital signatures |
US10/248,624 Expired - Lifetime US7028185B2 (en) | 2000-08-04 | 2003-02-01 | Managing database for identifying to recipients security features of devices generating digital signatures |
US10/248,629 Expired - Lifetime US6959381B2 (en) | 2000-08-04 | 2003-02-01 | Central key authority (CKA) database for user accounts in ABDS system |
US10/248,628 Expired - Lifetime US6957336B2 (en) | 2000-08-04 | 2003-02-01 | Establishing initial PuK-linked account database |
US10/248,626 Expired - Lifetime US7047414B2 (en) | 2000-08-04 | 2003-02-01 | Managing database for reliably identifying information of device generating digital signatures |
US10/248,620 Expired - Lifetime US6952773B2 (en) | 2000-08-04 | 2003-02-01 | Requesting execution of instructions on accounts in ABDS system |
US12/355,712 Expired - Fee Related US7784106B2 (en) | 2000-08-04 | 2009-01-16 | Manufacturing unique devices that generate digital signatures |
Family Applications After (14)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/923,213 Expired - Fee Related US7500272B2 (en) | 2000-08-04 | 2001-08-06 | Manufacturing unique devices that generate digital signatures |
US10/312,164 Expired - Lifetime US7200749B2 (en) | 2000-08-04 | 2001-08-06 | Method and system for using electronic communications for an electronic contract |
US10/248,604 Expired - Lifetime US7143284B2 (en) | 2000-08-04 | 2003-01-31 | ABDS method and verification status for authenticating entity access |
US10/248,605 Expired - Lifetime US6938156B2 (en) | 2000-08-04 | 2003-01-31 | ABDS system and verification status for authenticating entity access |
US10/248,603 Expired - Lifetime US6851054B2 (en) | 2000-08-04 | 2003-01-31 | Account-Based digital signature (ABDS) system for authenticating entity access to controlled resource |
US10/248,606 Expired - Lifetime US6950940B2 (en) | 2000-08-04 | 2003-01-31 | ABDS method utilizing security information in authenticating entity access |
US10/248,627 Expired - Lifetime US6892302B2 (en) | 2000-08-04 | 2003-02-01 | Incorporating security certificate during manufacture of device generating digital signatures |
US10/248,625 Expired - Lifetime US6915430B2 (en) | 2000-08-04 | 2003-02-01 | Reliably identifying information of device generating digital signatures |
US10/248,624 Expired - Lifetime US7028185B2 (en) | 2000-08-04 | 2003-02-01 | Managing database for identifying to recipients security features of devices generating digital signatures |
US10/248,629 Expired - Lifetime US6959381B2 (en) | 2000-08-04 | 2003-02-01 | Central key authority (CKA) database for user accounts in ABDS system |
US10/248,628 Expired - Lifetime US6957336B2 (en) | 2000-08-04 | 2003-02-01 | Establishing initial PuK-linked account database |
US10/248,626 Expired - Lifetime US7047414B2 (en) | 2000-08-04 | 2003-02-01 | Managing database for reliably identifying information of device generating digital signatures |
US10/248,620 Expired - Lifetime US6952773B2 (en) | 2000-08-04 | 2003-02-01 | Requesting execution of instructions on accounts in ABDS system |
US12/355,712 Expired - Fee Related US7784106B2 (en) | 2000-08-04 | 2009-01-16 | Manufacturing unique devices that generate digital signatures |
Country Status (6)
Country | Link |
---|---|
US (15) | US20020016913A1 (en) |
EP (6) | EP1317816A4 (en) |
JP (6) | JP2004506245A (en) |
AU (8) | AU2001287164B2 (en) |
CA (6) | CA2418050C (en) |
WO (6) | WO2002013445A2 (en) |
Cited By (98)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020126850A1 (en) * | 2001-03-09 | 2002-09-12 | Arcot Systems, Inc. | Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys |
US20030051150A1 (en) * | 2001-09-10 | 2003-03-13 | Jung Jin Ho | Method for encrypting multimedia data |
US20040083394A1 (en) * | 2002-02-22 | 2004-04-29 | Gavin Brebner | Dynamic user authentication |
US20040083366A1 (en) * | 2002-10-24 | 2004-04-29 | Nachenberg Carey S. | Securing executable content using a trusted computing platform |
US20040129776A1 (en) * | 2002-09-26 | 2004-07-08 | Samsung Electronics Co., Ltd. | Security monitor apparatus and method using smart card |
US20040162987A1 (en) * | 2003-02-19 | 2004-08-19 | International Business Machines Corporation | Method, system and program product for auditing electronic transactions based on biometric readings |
US20050039016A1 (en) * | 2003-08-12 | 2005-02-17 | Selim Aissi | Method for using trusted, hardware-based identity credentials in runtime package signature to secure mobile communications and high-value transaction execution |
US20050086171A1 (en) * | 2002-07-30 | 2005-04-21 | Makoto Abe | Information processing system, information communication terminal and method, information processing device and method, recording medium, and program |
US20050125658A1 (en) * | 2001-10-23 | 2005-06-09 | Yoshihiro Tsukamoto | Information processing apparatus |
EP1547002A1 (en) * | 2002-07-24 | 2005-06-29 | BQT Solutions Pty Ltd | A method of secure transmission |
US20050204134A1 (en) * | 2004-03-15 | 2005-09-15 | Von Arx Jeffrey A. | System and method for securely authenticating a data exchange session with an implantable medical device |
US20060080539A1 (en) * | 2002-05-29 | 2006-04-13 | Akiko Asami | Information processing system |
US20060236101A1 (en) * | 2003-08-05 | 2006-10-19 | Kezhi Qiao | Authentication method for medic gateway |
US20060242691A1 (en) * | 2002-10-24 | 2006-10-26 | Gisela Meister | Method for carrying out a secure electronic transaction using a portable data support |
US20070049265A1 (en) * | 2005-08-30 | 2007-03-01 | Kaimal Biju R | Apparatus and method for local device management |
US20070046424A1 (en) * | 2005-08-31 | 2007-03-01 | Davis Michael L | Device authentication using a unidirectional protocol |
WO2007048839A1 (en) * | 2005-10-28 | 2007-05-03 | Gemplus | Method for securing payments by cutting out amounts |
US20070143838A1 (en) * | 2005-12-21 | 2007-06-21 | Thomas Milligan | Systems and methods for automatic secret generation and distribution for secure systems |
US20070226513A1 (en) * | 2004-05-06 | 2007-09-27 | Fukio Handa | Ic Card for Encryption or Decryption Process and Encrypted Communication System and Encrypted Communication Method Using the Same |
US20070226787A1 (en) * | 2006-03-24 | 2007-09-27 | Atmel Corporation | Method and system for secure external TPM password generation and use |
US20070237366A1 (en) * | 2006-03-24 | 2007-10-11 | Atmel Corporation | Secure biometric processing system and method of use |
WO2007143740A2 (en) * | 2006-06-08 | 2007-12-13 | Mastercard International Incorporated | All-in-one proximity payment device with local authentication |
US7437330B1 (en) * | 2002-09-20 | 2008-10-14 | Yt Acquisition Corp. | System and method for categorizing transactions |
US20080288029A1 (en) * | 2004-03-15 | 2008-11-20 | Healy Scott J | System And Method For Securely Exchanging Sensitive Information With An Implantable Medical Device |
US20090153290A1 (en) * | 2007-12-14 | 2009-06-18 | Farpointe Data, Inc., A California Corporation | Secure interface for access control systems |
US20100017881A1 (en) * | 2006-12-26 | 2010-01-21 | Oberthur Technologies | Portable Electronic Device and Method for Securing Such Device |
US20100034375A1 (en) * | 2008-08-11 | 2010-02-11 | Assa Abloy Ab | Secure wiegand communications |
US20100039220A1 (en) * | 2008-08-14 | 2010-02-18 | Assa Abloy Ab | Rfid reader with embedded attack detection heuristics |
US7769695B2 (en) | 2001-09-21 | 2010-08-03 | Yt Acquisition Corporation | System and method for purchase benefits at a point of sale |
US20100241690A1 (en) * | 2009-03-20 | 2010-09-23 | Microsoft Corporation | Component and dependency discovery |
US7892087B1 (en) * | 2002-12-02 | 2011-02-22 | Sca Promotions, Inc. | Authentication of game results |
US8052048B1 (en) | 2002-12-26 | 2011-11-08 | Diebold Self-Service Systems Division Of Diebold, Incorporated | Automated banking machine that operates responsive to data bearing records |
US20130173467A1 (en) * | 2011-12-29 | 2013-07-04 | Ebay Inc. | Methods and systems for using a co-located group as an authorization mechanism |
US20130246793A1 (en) * | 2006-06-19 | 2013-09-19 | Newsecure Innovations Inc. | Method and apparatus for encryption and pass-through handling of confidential information in software applications |
US20130318354A1 (en) * | 2010-06-28 | 2013-11-28 | Bundesdruckerei Gmbh | Method for generating a certificate |
US8666906B1 (en) | 2007-10-01 | 2014-03-04 | Google Inc. | Discrete verification of payment information |
US8700895B1 (en) | 2010-06-30 | 2014-04-15 | Google Inc. | System and method for operating a computing device in a secure mode |
US20150066509A1 (en) * | 2013-08-30 | 2015-03-05 | Hon Hai Precision Industry Co., Ltd. | Electronic device and method for encrypting and decrypting document based on voiceprint techology |
US20150074403A1 (en) * | 2006-10-10 | 2015-03-12 | Qualcomm Incorporated | Method and apparatus for mutual authentication |
WO2015066028A1 (en) * | 2013-11-04 | 2015-05-07 | Apple Inc. | Using biometric authentication for nfc-based payments |
CN104821021A (en) * | 2015-03-30 | 2015-08-05 | 无锡市崇安区科技创业服务中心 | Password information automatic push-based locker control system |
US9118666B2 (en) | 2010-06-30 | 2015-08-25 | Google Inc. | Computing device integrity verification |
US20150281970A1 (en) * | 2008-07-09 | 2015-10-01 | Samsung Electronics Co., Ltd. | Near field communication (nfc) device and method for selectively securing records in a near field communication data exchange format (ndef) message |
DE102014108911A1 (en) * | 2014-06-25 | 2015-12-31 | Paschalis Papagrigoriou | Clock with advanced functionality to secure electronic transactions with secure electronic signatures |
CN105229596A (en) * | 2013-03-22 | 2016-01-06 | 诺克诺克实验公司 | High level of authentication technology and application |
CN105447934A (en) * | 2015-11-13 | 2016-03-30 | 珠海唯码科技有限公司 | Multiple remote authentication digital anti-theft lock |
US20160104162A1 (en) * | 2014-07-10 | 2016-04-14 | Bank Of America Corporation | Dynamic card validation |
US20160314469A1 (en) * | 2013-12-31 | 2016-10-27 | Feitian Technologies Co., Ltd. | Method for generating off-line authentication credentials by intelligent card |
WO2017032452A1 (en) * | 2015-08-24 | 2017-03-02 | Giesecke & Devrient Gmbh | Transaction system |
US9591616B2 (en) | 2014-04-25 | 2017-03-07 | Alibaba Group Holding Limited | Data transmission |
EP3171315A1 (en) * | 2015-11-23 | 2017-05-24 | Xiaomi Inc. | Payment verification system, method and apparatus, computer program and recording medium |
GB2547954A (en) * | 2016-03-03 | 2017-09-06 | Zwipe As | Attack resistant biometric authorised device |
WO2017152150A1 (en) * | 2016-03-04 | 2017-09-08 | ShoCard, Inc. | Method and system for authenticated login using static or dynamic codes |
US20170294053A1 (en) * | 2016-04-07 | 2017-10-12 | Yeon Technologies Co., Ltd. | Method, system and communication terminal for patrol with scanning tags |
US9811827B2 (en) | 2012-02-28 | 2017-11-07 | Google Inc. | System and method for providing transaction verification |
CN107491678A (en) * | 2017-08-16 | 2017-12-19 | 合肥庆响网络科技有限公司 | Computer iris recognition start-up system |
US9871789B2 (en) | 2014-10-31 | 2018-01-16 | Advantest Corporation | Authentication system, authentication method and service providing system |
US9875347B2 (en) | 2014-07-31 | 2018-01-23 | Nok Nok Labs, Inc. | System and method for performing authentication using data analytics |
US9887983B2 (en) | 2013-10-29 | 2018-02-06 | Nok Nok Labs, Inc. | Apparatus and method for implementing composite authenticators |
US9898596B2 (en) | 2013-03-22 | 2018-02-20 | Nok Nok Labs, Inc. | System and method for eye tracking during authentication |
US9961077B2 (en) | 2013-05-30 | 2018-05-01 | Nok Nok Labs, Inc. | System and method for biometric authentication with device attestation |
US10084761B1 (en) * | 2014-06-27 | 2018-09-25 | Wickr Inc | In-band identity verification and man-in-the-middle defense |
US10091195B2 (en) | 2016-12-31 | 2018-10-02 | Nok Nok Labs, Inc. | System and method for bootstrapping a user binding |
US10148630B2 (en) | 2014-07-31 | 2018-12-04 | Nok Nok Labs, Inc. | System and method for implementing a hosted authentication service |
US20190034934A1 (en) * | 2017-07-28 | 2019-01-31 | Alclear, Llc | Biometric payment |
US10237070B2 (en) | 2016-12-31 | 2019-03-19 | Nok Nok Labs, Inc. | System and method for sharing keys across authenticators |
US20190095771A1 (en) * | 2016-07-04 | 2019-03-28 | Kabushiki Kaisha Toshiba | Ic card, portable electronic device, and information processing method |
CN109872233A (en) * | 2019-01-17 | 2019-06-11 | 深圳壹账通智能科技有限公司 | Contract signing method, apparatus, computer equipment and storage medium |
US10326761B2 (en) | 2014-05-02 | 2019-06-18 | Nok Nok Labs, Inc. | Web-based user authentication techniques and applications |
US10452877B2 (en) | 2016-12-16 | 2019-10-22 | Assa Abloy Ab | Methods to combine and auto-configure wiegand and RS485 |
CN110532807A (en) * | 2019-07-30 | 2019-12-03 | 平安科技(深圳)有限公司 | Electronic voucher generation method, device, computer equipment and storage medium |
DE102018119530A1 (en) * | 2018-08-10 | 2020-02-13 | Bundesdruckerei Gmbh | Network module for providing a communication link between a data processing entity and a communication network |
CN110929300A (en) * | 2019-12-11 | 2020-03-27 | 中国人民解放军国防科技大学 | Trusted computing security chip construction method based on identification password |
US10637853B2 (en) | 2016-08-05 | 2020-04-28 | Nok Nok Labs, Inc. | Authentication techniques including speech and/or lip movement analysis |
US20200162455A1 (en) * | 2018-11-19 | 2020-05-21 | Authentrend Technology Inc. | Multi-functional authentication apparatus and operating method for the same |
US10708244B2 (en) * | 2017-06-07 | 2020-07-07 | Virtual Connect Technologies, Inc. | System and method for encryption, storage and transmission of digital information |
US20200259651A1 (en) * | 2017-10-30 | 2020-08-13 | Visa International Service Association | Multi-party threshold authenticated encryption |
US10769635B2 (en) | 2016-08-05 | 2020-09-08 | Nok Nok Labs, Inc. | Authentication techniques including speech and/or lip movement analysis |
US20200364722A1 (en) * | 2019-05-16 | 2020-11-19 | Alclear, Llc | Biometric payment processing that configures payment processing for a determined merchant of record |
US20210075598A1 (en) * | 2017-09-22 | 2021-03-11 | NEC Laboratories Europe GmbH | Scalable byzantine fault-tolerant protocol with partial tee support |
US10979227B2 (en) | 2018-10-17 | 2021-04-13 | Ping Identity Corporation | Blockchain ID connect |
US11042669B2 (en) | 2018-04-25 | 2021-06-22 | Blockchain ASICs Inc. | Cryptographic ASIC with unique internal identifier |
US11057187B2 (en) * | 2018-08-09 | 2021-07-06 | Guardtime Sa | Blockchain-assisted hash-based data signature system and method |
US11062106B2 (en) | 2016-03-07 | 2021-07-13 | Ping Identity Corporation | Large data transfer using visual codes with feedback confirmation |
US11082221B2 (en) | 2018-10-17 | 2021-08-03 | Ping Identity Corporation | Methods and systems for creating and recovering accounts using dynamic passwords |
US11170130B1 (en) | 2021-04-08 | 2021-11-09 | Aster Key, LLC | Apparatus, systems and methods for storing user profile data on a distributed database for anonymous verification |
US11206133B2 (en) | 2017-12-08 | 2021-12-21 | Ping Identity Corporation | Methods and systems for recovering data using dynamic passwords |
US11263415B2 (en) | 2016-03-07 | 2022-03-01 | Ping Identity Corporation | Transferring data files using a series of visual codes |
US11323272B2 (en) | 2017-02-06 | 2022-05-03 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US20220385463A1 (en) * | 2020-01-31 | 2022-12-01 | Visa International Service Association | Distributed symmetric encryption |
US11544367B2 (en) | 2015-05-05 | 2023-01-03 | Ping Identity Corporation | Systems, apparatus and methods for secure electrical communication of biometric personal identification information to validate the identity of an individual |
CN115660878A (en) * | 2022-11-03 | 2023-01-31 | 深圳标普云科技有限公司 | Electronic invoice realization method and system |
US20230062244A1 (en) * | 2021-09-01 | 2023-03-02 | Qualcomm Incorporated | Extended reality control of smart devices |
US11646889B2 (en) | 2017-12-19 | 2023-05-09 | Riddle & Code Gmbh | Dongles and method for providing a digital signature |
US11736219B2 (en) | 2018-12-28 | 2023-08-22 | Kabushiki Kaisha Toshiba | Communication control device and communication control system |
US11792024B2 (en) | 2019-03-29 | 2023-10-17 | Nok Nok Labs, Inc. | System and method for efficient challenge-response authentication |
US11831409B2 (en) | 2018-01-12 | 2023-11-28 | Nok Nok Labs, Inc. | System and method for binding verifiable claims |
US11868995B2 (en) | 2017-11-27 | 2024-01-09 | Nok Nok Labs, Inc. | Extending a secure key storage for transaction confirmation and cryptocurrency |
Families Citing this family (667)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8015597B2 (en) * | 1995-10-02 | 2011-09-06 | Corestreet, Ltd. | Disseminating additional data used for controlling access |
US10181953B1 (en) | 2013-09-16 | 2019-01-15 | Amazon Technologies, Inc. | Trusted data verification |
US7357312B2 (en) * | 1998-05-29 | 2008-04-15 | Gangi Frank J | System for associating identification and personal data for multiple magnetic stripe cards or other sources to facilitate a transaction and related methods |
US6131811A (en) * | 1998-05-29 | 2000-10-17 | E-Micro Corporation | Wallet consolidator |
US7083087B1 (en) | 2000-09-18 | 2006-08-01 | E-Micro Corporation | Method and apparatus for associating identification and personal data for multiple magnetic stripe cards or other sources |
US6816968B1 (en) * | 1998-07-10 | 2004-11-09 | Silverbrook Research Pty Ltd | Consumable authentication protocol and system |
US7174457B1 (en) * | 1999-03-10 | 2007-02-06 | Microsoft Corporation | System and method for authenticating an operating system to a central processing unit, providing the CPU/OS with secure storage, and authenticating the CPU/OS to a third party |
US7194092B1 (en) * | 1998-10-26 | 2007-03-20 | Microsoft Corporation | Key-based secure storage |
AU763571B2 (en) | 1998-12-23 | 2003-07-24 | Chase Manhattan Bank, The | System and method for integrating trading operations including the generation, processing and tracking of and trade documents |
US7578439B2 (en) * | 1999-08-19 | 2009-08-25 | E2Interactive, Inc. | System and method for authorizing stored value card transactions |
US8706630B2 (en) * | 1999-08-19 | 2014-04-22 | E2Interactive, Inc. | System and method for securely authorizing and distributing stored-value card data |
US8793160B2 (en) | 1999-12-07 | 2014-07-29 | Steve Sorem | System and method for processing transactions |
WO2002003219A1 (en) | 2000-06-30 | 2002-01-10 | Plurimus Corporation | Method and system for monitoring online computer network behavior and creating online behavior profiles |
US7058641B1 (en) * | 2000-08-08 | 2006-06-06 | Franz Gregory J | Information distribution system and method |
WO2002013016A1 (en) * | 2000-08-08 | 2002-02-14 | Wachovia Corporation | Internet third-party authentication using electronic tickets |
US7689560B2 (en) * | 2000-10-13 | 2010-03-30 | Miosoft Corporation | Persistent data storage techniques |
US7831467B1 (en) | 2000-10-17 | 2010-11-09 | Jpmorgan Chase Bank, N.A. | Method and system for retaining customer loyalty |
US7134016B1 (en) * | 2000-11-14 | 2006-11-07 | Harris Scott C | Software system with a biometric dongle function |
US20020083012A1 (en) * | 2000-11-16 | 2002-06-27 | Steve Bush | Method and system for account management |
US7937655B2 (en) * | 2000-12-22 | 2011-05-03 | Oracle International Corporation | Workflows with associated processes |
US7475151B2 (en) * | 2000-12-22 | 2009-01-06 | Oracle International Corporation | Policies for modifying group membership |
US7213249B2 (en) * | 2000-12-22 | 2007-05-01 | Oracle International Corporation | Blocking cache flush requests until completing current pending requests in a local server and remote server |
US8015600B2 (en) * | 2000-12-22 | 2011-09-06 | Oracle International Corporation | Employing electronic certificate workflows |
US7802174B2 (en) | 2000-12-22 | 2010-09-21 | Oracle International Corporation | Domain based workflows |
US7415607B2 (en) * | 2000-12-22 | 2008-08-19 | Oracle International Corporation | Obtaining and maintaining real time certificate status |
US7581011B2 (en) * | 2000-12-22 | 2009-08-25 | Oracle International Corporation | Template based workflow definition |
US7711818B2 (en) * | 2000-12-22 | 2010-05-04 | Oracle International Corporation | Support for multiple data stores |
US7085834B2 (en) * | 2000-12-22 | 2006-08-01 | Oracle International Corporation | Determining a user's groups |
PL345054A1 (en) * | 2001-01-11 | 2002-07-15 | Igor Hansen | Personal database system and method of managing the access to such database |
US7451116B2 (en) * | 2001-03-07 | 2008-11-11 | Diebold, Incorporated | Automated transaction machine digital signature system and method |
US8261975B2 (en) | 2001-03-07 | 2012-09-11 | Diebold, Incorporated | Automated banking machine that operates responsive to data bearing records |
US7908304B2 (en) | 2001-03-15 | 2011-03-15 | Versata Development Group, Inc. | Method and system for managing distributor information |
US7925513B2 (en) * | 2001-03-15 | 2011-04-12 | Versata Development Group, Inc. | Framework for processing sales transaction data |
US20030018481A1 (en) * | 2001-03-15 | 2003-01-23 | Cheng Zhou | Method and apparatus for generating configurable documents |
US7958024B2 (en) * | 2001-03-15 | 2011-06-07 | Versata Development Group, Inc. | Method and apparatus for processing sales transaction data |
US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
US20020198994A1 (en) * | 2001-05-15 | 2002-12-26 | Charles Patton | Method and system for enabling and controlling communication topology, access to resources, and document flow in a distributed networking environment |
WO2002099598A2 (en) | 2001-06-07 | 2002-12-12 | First Usa Bank, N.A. | System and method for rapid updating of credit information |
EP1410293A2 (en) | 2001-06-12 | 2004-04-21 | Research In Motion Limited | System and method for compressing secure e-mail for exchange with a mobile data communication device |
CN1653459B (en) * | 2001-06-12 | 2010-12-15 | 捷讯研究有限公司 | System and method for processing encoded messages for exchange with a mobile data communication device |
US20030005317A1 (en) * | 2001-06-28 | 2003-01-02 | Audebert Yves Louis Gabriel | Method and system for generating and verifying a key protection certificate |
US7366772B2 (en) * | 2001-06-29 | 2008-04-29 | International Business Machines Corporation | Method and apparatus for creating and exposing order status within a supply chain having disparate systems |
US7904326B2 (en) * | 2001-06-29 | 2011-03-08 | Versata Development Group, Inc. | Method and apparatus for performing collective validation of credential information |
US7266839B2 (en) | 2001-07-12 | 2007-09-04 | J P Morgan Chase Bank | System and method for providing discriminated content to network users |
US20030023478A1 (en) * | 2001-07-26 | 2003-01-30 | Piccionelli Gregory A. | Electronic initiative petition |
US8020754B2 (en) | 2001-08-13 | 2011-09-20 | Jpmorgan Chase Bank, N.A. | System and method for funding a collective account by use of an electronic tag |
US7333996B2 (en) * | 2001-08-22 | 2008-02-19 | International Business Machines Corporation | Management of contract data |
JP2003069559A (en) * | 2001-08-23 | 2003-03-07 | Sony Corp | Content protection system |
ATE434786T1 (en) | 2001-09-20 | 2009-07-15 | Hitwise Pty Ltd | METHOD AND SYSTEM FOR CHARACTERIZING ONLINE BEHAVIOR |
US9189788B1 (en) | 2001-09-21 | 2015-11-17 | Open Invention Network, Llc | System and method for verifying identity |
US7269737B2 (en) | 2001-09-21 | 2007-09-11 | Pay By Touch Checking Resources, Inc. | System and method for biometric authorization for financial transactions |
US7991386B2 (en) * | 2003-11-14 | 2011-08-02 | E2Interactive, Inc. | System and method for authorizing the activation of a communication device |
US20030074579A1 (en) * | 2001-10-16 | 2003-04-17 | Microsoft Corporation | Virtual distributed security system |
US7451157B2 (en) * | 2001-10-16 | 2008-11-11 | Microsoft Corporation | Scoped metadata in a markup language |
US8015204B2 (en) * | 2001-10-16 | 2011-09-06 | Microsoft Corporation | Scoped access control metadata element |
US7676540B2 (en) * | 2001-10-16 | 2010-03-09 | Microsoft Corporation | Scoped referral statements |
US7536712B2 (en) * | 2001-10-16 | 2009-05-19 | Microsoft Corporation | Flexible electronic message security mechanism |
EP1303097A3 (en) * | 2001-10-16 | 2005-11-30 | Microsoft Corporation | Virtual distributed security system |
US7194553B2 (en) | 2001-10-16 | 2007-03-20 | Microsoft Corporation | Resolving virtual network names |
SE523290C2 (en) * | 2001-10-19 | 2004-04-06 | Smarttrust Systems Oy | Method and device in a communication network |
JP3987710B2 (en) * | 2001-10-30 | 2007-10-10 | 株式会社日立製作所 | Certification system and authentication method |
US7899047B2 (en) | 2001-11-27 | 2011-03-01 | Microsoft Corporation | Virtual network with adaptive dispatcher |
US7225256B2 (en) * | 2001-11-30 | 2007-05-29 | Oracle International Corporation | Impersonation in an access system |
US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
US10033700B2 (en) * | 2001-12-12 | 2018-07-24 | Intellectual Ventures I Llc | Dynamic evaluation of access rights |
US10360545B2 (en) | 2001-12-12 | 2019-07-23 | Guardian Data Storage, Llc | Method and apparatus for accessing secured electronic data off-line |
US8065713B1 (en) | 2001-12-12 | 2011-11-22 | Klimenty Vainstein | System and method for providing multi-location access management to secured items |
US7930756B1 (en) | 2001-12-12 | 2011-04-19 | Crocker Steven Toye | Multi-level cryptographic transformations for securing digital assets |
US7921288B1 (en) | 2001-12-12 | 2011-04-05 | Hildebrand Hal S | System and method for providing different levels of key security for controlling access to secured items |
US7921450B1 (en) * | 2001-12-12 | 2011-04-05 | Klimenty Vainstein | Security system using indirect key generation from access rules and methods therefor |
US7565683B1 (en) | 2001-12-12 | 2009-07-21 | Weiqing Huang | Method and system for implementing changes to security policies in a distributed security system |
US7380120B1 (en) | 2001-12-12 | 2008-05-27 | Guardian Data Storage, Llc | Secured data format for access control |
US7260555B2 (en) | 2001-12-12 | 2007-08-21 | Guardian Data Storage, Llc | Method and architecture for providing pervasive security to digital assets |
US7921284B1 (en) | 2001-12-12 | 2011-04-05 | Gary Mark Kinghorn | Method and system for protecting electronic data in enterprise environment |
US7251730B2 (en) * | 2001-12-21 | 2007-07-31 | Qualcomm Incorporated | Method and apparatus for simplified audio authentication |
US7386468B2 (en) * | 2002-01-08 | 2008-06-10 | International Business Machines Corporation | System and method for resource reduction receipt log and audit trail |
DE10202286A1 (en) * | 2002-01-22 | 2003-07-31 | Siemens Ag | Control of access to personal data, especially medical data, whereby to ensure that only authorized persons can access sensitive patient data at least a part of an authentication code is specific to the patient alone |
US8176334B2 (en) | 2002-09-30 | 2012-05-08 | Guardian Data Storage, Llc | Document security system that permits external users to gain access to secured files |
US7966497B2 (en) | 2002-02-15 | 2011-06-21 | Qualcomm Incorporated | System and method for acoustic two factor authentication |
US20030163685A1 (en) * | 2002-02-28 | 2003-08-28 | Nokia Corporation | Method and system to allow performance of permitted activity with respect to a device |
US7366905B2 (en) * | 2002-02-28 | 2008-04-29 | Nokia Corporation | Method and system for user generated keys and certificates |
US7130886B2 (en) * | 2002-03-06 | 2006-10-31 | Research In Motion Limited | System and method for providing secure message signature status and trust status indication |
US7349538B2 (en) * | 2002-03-21 | 2008-03-25 | Ntt Docomo Inc. | Hierarchical identity-based encryption and signature schemes |
US7899753B1 (en) | 2002-03-25 | 2011-03-01 | Jpmorgan Chase Bank, N.A | Systems and methods for time variable financial authentication |
EP1497948A4 (en) * | 2002-04-15 | 2007-03-21 | Ntt Docomo Inc | Signature schemes using bilinear mappings |
US7840803B2 (en) * | 2002-04-16 | 2010-11-23 | Massachusetts Institute Of Technology | Authentication of integrated circuits |
US7487365B2 (en) * | 2002-04-17 | 2009-02-03 | Microsoft Corporation | Saving and retrieving data based on symmetric key encryption |
US7890771B2 (en) | 2002-04-17 | 2011-02-15 | Microsoft Corporation | Saving and retrieving data based on public key encryption |
US7662094B2 (en) * | 2002-05-14 | 2010-02-16 | Given Imaging Ltd. | Optical head assembly with dome, and device for use thereof |
US7216163B2 (en) * | 2002-05-15 | 2007-05-08 | Oracle International Corporation | Method and apparatus for provisioning tasks using a provisioning bridge server |
US7840658B2 (en) * | 2002-05-15 | 2010-11-23 | Oracle International Corporation | Employing job code attributes in provisioning |
US7401224B2 (en) | 2002-05-15 | 2008-07-15 | Qualcomm Incorporated | System and method for managing sonic token verifiers |
JP2003346149A (en) * | 2002-05-24 | 2003-12-05 | Omron Corp | Face collating device and bioinformation collating device |
US20040044591A1 (en) * | 2002-06-19 | 2004-03-04 | Gilliland Ramelle L. | Method and system for electronic procurement involving electronic requests for quotation |
US20040015432A1 (en) * | 2002-07-19 | 2004-01-22 | Lewis Harry D. | Business method for creating and managing multilateral contractual relationships electronically and on a large scale |
US8393001B1 (en) | 2002-07-26 | 2013-03-05 | Mcafee, Inc. | Secure signature server system and associated method |
US7590861B2 (en) * | 2002-08-06 | 2009-09-15 | Privaris, Inc. | Methods for secure enrollment and backup of personal identity credentials into electronic devices |
US20040107170A1 (en) * | 2002-08-08 | 2004-06-03 | Fujitsu Limited | Apparatuses for purchasing of goods and services |
US7784684B2 (en) | 2002-08-08 | 2010-08-31 | Fujitsu Limited | Wireless computer wallet for physical point of sale (POS) transactions |
US7801826B2 (en) * | 2002-08-08 | 2010-09-21 | Fujitsu Limited | Framework and system for purchasing of goods and services |
US7606560B2 (en) * | 2002-08-08 | 2009-10-20 | Fujitsu Limited | Authentication services using mobile device |
US7822688B2 (en) * | 2002-08-08 | 2010-10-26 | Fujitsu Limited | Wireless wallet |
CA2496165C (en) | 2002-08-19 | 2014-07-15 | Research In Motion Limited | System and method for secure control of resources of wireless mobile communication devices |
EP1540875A4 (en) * | 2002-08-28 | 2011-01-26 | Ntt Docomo Inc | Certificate-based encryption and public key infrastructure |
US20040122736A1 (en) | 2002-10-11 | 2004-06-24 | Bank One, Delaware, N.A. | System and method for granting promotional rewards to credit account holders |
US8301493B2 (en) | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
US7895443B2 (en) * | 2002-11-05 | 2011-02-22 | Safenet, Inc. | Secure authentication using hardware token and computer fingerprint |
JP4349789B2 (en) | 2002-11-06 | 2009-10-21 | 富士通株式会社 | Safety judgment device and safety judgment method |
US7661127B2 (en) * | 2002-11-12 | 2010-02-09 | Millipore Corporation | Instrument access control system |
US20040103317A1 (en) * | 2002-11-22 | 2004-05-27 | Burns William D. | Method and apparatus for protecting secure credentials on an untrusted computer platform |
US7461260B2 (en) * | 2002-12-31 | 2008-12-02 | Intel Corporation | Methods and apparatus for finding a shared secret without compromising non-shared secrets |
US7386721B1 (en) * | 2003-03-12 | 2008-06-10 | Cisco Technology, Inc. | Method and apparatus for integrated provisioning of a network device with configuration information and identity certification |
WO2004084029A2 (en) * | 2003-03-14 | 2004-09-30 | Citibank, N.A. | Method and system of transaction security |
US7451113B1 (en) * | 2003-03-21 | 2008-11-11 | Mighty Net, Inc. | Card management system and method |
US7644123B2 (en) * | 2003-03-24 | 2010-01-05 | British Telecommunications Public Limited Company | Message announcements |
US8123616B2 (en) | 2003-03-25 | 2012-02-28 | Igt | Methods and apparatus for limiting access to games using biometric data |
US7867083B2 (en) | 2003-03-25 | 2011-01-11 | Igt | Methods and apparatus for limiting access to games using biometric data |
JP2004302921A (en) * | 2003-03-31 | 2004-10-28 | Toshiba Corp | Device authenticating apparatus using off-line information and device authenticating method |
WO2004092993A1 (en) * | 2003-04-09 | 2004-10-28 | Gtech Rhode Island Corporation | Electronic payment system |
JP2004310581A (en) * | 2003-04-09 | 2004-11-04 | Nec Corp | Network connecting method, and network system |
US8352725B1 (en) * | 2003-04-21 | 2013-01-08 | Cisco Technology, Inc. | Method and apparatus for managing secure communications |
EP3032446B1 (en) * | 2003-04-25 | 2019-10-23 | Apple Inc. | Methods and system for secure network-based distribution of content |
US7447660B2 (en) * | 2003-04-30 | 2008-11-04 | Lexcel Solutions, Inc. | System and method for capacity testing of electronic funds transfer systems |
US7647344B2 (en) * | 2003-05-29 | 2010-01-12 | Experian Marketing Solutions, Inc. | System, method and software for providing persistent entity identification and linking entity information in an integrated data repository |
US8707034B1 (en) | 2003-05-30 | 2014-04-22 | Intellectual Ventures I Llc | Method and system for using remote headers to secure electronic files |
US8306907B2 (en) | 2003-05-30 | 2012-11-06 | Jpmorgan Chase Bank N.A. | System and method for offering risk-based interest rates in a credit instrument |
US7945785B2 (en) * | 2003-06-02 | 2011-05-17 | Seiko Epson Corporation | Security of data over a network |
MXPA05013422A (en) * | 2003-06-10 | 2006-03-17 | Mastercard International Inc | Systems and methods for conducting secure payment transactions using a formatted data structure. |
KR20050007830A (en) * | 2003-07-11 | 2005-01-21 | 삼성전자주식회사 | Method for Domain Authentication for exchanging contents between devices |
US7376834B2 (en) * | 2003-07-18 | 2008-05-20 | Palo Alto Research Center Incorporated | System and method for securely controlling communications |
US7669236B2 (en) * | 2004-11-18 | 2010-02-23 | Biogy, Inc. | Determining whether to grant access to a passcode protected system |
JP4339648B2 (en) * | 2003-08-13 | 2009-10-07 | 富士通フロンテック株式会社 | Electronic payment system, electronic payment program and electronic payment device, |
US8175908B1 (en) | 2003-09-04 | 2012-05-08 | Jpmorgan Chase Bank, N.A. | Systems and methods for constructing and utilizing a merchant database derived from customer purchase transactions data |
US7526652B2 (en) * | 2003-09-04 | 2009-04-28 | Accullink, Inc. | Secure PIN management |
JP4712325B2 (en) | 2003-09-12 | 2011-06-29 | 株式会社リコー | COMMUNICATION DEVICE, COMMUNICATION SYSTEM, COMMUNICATION METHOD, AND PROGRAM |
TW200513087A (en) * | 2003-09-19 | 2005-04-01 | Hui Lin | Mail server login security authentication system and method, and IC card authentication hardware |
TW200513086A (en) * | 2003-09-19 | 2005-04-01 | Hui Lin | Internet passing security authentication system and method, and IC card authentication hardware |
FI20031361A0 (en) * | 2003-09-22 | 2003-09-22 | Nokia Corp | Remote management of IPSec security associations |
US7703140B2 (en) | 2003-09-30 | 2010-04-20 | Guardian Data Storage, Llc | Method and system for securing digital assets using process-driven security policies |
US8127366B2 (en) | 2003-09-30 | 2012-02-28 | Guardian Data Storage, Llc | Method and apparatus for transitioning between states of security policies used to secure electronic documents |
US7536724B1 (en) * | 2003-10-01 | 2009-05-19 | Symantec Corporation | Risk profiling for optimizing deployment of security measures |
EP1521390B1 (en) * | 2003-10-01 | 2008-08-13 | Hewlett-Packard Development Company, L.P. | Digital signature method and apparatus |
US7904487B2 (en) | 2003-10-09 | 2011-03-08 | Oracle International Corporation | Translating data access requests |
US7882132B2 (en) | 2003-10-09 | 2011-02-01 | Oracle International Corporation | Support for RDBMS in LDAP system |
US9614772B1 (en) | 2003-10-20 | 2017-04-04 | F5 Networks, Inc. | System and method for directing network traffic in tunneling applications |
JP4070708B2 (en) * | 2003-11-14 | 2008-04-02 | 株式会社リコー | Security ensuring support program, server device for executing the program, and storage medium storing the program |
US7437328B2 (en) * | 2003-11-14 | 2008-10-14 | E2Interactive, Inc. | Value insertion using bill pay card preassociated with biller |
US8655309B2 (en) | 2003-11-14 | 2014-02-18 | E2Interactive, Inc. | Systems and methods for electronic device point-of-sale activation |
KR101577860B1 (en) * | 2003-12-01 | 2015-12-16 | 인터디지탈 테크날러지 코포레이션 | Session initiation protocol(sip) based user initiated handoff |
US7908208B2 (en) * | 2003-12-10 | 2011-03-15 | Alphacap Ventures Llc | Private entity profile network |
US7263608B2 (en) * | 2003-12-12 | 2007-08-28 | Lenovo (Singapore) Pte. Ltd. | System and method for providing endorsement certificate |
GB0329039D0 (en) * | 2003-12-15 | 2004-01-14 | Ncipher Corp Ltd | Cryptographic security module method and apparatus |
US20070094129A1 (en) * | 2003-12-19 | 2007-04-26 | E2Interactive, Inc. D/B/A E2Interactive, Inc. | System and method for adding value to a stored-value account using provider specific pin |
US8495361B2 (en) * | 2003-12-31 | 2013-07-23 | International Business Machines Corporation | Securely creating an endorsement certificate in an insecure environment |
US7644278B2 (en) * | 2003-12-31 | 2010-01-05 | International Business Machines Corporation | Method for securely creating an endorsement certificate in an insecure environment |
US7751568B2 (en) * | 2003-12-31 | 2010-07-06 | International Business Machines Corporation | Method for securely creating an endorsement certificate utilizing signing key pairs |
US20050166051A1 (en) * | 2004-01-26 | 2005-07-28 | Mark Buer | System and method for certification of a secure platform |
US7877605B2 (en) * | 2004-02-06 | 2011-01-25 | Fujitsu Limited | Opinion registering application for a universal pervasive transaction framework |
US20050177504A1 (en) * | 2004-02-10 | 2005-08-11 | Bottomline Technologies (De) Inc. | System and method for remotely authorizing a payment transaction file over an open network |
US7236957B2 (en) * | 2004-02-10 | 2007-06-26 | Bottomline Technologies (De) Inc. | Method for remotely authorizing a payment transaction file over an open network |
US7828652B2 (en) * | 2004-02-12 | 2010-11-09 | Igt | Player verification method and system for remote gaming terminals |
US7400878B2 (en) | 2004-02-26 | 2008-07-15 | Research In Motion Limited | Computing device with environment aware features |
US20050192839A1 (en) * | 2004-02-27 | 2005-09-01 | P2P Link Llc | Method and system for managing paperless claim processing |
US9020854B2 (en) | 2004-03-08 | 2015-04-28 | Proxense, Llc | Linked account system using personal digital key (PDK-LAS) |
AU2005220988B2 (en) * | 2004-03-15 | 2011-01-06 | Lockstep Consulting Pty Ltd | System and method for anonymously indexing electronic record systems |
AU2004201058B1 (en) * | 2004-03-15 | 2004-09-09 | Lockstep Consulting Pty Ltd | Means and method of issuing Anonymous Public Key Certificates for indexing electronic record systems |
US20050229005A1 (en) * | 2004-04-07 | 2005-10-13 | Activcard Inc. | Security badge arrangement |
US20050234756A1 (en) * | 2004-04-14 | 2005-10-20 | Mitac International Corp. | Management system for integrating multiple logistic bodies and method thereof |
AU2005239005A1 (en) | 2004-04-30 | 2005-11-10 | Research In Motion Limited | System and method for handling data transfers |
JP4314152B2 (en) * | 2004-05-21 | 2009-08-12 | 株式会社東芝 | Electronic information assurance system, business terminal |
US20050273604A1 (en) * | 2004-06-04 | 2005-12-08 | Chengshing Lai | [mobile phone with file encryption function and method of encrypting/decrypting file thereof] |
US7272728B2 (en) | 2004-06-14 | 2007-09-18 | Iovation, Inc. | Network security and fraud detection system and method |
US8583921B1 (en) | 2004-06-30 | 2013-11-12 | Lingyan Shu | Method and system for identity authentication |
US20060041930A1 (en) * | 2004-08-23 | 2006-02-23 | Hafeman Joseph E | Accessing personal information |
US20060078790A1 (en) * | 2004-10-05 | 2006-04-13 | Polyplus Battery Company | Solid electrolytes based on lithium hafnium phosphate for active metal anode protection |
US7886144B2 (en) | 2004-10-29 | 2011-02-08 | Research In Motion Limited | System and method for retrieving certificates associated with senders of digitally signed messages |
AT500997B1 (en) * | 2004-11-09 | 2007-02-15 | Kapsch Trafficcom Ag | METHOD AND APPARATUS FOR USER-SPECIFIC INITIALIZATION OF IDENTIFICATION DEVICES IN THE FIELD |
JP5437548B2 (en) * | 2004-11-15 | 2014-03-12 | ハイデルベルガー ドルツクマシーネン アクチエンゲゼルシヤフト | Input signatures in electronic control systems |
US20060107041A1 (en) * | 2004-11-18 | 2006-05-18 | Michael Fiske | Assembling a security access system |
US20060107315A1 (en) * | 2004-11-18 | 2006-05-18 | Michael Fiske | System that uses access keys |
US20090228714A1 (en) * | 2004-11-18 | 2009-09-10 | Biogy, Inc. | Secure mobile device with online vault |
US8209751B2 (en) * | 2004-11-18 | 2012-06-26 | Biogy, Inc. | Receiving an access key |
US7979716B2 (en) * | 2004-11-18 | 2011-07-12 | Biogy, Inc. | Method of generating access keys |
US7886155B2 (en) | 2004-12-20 | 2011-02-08 | Biogy, Inc. | System for generating requests to a passcode protected entity |
US7770018B2 (en) * | 2004-11-18 | 2010-08-03 | Biogy, Inc. | Setting up a security access system |
US20060107312A1 (en) * | 2004-11-18 | 2006-05-18 | Michael Fiske | System for handing requests for access to a passcode protected entity |
US7565548B2 (en) * | 2004-11-18 | 2009-07-21 | Biogy, Inc. | Biometric print quality assurance |
US7702911B2 (en) * | 2004-11-18 | 2010-04-20 | Biogy, Inc. | Interfacing with a system that includes a passcode authenticator |
US20060107309A1 (en) * | 2004-11-18 | 2006-05-18 | Michael Fiske | Using an access key |
US7707622B2 (en) | 2004-11-18 | 2010-04-27 | Biogy, Inc. | API for a system having a passcode authenticator |
US8224753B2 (en) * | 2004-12-07 | 2012-07-17 | Farsheed Atef | System and method for identity verification and management |
US20080288786A1 (en) * | 2004-12-20 | 2008-11-20 | Michael Stephen Fiske | System with access keys |
RU2007127725A (en) * | 2004-12-20 | 2009-01-27 | ПРОКСЕНС, ЭлЭлСи (US) | PERSONAL DATA (PDK) AUTHENTICATION BY BIOMETRIC KEY |
US20060136717A1 (en) * | 2004-12-20 | 2006-06-22 | Mark Buer | System and method for authentication via a proximate device |
US8295484B2 (en) | 2004-12-21 | 2012-10-23 | Broadcom Corporation | System and method for securing data from a remote input device |
US20060156013A1 (en) * | 2005-01-07 | 2006-07-13 | Beeson Curtis L | Digital signature software using ephemeral private key and system |
US8874544B2 (en) * | 2005-01-13 | 2014-10-28 | International Business Machines Corporation | System and method for exposing internal search indices to internet search engines |
US7568104B2 (en) * | 2005-01-19 | 2009-07-28 | International Business Machines Corporation | Method and apparatus for adding signature information to electronic documents |
US8181020B2 (en) * | 2005-02-02 | 2012-05-15 | Insyde Software Corp. | System and method for securely storing firmware |
US20060179009A1 (en) * | 2005-02-08 | 2006-08-10 | International Business Machines Corporation | Management of terms and conditions for an agreement |
JP4615344B2 (en) * | 2005-03-24 | 2011-01-19 | 株式会社日立製作所 | Data processing system and database management method |
JP2006277199A (en) * | 2005-03-29 | 2006-10-12 | Fujitsu Ltd | Delivery object management system and delivery object storage warehouse |
US20060236098A1 (en) | 2005-03-31 | 2006-10-19 | Alexander Gantman | Multisigning - a protocol for robust multiple party digital signatures |
US8175889B1 (en) | 2005-04-06 | 2012-05-08 | Experian Information Solutions, Inc. | Systems and methods for tracking changes of address based on service disconnect/connect data |
DE102005018676B4 (en) * | 2005-04-21 | 2008-09-25 | Wincor Nixdorf International Gmbh | Key management procedure for cryptographic modules |
US7401731B1 (en) | 2005-05-27 | 2008-07-22 | Jpmorgan Chase Bank, Na | Method and system for implementing a card product with multiple customized relationships |
US20060288225A1 (en) * | 2005-06-03 | 2006-12-21 | Jung Edward K | User-centric question and answer for authentication and security |
CA2510366C (en) * | 2005-06-14 | 2013-02-26 | Certicom Corp. | System and method for remote device registration |
US7624432B2 (en) * | 2005-06-28 | 2009-11-24 | International Business Machines Corporation | Security and authorization in management agents |
US7614082B2 (en) | 2005-06-29 | 2009-11-03 | Research In Motion Limited | System and method for privilege management and revocation |
US20070027820A1 (en) * | 2005-07-28 | 2007-02-01 | Amir Elharar | Methods and systems for securing electronic transactions |
US20070030257A1 (en) * | 2005-08-04 | 2007-02-08 | Bhogal Kulvir S | Locking digital pen |
US7925578B1 (en) | 2005-08-26 | 2011-04-12 | Jpmorgan Chase Bank, N.A. | Systems and methods for performing scoring optimization |
US20070079125A1 (en) * | 2005-09-27 | 2007-04-05 | Lexmark International, Inc. | Interface protocol method and system |
US8306986B2 (en) * | 2005-09-30 | 2012-11-06 | American Express Travel Related Services Company, Inc. | Method, system, and computer program product for linking customer information |
US7748034B2 (en) * | 2005-10-12 | 2010-06-29 | Cisco Technology, Inc. | Strong anti-replay protection for IP traffic sent point to point or multi-cast to large groups |
US20070084638A1 (en) * | 2005-10-19 | 2007-04-19 | Clyde Bohnsack | Drilling fluid flow facilitation |
EA008186B1 (en) * | 2005-11-11 | 2007-04-27 | Фонд Сопровождения Инвестиционных Проектов "Генкей" | Method and device for obtaining and storing personal digital certificate and method for protected exchange of digital information |
US20070118485A1 (en) * | 2005-11-15 | 2007-05-24 | Norbert Gugerbauer | Interactive contract service |
US8181220B2 (en) | 2005-12-19 | 2012-05-15 | Adobe Systems Incorporated | Method and apparatus for digital rights management policies |
US8234494B1 (en) * | 2005-12-21 | 2012-07-31 | At&T Intellectual Property Ii, L.P. | Speaker-verification digital signatures |
US20070150415A1 (en) * | 2005-12-22 | 2007-06-28 | Bundy Ross E | Method and apparatus for creating and entering a PIN code |
FR2895608B1 (en) * | 2005-12-23 | 2008-03-21 | Trusted Logic Sa | METHOD FOR MAKING A SECURED COUNTER ON AN ON-BOARD COMPUTER SYSTEM HAVING A CHIP CARD |
DE102005062307A1 (en) * | 2005-12-24 | 2007-06-28 | T-Mobile International Ag & Co. Kg | Chip card e.g. subscriber identity module card, pre-arranging method for electronic signature services, involves generating asymmetrical code pair and signature-personal identification number on card, and conveying number to user by card |
US7929703B2 (en) * | 2005-12-28 | 2011-04-19 | Alcatel-Lucent Usa Inc. | Methods and system for managing security keys within a wireless network |
US8219129B2 (en) | 2006-01-06 | 2012-07-10 | Proxense, Llc | Dynamic real-time tiered client access |
US11206664B2 (en) | 2006-01-06 | 2021-12-21 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network |
US20070179903A1 (en) * | 2006-01-30 | 2007-08-02 | Microsoft Corporation | Identity theft mitigation |
US8122252B2 (en) * | 2006-02-28 | 2012-02-21 | Kryptiq Corporation | Cascaded digital signatures |
CN101484901B (en) * | 2006-02-28 | 2014-09-17 | 塞尔蒂卡姆公司 | System and method for controlling productive process |
US8615663B2 (en) * | 2006-04-17 | 2013-12-24 | Broadcom Corporation | System and method for secure remote biometric authentication |
US7593549B2 (en) * | 2006-04-27 | 2009-09-22 | Bruce Reiner | Apparatus and method for utilizing biometrics in medical applications |
US7904718B2 (en) * | 2006-05-05 | 2011-03-08 | Proxense, Llc | Personal digital key differentiation for secure transactions |
US8341397B2 (en) * | 2006-06-26 | 2012-12-25 | Mlr, Llc | Security system for handheld wireless devices using-time variable encryption keys |
US20080015986A1 (en) * | 2006-06-30 | 2008-01-17 | Wright Robert E | Systems, methods and computer program products for controlling online access to an account |
EP1876549A1 (en) * | 2006-07-07 | 2008-01-09 | Swisscom Mobile AG | Method and system for encrypted data transmission |
US11019007B1 (en) * | 2006-07-13 | 2021-05-25 | United Services Automobile Association (Usaa) | Systems and methods for providing electronic official documents |
US7949867B2 (en) | 2006-07-19 | 2011-05-24 | Rel-Id Technologies, Inc. | Secure communications |
US20080031459A1 (en) * | 2006-08-07 | 2008-02-07 | Seth Voltz | Systems and Methods for Identity-Based Secure Communications |
US8670564B1 (en) | 2006-08-14 | 2014-03-11 | Key Holdings, LLC | Data encryption system and method |
US8005759B2 (en) | 2006-08-17 | 2011-08-23 | Experian Information Solutions, Inc. | System and method for providing a score for a used vehicle |
US8321677B2 (en) * | 2006-09-21 | 2012-11-27 | Google Inc. | Pre-binding and tight binding of an on-line identity to a digital signature |
US7912865B2 (en) * | 2006-09-26 | 2011-03-22 | Experian Marketing Solutions, Inc. | System and method for linking multiple entities in a business database |
JP2008084229A (en) * | 2006-09-28 | 2008-04-10 | Fujitsu Ltd | Information leakage prevention device and information leakage prevention method |
EP2080158A4 (en) * | 2006-09-29 | 2011-06-22 | Scammell Dan | A system and method for verifying a user's identity in electronic transactions |
US7802719B2 (en) * | 2006-09-29 | 2010-09-28 | Sony Ericsson Mobile Communications Ab | System and method for presenting multiple transaction options in a portable device |
US8166532B2 (en) * | 2006-10-10 | 2012-04-24 | Honeywell International Inc. | Decentralized access control framework |
US8719954B2 (en) | 2006-10-11 | 2014-05-06 | Bassilic Technologies Llc | Method and system for secure distribution of selected content to be protected on an appliance-specific basis with definable permitted associated usage rights for the selected content |
US20080092239A1 (en) * | 2006-10-11 | 2008-04-17 | David H. Sitrick | Method and system for secure distribution of selected content to be protected |
US8619982B2 (en) * | 2006-10-11 | 2013-12-31 | Bassilic Technologies Llc | Method and system for secure distribution of selected content to be protected on an appliance specific basis |
US20080097777A1 (en) * | 2006-10-23 | 2008-04-24 | Ctm Software Corporation | Electronic document execution |
US8751815B2 (en) * | 2006-10-25 | 2014-06-10 | Iovation Inc. | Creating and verifying globally unique device-specific identifiers |
US7613915B2 (en) * | 2006-11-09 | 2009-11-03 | BroadOn Communications Corp | Method for programming on-chip non-volatile memory in a secure processor, and a device so programmed |
US9269221B2 (en) | 2006-11-13 | 2016-02-23 | John J. Gobbi | Configuration of interfaces for a location detection system and application |
US8700014B2 (en) | 2006-11-22 | 2014-04-15 | Bindu Rama Rao | Audio guided system for providing guidance to user of mobile device on multi-step activities |
US11256386B2 (en) | 2006-11-22 | 2022-02-22 | Qualtrics, Llc | Media management system supporting a plurality of mobile devices |
US8380175B2 (en) * | 2006-11-22 | 2013-02-19 | Bindu Rama Rao | System for providing interactive advertisements to user of mobile devices |
US10803474B2 (en) | 2006-11-22 | 2020-10-13 | Qualtrics, Llc | System for creating and distributing interactive advertisements to mobile devices |
US8478250B2 (en) | 2007-07-30 | 2013-07-02 | Bindu Rama Rao | Interactive media management server |
US8116456B2 (en) * | 2006-11-28 | 2012-02-14 | Oracle International Corporation | Techniques for managing heterogeneous key stores |
GB2446198A (en) * | 2006-12-01 | 2008-08-06 | David Irvine | Non-repudiation of messages in peer-to-peer network |
GB0625052D0 (en) * | 2006-12-15 | 2007-01-24 | Hewlett Packard Development Co | Evidence of manufacturing processes |
US20170344703A1 (en) | 2006-12-29 | 2017-11-30 | Kip Prod P1 Lp | Multi-services application gateway and system employing the same |
US9569587B2 (en) * | 2006-12-29 | 2017-02-14 | Kip Prod Pi Lp | Multi-services application gateway and system employing the same |
US11316688B2 (en) | 2006-12-29 | 2022-04-26 | Kip Prod P1 Lp | Multi-services application gateway and system employing the same |
US9602880B2 (en) | 2006-12-29 | 2017-03-21 | Kip Prod P1 Lp | Display inserts, overlays, and graphical user interfaces for multimedia systems |
WO2008085205A2 (en) | 2006-12-29 | 2008-07-17 | Prodea Systems, Inc. | System and method for providing network support services and premises gateway support infrastructure |
US11783925B2 (en) | 2006-12-29 | 2023-10-10 | Kip Prod P1 Lp | Multi-services application gateway and system employing the same |
US20080168273A1 (en) * | 2007-01-05 | 2008-07-10 | Chung Hyen V | Configuration mechanism for flexible messaging security protocols |
US8239688B2 (en) | 2007-01-07 | 2012-08-07 | Apple Inc. | Securely recovering a computing device |
US8254568B2 (en) | 2007-01-07 | 2012-08-28 | Apple Inc. | Secure booting a computing device |
US20080172331A1 (en) * | 2007-01-16 | 2008-07-17 | Graves Phillip C | Bill Payment Card Method and System |
US20080179393A1 (en) * | 2007-01-30 | 2008-07-31 | Nizam Antoo | Method and system using portable consumer device including payment capability |
US8606666B1 (en) | 2007-01-31 | 2013-12-10 | Experian Information Solutions, Inc. | System and method for providing an aggregation tool |
CN101622849B (en) | 2007-02-02 | 2014-06-11 | 网圣公司 | System and method for adding context to prevent data leakage over a computer network |
US9418501B2 (en) * | 2007-02-05 | 2016-08-16 | First Data Corporation | Method for digital signature authentication of pin-less debit card account transactions |
US20080185429A1 (en) * | 2007-02-05 | 2008-08-07 | First Data Corporation | Authentication Of PIN-Less Transactions |
US20080189209A1 (en) * | 2007-02-05 | 2008-08-07 | First Data Corporation | Real-Time Funds Transfer |
US9069967B2 (en) * | 2007-02-16 | 2015-06-30 | Veracode, Inc. | Assessment and analysis of software security flaws |
US8566247B1 (en) * | 2007-02-19 | 2013-10-22 | Robert H. Nagel | System and method for secure communications involving an intermediary |
US20080208735A1 (en) * | 2007-02-22 | 2008-08-28 | American Expresstravel Related Services Company, Inc., A New York Corporation | Method, System, and Computer Program Product for Managing Business Customer Contacts |
US9660812B2 (en) * | 2007-02-28 | 2017-05-23 | Red Hat, Inc. | Providing independent verification of information in a public forum |
US8090954B2 (en) | 2007-03-16 | 2012-01-03 | Microsoft Corporation | Prevention of unauthorized forwarding and authentication of signatures |
US8285656B1 (en) | 2007-03-30 | 2012-10-09 | Consumerinfo.Com, Inc. | Systems and methods for data verification |
US20080263644A1 (en) * | 2007-04-23 | 2008-10-23 | Doron Grinstein | Federated authorization for distributed computing |
US20080271145A1 (en) * | 2007-04-30 | 2008-10-30 | Schiller Mark R | Tamper indication system and method for a computing system |
US20080301016A1 (en) * | 2007-05-30 | 2008-12-04 | American Express Travel Related Services Company, Inc. General Counsel's Office | Method, System, and Computer Program Product for Customer Linking and Identification Capability for Institutions |
US8583915B1 (en) * | 2007-05-31 | 2013-11-12 | Bby Solutions, Inc. | Security and authentication systems and methods for personalized portable devices and associated systems |
US20090006846A1 (en) | 2007-06-27 | 2009-01-01 | Apple Inc. | Bluetooth device as security access key |
SE532600C2 (en) * | 2007-06-29 | 2010-03-02 | Oniteo Ab | Method and system for secure provisioning of hardware |
US7930249B2 (en) | 2007-07-11 | 2011-04-19 | Qualcomm Incorporated | Mobile wireless financial instrument for automatically selecting a payment instrument |
US8230490B2 (en) * | 2007-07-31 | 2012-07-24 | Keycorp | System and method for authentication of users in a secure computer system |
US7978850B2 (en) * | 2007-07-31 | 2011-07-12 | Lsi Corporation | Manufacturing embedded unique keys using a built in random number generator |
WO2009035283A2 (en) * | 2007-09-11 | 2009-03-19 | Lg Electronics Inc. | Secure signing method, secure authentication method and iptv system |
US8170998B2 (en) * | 2007-09-12 | 2012-05-01 | American Express Travel Related Services Company, Inc. | Methods, systems, and computer program products for estimating accuracy of linking of customer relationships |
US8060502B2 (en) | 2007-10-04 | 2011-11-15 | American Express Travel Related Services Company, Inc. | Methods, systems, and computer program products for generating data quality indicators for relationships in a database |
WO2009059408A1 (en) * | 2007-11-07 | 2009-05-14 | Toposis Corporation | System and method for multiparty billing of network services |
WO2009062182A1 (en) * | 2007-11-09 | 2009-05-14 | Topia Technology | Architecture for management of digital files across distributed network |
WO2009062194A1 (en) | 2007-11-09 | 2009-05-14 | Proxense, Llc | Proximity-sensor supporting multiple application services |
KR101442169B1 (en) * | 2007-11-27 | 2014-11-03 | 삼성전자주식회사 | A Public Key Infrastructure-based Bluetooth Smart-Key System and Operating Method Thereof |
US20090144170A1 (en) * | 2007-11-30 | 2009-06-04 | Mark Dickelman | Buyer-Seller Interfaces and Methods for Disparate Network Systems |
CN101170407B (en) * | 2007-12-03 | 2011-01-12 | 北京深思洛克软件技术股份有限公司 | A method for securely generating secret key pair and transmitting public key or certificate application file |
US8171528B1 (en) | 2007-12-06 | 2012-05-01 | Proxense, Llc | Hybrid device having a personal digital key and receiver-decoder circuit and methods of use |
US9990674B1 (en) | 2007-12-14 | 2018-06-05 | Consumerinfo.Com, Inc. | Card registry systems and methods |
US8127986B1 (en) | 2007-12-14 | 2012-03-06 | Consumerinfo.Com, Inc. | Card registry systems and methods |
US9251332B2 (en) | 2007-12-19 | 2016-02-02 | Proxense, Llc | Security system and method for controlling access to computing resources |
US9818071B2 (en) | 2007-12-21 | 2017-11-14 | Invention Science Fund I, Llc | Authorization rights for operational components |
US8752166B2 (en) | 2007-12-21 | 2014-06-10 | The Invention Science Fund I, Llc | Security-activated operational components |
US20110178619A1 (en) * | 2007-12-21 | 2011-07-21 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Security-activated robotic tasks |
US9626487B2 (en) * | 2007-12-21 | 2017-04-18 | Invention Science Fund I, Llc | Security-activated production device |
US9128476B2 (en) | 2007-12-21 | 2015-09-08 | The Invention Science Fund I, Llc | Secure robotic operational system |
US8286236B2 (en) * | 2007-12-21 | 2012-10-09 | The Invention Science Fund I, Llc | Manufacturing control system |
US9071436B2 (en) | 2007-12-21 | 2015-06-30 | The Invention Science Fund I, Llc | Security-activated robotic system |
US8429754B2 (en) * | 2007-12-21 | 2013-04-23 | The Invention Science Fund I, Llc | Control technique for object production rights |
US8622308B1 (en) | 2007-12-31 | 2014-01-07 | Jpmorgan Chase Bank, N.A. | System and method for processing transactions using a multi-account transactions device |
JP4993122B2 (en) * | 2008-01-23 | 2012-08-08 | 大日本印刷株式会社 | Platform integrity verification system and method |
GB0802585D0 (en) | 2008-02-12 | 2008-03-19 | Mtld Top Level Domain Ltd | Determining a property of communication device |
US8508336B2 (en) | 2008-02-14 | 2013-08-13 | Proxense, Llc | Proximity-based healthcare management system with automatic access to private information |
US8370948B2 (en) * | 2008-03-19 | 2013-02-05 | Websense, Inc. | System and method for analysis of electronic information dissemination events |
US8407784B2 (en) * | 2008-03-19 | 2013-03-26 | Websense, Inc. | Method and system for protection against information stealing software |
US9130986B2 (en) | 2008-03-19 | 2015-09-08 | Websense, Inc. | Method and system for protection against information stealing software |
US9015842B2 (en) | 2008-03-19 | 2015-04-21 | Websense, Inc. | Method and system for protection against information stealing software |
US9286596B2 (en) * | 2008-04-01 | 2016-03-15 | Topaz Systems, Inc. | Signing ceremony system and method |
US11120449B2 (en) | 2008-04-08 | 2021-09-14 | Proxense, Llc | Automated service-based order processing |
US8320638B2 (en) * | 2008-04-10 | 2012-11-27 | Pitt Alan M | Anonymous association system utilizing biometrics |
US8140855B2 (en) * | 2008-04-11 | 2012-03-20 | Microsoft Corp. | Security-enhanced log in |
US8150039B2 (en) * | 2008-04-15 | 2012-04-03 | Apple Inc. | Single security model in booting a computing device |
JP4807377B2 (en) * | 2008-05-13 | 2011-11-02 | ソニー株式会社 | COMMUNICATION DEVICE, COMMUNICATION METHOD, COMMUNICATION SYSTEM, AND SERVICE ISSUING METHOD |
US8812701B2 (en) * | 2008-05-21 | 2014-08-19 | Uniloc Luxembourg, S.A. | Device and method for secured communication |
US7522723B1 (en) * | 2008-05-29 | 2009-04-21 | Cheman Shaik | Password self encryption method and system and encryption by keys generated from personal secret information |
US9832069B1 (en) | 2008-05-30 | 2017-11-28 | F5 Networks, Inc. | Persistence based on server response in an IP multimedia subsystem (IMS) |
JP5083042B2 (en) * | 2008-05-30 | 2012-11-28 | 富士通株式会社 | Access control policy compliance check program |
US8209394B2 (en) * | 2008-06-02 | 2012-06-26 | Microsoft Corporation | Device-specific identity |
US7853493B2 (en) * | 2008-06-18 | 2010-12-14 | Consumerinfo.Com, Inc. | Personal finance integration system and method |
FR2932937B1 (en) * | 2008-06-24 | 2011-02-11 | Alcatel Lucent | ROUTER ASSOCIATED WITH A SECURE DEVICE. |
US8935528B2 (en) * | 2008-06-26 | 2015-01-13 | Microsoft Corporation | Techniques for ensuring authentication and integrity of communications |
EP2138970A1 (en) * | 2008-06-26 | 2009-12-30 | Nokia Siemens Networks Oy | Ordering scheme |
US8312033B1 (en) | 2008-06-26 | 2012-11-13 | Experian Marketing Solutions, Inc. | Systems and methods for providing an integrated identifier |
US9704161B1 (en) * | 2008-06-27 | 2017-07-11 | Amazon Technologies, Inc. | Providing information without authentication |
US9449319B1 (en) | 2008-06-30 | 2016-09-20 | Amazon Technologies, Inc. | Conducting transactions with dynamic passwords |
US8196213B2 (en) * | 2008-07-11 | 2012-06-05 | Microsoft Corporation | Verification of un-trusted code for consumption on an insecure device |
JP2010020712A (en) * | 2008-07-14 | 2010-01-28 | Canon Inc | Information processing apparatus, method for controlling information processing apparatus, storage medium, and program |
US8250627B2 (en) * | 2008-07-28 | 2012-08-21 | International Business Machines Corporation | Transaction authorization |
JP4623158B2 (en) * | 2008-07-29 | 2011-02-02 | コニカミノルタビジネステクノロジーズ株式会社 | IC card authentication apparatus, IC card authentication method, IC card authentication program, and recording medium |
US8447669B2 (en) | 2008-08-26 | 2013-05-21 | Visa U.S.A. Inc. | System and method for implementing financial assistance programs |
US8516259B2 (en) * | 2008-09-03 | 2013-08-20 | Alcatel Lucent | Verifying authenticity of voice mail participants in telephony networks |
EP2166483A1 (en) * | 2008-09-17 | 2010-03-24 | Tds Todos Data System Ab | Method and device for creating a digital signature |
GB2465138B (en) | 2008-10-10 | 2012-10-10 | Afilias Technologies Ltd | Transcoding web resources |
US9112910B2 (en) | 2008-10-14 | 2015-08-18 | International Business Machines Corporation | Method and system for authentication |
US8060424B2 (en) | 2008-11-05 | 2011-11-15 | Consumerinfo.Com, Inc. | On-line method and system for monitoring and reporting unused available credit |
US20100131409A1 (en) * | 2008-11-22 | 2010-05-27 | Google Inc. | Identification verification with user challenge |
US20100146050A1 (en) * | 2008-12-05 | 2010-06-10 | Amalto Technologies Corp. | Distributed document transformation for electronic business to business transactions |
US20100146281A1 (en) * | 2008-12-05 | 2010-06-10 | Amalto Technologies Corp. | Security and certificate management for electronic business to business transactions |
WO2010067433A1 (en) | 2008-12-11 | 2010-06-17 | 三菱電機株式会社 | Self-authentication communication device, self-authentication verification communication device, device authentication system, device authentication method for device authentication system, self-authentication communication program, and self-authentication verification communication program |
JP5802137B2 (en) | 2009-02-05 | 2015-10-28 | ダブリューダブリューパス コーポレイションWwpass Corporation | Centralized authentication system and method with secure private data storage |
US8296564B2 (en) | 2009-02-17 | 2012-10-23 | Microsoft Corporation | Communication channel access based on channel identifier and use policy |
US8423779B2 (en) * | 2009-02-23 | 2013-04-16 | Wms Gaming, Inc. | Compounding security with a security dongle |
US8224375B2 (en) | 2009-05-01 | 2012-07-17 | Qualcomm Incorporated | Proximity purchase ringtones |
WO2010132492A2 (en) | 2009-05-11 | 2010-11-18 | Experian Marketing Solutions, Inc. | Systems and methods for providing anonymized user profile data |
US9130972B2 (en) | 2009-05-26 | 2015-09-08 | Websense, Inc. | Systems and methods for efficient detection of fingerprinted data and information |
US20100301993A1 (en) * | 2009-05-28 | 2010-12-02 | International Business Machines Corporation | Pattern based security authorization |
US20100306076A1 (en) * | 2009-05-29 | 2010-12-02 | Ebay Inc. | Trusted Integrity Manager (TIM) |
US8484723B2 (en) * | 2009-06-05 | 2013-07-09 | Signix, Inc. | Method and system for signing and authenticating electronic documents via a signature authority which may act in concert with software controlled by the signer |
US8590003B2 (en) | 2009-06-15 | 2013-11-19 | Microsoft Corporation | Controlling access to resources by hosted entities |
US8326874B2 (en) * | 2009-06-17 | 2012-12-04 | Microsoft Corporation | Model-based implied authorization |
US9208459B2 (en) * | 2009-07-10 | 2015-12-08 | Certicom Corp. | System and method for performing serialization of devices |
US8914874B2 (en) * | 2009-07-21 | 2014-12-16 | Microsoft Corporation | Communication channel claim dependent security precautions |
US8504726B2 (en) * | 2009-07-27 | 2013-08-06 | Corista LLC | User targeted medical imaging and information packaging, compression and distribution system |
WO2011017041A2 (en) * | 2009-07-27 | 2011-02-10 | Corista LLC | System for networked digital pathology exchange |
US8356054B2 (en) * | 2009-11-10 | 2013-01-15 | International Business Machines Corporation | Management of resources in a host system |
US10027711B2 (en) | 2009-11-20 | 2018-07-17 | Alert Enterprise, Inc. | Situational intelligence |
US10019677B2 (en) | 2009-11-20 | 2018-07-10 | Alert Enterprise, Inc. | Active policy enforcement |
WO2011063269A1 (en) * | 2009-11-20 | 2011-05-26 | Alert Enterprise, Inc. | Method and apparatus for risk visualization and remediation |
US20110137740A1 (en) | 2009-12-04 | 2011-06-09 | Ashmit Bhattacharya | Processing value-ascertainable items |
EP2348450B1 (en) * | 2009-12-18 | 2013-11-06 | CompuGroup Medical AG | Database system, computer system, and computer-readable storage medium for decrypting a data record |
EP2348447B1 (en) * | 2009-12-18 | 2014-07-16 | CompuGroup Medical AG | A computer implemented method for generating a set of identifiers from a private key, computer implemented method and computing device |
EP2348452B1 (en) * | 2009-12-18 | 2014-07-02 | CompuGroup Medical AG | A computer implemented method for sending a message to a recipient user, receiving a message by a recipient user, a computer readable storage medium and a computer system |
EP2365456B1 (en) | 2010-03-11 | 2016-07-20 | CompuGroup Medical SE | Data structure, method and system for predicting medical conditions |
US9418205B2 (en) | 2010-03-15 | 2016-08-16 | Proxense, Llc | Proximity-based system for automatic application or data access and item tracking |
US8676684B2 (en) | 2010-04-12 | 2014-03-18 | Iovation Inc. | System and method for evaluating risk in fraud prevention |
US9141724B2 (en) | 2010-04-19 | 2015-09-22 | Afilias Technologies Limited | Transcoder hinting |
US20110295908A1 (en) * | 2010-05-27 | 2011-12-01 | International Business Machines Corporation | Detecting counterfeit devices |
WO2011149558A2 (en) | 2010-05-28 | 2011-12-01 | Abelow Daniel H | Reality alternate |
TWI422206B (en) * | 2010-05-31 | 2014-01-01 | Intercity Business Corp | Tolerant key verification method |
US8554631B1 (en) * | 2010-07-02 | 2013-10-08 | Jpmorgan Chase Bank, N.A. | Method and system for determining point of sale authorization |
GB2481843A (en) | 2010-07-08 | 2012-01-11 | Mtld Top Level Domain Ltd | Web based method of generating user interfaces |
US9322974B1 (en) | 2010-07-15 | 2016-04-26 | Proxense, Llc. | Proximity-based system for object tracking |
US8555332B2 (en) | 2010-08-20 | 2013-10-08 | At&T Intellectual Property I, L.P. | System for establishing communications with a mobile device server |
US9152727B1 (en) | 2010-08-23 | 2015-10-06 | Experian Marketing Solutions, Inc. | Systems and methods for processing consumer information for targeted marketing applications |
US20130041961A1 (en) | 2010-09-13 | 2013-02-14 | Frederick Mitchell Thrower, III | Systems and methods for electronic communication using unique identifiers associated with electronic addresses |
US8438285B2 (en) | 2010-09-15 | 2013-05-07 | At&T Intellectual Property I, L.P. | System for managing resources accessible to a mobile device server |
GB2484268A (en) | 2010-09-16 | 2012-04-11 | Uniloc Usa Inc | Psychographic profiling of users of computing devices |
US9147085B2 (en) | 2010-09-24 | 2015-09-29 | Blackberry Limited | Method for establishing a plurality of modes of operation on a mobile device |
US8959451B2 (en) | 2010-09-24 | 2015-02-17 | Blackberry Limited | Launching an application based on data classification |
EP2619704B1 (en) | 2010-09-24 | 2018-01-10 | BlackBerry Limited | Method and apparatus for differentiated access control |
WO2012037657A2 (en) | 2010-09-24 | 2012-03-29 | Research In Motion Limited | Method and apparatus for differentiated access control |
US10164922B2 (en) | 2010-09-27 | 2018-12-25 | International Business Machines Corporation | Secure electronic message conveyance |
AU2010224455B8 (en) * | 2010-09-28 | 2011-05-26 | Mu Hua Investments Limited | Biometric key |
US8478905B2 (en) | 2010-10-01 | 2013-07-02 | At&T Intellectual Property I, Lp | System for synchronizing to a mobile device server |
US8443420B2 (en) | 2010-10-01 | 2013-05-14 | At&T Intellectual Property I, L.P. | System for communicating with a mobile device server |
US8610546B2 (en) | 2010-10-01 | 2013-12-17 | At&T Intellectual Property I, L.P. | System for selecting resources accessible to a mobile device server |
US8639616B1 (en) | 2010-10-01 | 2014-01-28 | Experian Information Solutions, Inc. | Business to contact linkage system |
US8516039B2 (en) | 2010-10-01 | 2013-08-20 | At&T Intellectual Property I, L.P. | Apparatus and method for managing mobile device servers |
US8989055B2 (en) | 2011-07-17 | 2015-03-24 | At&T Intellectual Property I, L.P. | Processing messages with a device server operating in a telephone |
US8504449B2 (en) * | 2010-10-01 | 2013-08-06 | At&T Intellectual Property I, L.P. | Apparatus and method for managing software applications of a mobile device server |
US8863240B2 (en) * | 2010-10-20 | 2014-10-14 | T-Mobile Usa, Inc. | Method and system for smart card migration |
US20120209677A1 (en) | 2010-10-20 | 2012-08-16 | Mehta Kaushal N | Person-2-person social network marketing apparatuses, methods and systems |
US9525548B2 (en) * | 2010-10-21 | 2016-12-20 | Microsoft Technology Licensing, Llc | Provisioning techniques |
US9392316B2 (en) | 2010-10-28 | 2016-07-12 | At&T Intellectual Property I, L.P. | Messaging abstraction in a mobile device server |
US9064257B2 (en) * | 2010-11-02 | 2015-06-23 | Homayoon Beigi | Mobile device transaction using multi-factor authentication |
US10042993B2 (en) | 2010-11-02 | 2018-08-07 | Homayoon Beigi | Access control through multifactor authentication with multimodal biometrics |
US8800050B2 (en) * | 2010-11-09 | 2014-08-05 | Microsoft Corporation | Security system for computing resources pre-releases |
US8484186B1 (en) | 2010-11-12 | 2013-07-09 | Consumerinfo.Com, Inc. | Personalized people finder |
EP2453631B1 (en) | 2010-11-15 | 2016-06-22 | BlackBerry Limited | Data source based application sandboxing |
US8775794B2 (en) | 2010-11-15 | 2014-07-08 | Jpmorgan Chase Bank, N.A. | System and method for end to end encryption |
US9147042B1 (en) | 2010-11-22 | 2015-09-29 | Experian Information Solutions, Inc. | Systems and methods for data verification |
US9066123B2 (en) | 2010-11-30 | 2015-06-23 | At&T Intellectual Property I, L.P. | System for monetizing resources accessible to a mobile device server |
US9237155B1 (en) | 2010-12-06 | 2016-01-12 | Amazon Technologies, Inc. | Distributed policy enforcement with optimizing policy transformations |
IL210169A0 (en) | 2010-12-22 | 2011-03-31 | Yehuda Binder | System and method for routing-based internet security |
US8306914B2 (en) | 2011-01-07 | 2012-11-06 | American Express Travel Related Services Company, Inc. | Offsite financial account onboarding |
US8341080B2 (en) | 2011-01-07 | 2012-12-25 | Serve Virtual Enterprises, Inc. | Offsite financial account onboarding |
CN103608829A (en) * | 2011-01-18 | 2014-02-26 | 舍德Ip有限责任公司 | System and method for computerized negotiations based on coded integrity |
US20120195234A1 (en) * | 2011-01-31 | 2012-08-02 | Yigang Cai | Method for policy-based control of enterprise messaging |
US8817984B2 (en) | 2011-02-03 | 2014-08-26 | mSignia, Inc. | Cryptographic security functions based on anticipated changes in dynamic minutiae |
US11063920B2 (en) | 2011-02-03 | 2021-07-13 | mSignia, Inc. | Cryptographic security functions based on anticipated changes in dynamic minutiae |
WO2012106655A2 (en) | 2011-02-05 | 2012-08-09 | Visa International Service Association | Merchant-consumer bridging platform apparatuses, methods and systems |
DK2673741T3 (en) * | 2011-02-07 | 2021-01-25 | Scramcard Holdings Hong Kong Ltd | CHIP CARD WITH MEANS OF VERIFICATION |
WO2012109628A2 (en) | 2011-02-10 | 2012-08-16 | Visa International Service Assocation | Electronic coupon issuance and redemption apparatuses, methods and systems |
US10586227B2 (en) | 2011-02-16 | 2020-03-10 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
SG193481A1 (en) | 2011-02-16 | 2013-10-30 | Visa Int Service Ass | Snap mobile payment apparatuses, methods and systems |
US9265450B1 (en) | 2011-02-21 | 2016-02-23 | Proxense, Llc | Proximity-based system for object tracking and automatic application initialization |
WO2012116125A1 (en) | 2011-02-22 | 2012-08-30 | Visa International Service Association | Universal electronic payment apparatuses, methods and systems |
AU2012223415B2 (en) | 2011-02-28 | 2017-05-18 | Visa International Service Association | Secure anonymous transaction apparatuses, methods and systems |
WO2012122060A1 (en) | 2011-03-04 | 2012-09-13 | Visa International Service Association | Cloud service facilitator apparatuses, methods and systems |
US11514451B2 (en) | 2011-03-15 | 2022-11-29 | Capital One Services, Llc | Systems and methods for performing financial transactions using active authentication |
US9081982B2 (en) | 2011-04-18 | 2015-07-14 | Raytheon Company | Authorized data access based on the rights of a user and a location |
US9646291B2 (en) | 2011-05-11 | 2017-05-09 | Visa International Service Association | Electronic receipt manager apparatuses, methods and systems |
US8769642B1 (en) | 2011-05-31 | 2014-07-01 | Amazon Technologies, Inc. | Techniques for delegation of access privileges |
CN103797500A (en) | 2011-06-03 | 2014-05-14 | 维萨国际服务协会 | Virtual wallet card selection apparatuses, methods and systems |
US8600061B2 (en) * | 2011-06-24 | 2013-12-03 | Broadcom Corporation | Generating secure device secret key |
US10068084B2 (en) * | 2011-06-27 | 2018-09-04 | General Electric Company | Method and system of location-aware certificate based authentication |
US9582598B2 (en) | 2011-07-05 | 2017-02-28 | Visa International Service Association | Hybrid applications utilizing distributed models and views apparatuses, methods and systems |
US10121129B2 (en) | 2011-07-05 | 2018-11-06 | Visa International Service Association | Electronic wallet checkout platform apparatuses, methods and systems |
US9355393B2 (en) | 2011-08-18 | 2016-05-31 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9483606B1 (en) | 2011-07-08 | 2016-11-01 | Consumerinfo.Com, Inc. | Lifescore |
US8856956B2 (en) | 2011-07-08 | 2014-10-07 | Credibility Corp. | Automated entity verification |
US10438176B2 (en) | 2011-07-17 | 2019-10-08 | Visa International Service Association | Multiple merchant payment processor platform apparatuses, methods and systems |
WO2013019742A2 (en) * | 2011-07-29 | 2013-02-07 | Andrew Phipps | Systems and methods for electronic communication using unique identifiers associated with electronic addresses |
US20130039266A1 (en) | 2011-08-08 | 2013-02-14 | Research In Motion Limited | System and method to increase link adaptation performance with multi-level feedback |
US10318941B2 (en) | 2011-12-13 | 2019-06-11 | Visa International Service Association | Payment platform interface widget generation apparatuses, methods and systems |
US10242358B2 (en) | 2011-08-18 | 2019-03-26 | Visa International Service Association | Remote decoupled application persistent state apparatuses, methods and systems |
US10825001B2 (en) | 2011-08-18 | 2020-11-03 | Visa International Service Association | Multi-directional wallet connector apparatuses, methods and systems |
US9710807B2 (en) | 2011-08-18 | 2017-07-18 | Visa International Service Association | Third-party value added wallet features and interfaces apparatuses, methods and systems |
US10523618B2 (en) | 2011-09-07 | 2019-12-31 | Elwha Llc | Computational systems and methods for identifying a communications partner |
US9432190B2 (en) | 2011-09-07 | 2016-08-30 | Elwha Llc | Computational systems and methods for double-encrypting data for subsequent anonymous storage |
US20130060852A1 (en) * | 2011-09-07 | 2013-03-07 | Elwha LLC, a limited liability company of the State of Delaware | Computational systems and methods for regulating information flow during interactions |
US9491146B2 (en) | 2011-09-07 | 2016-11-08 | Elwha Llc | Computational systems and methods for encrypting data for anonymous storage |
US9747561B2 (en) | 2011-09-07 | 2017-08-29 | Elwha Llc | Computational systems and methods for linking users of devices |
US9141977B2 (en) | 2011-09-07 | 2015-09-22 | Elwha Llc | Computational systems and methods for disambiguating search terms corresponding to network members |
US10546306B2 (en) * | 2011-09-07 | 2020-01-28 | Elwha Llc | Computational systems and methods for regulating information flow during interactions |
US9167099B2 (en) | 2011-09-07 | 2015-10-20 | Elwha Llc | Computational systems and methods for identifying a communications partner |
US9928485B2 (en) | 2011-09-07 | 2018-03-27 | Elwha Llc | Computational systems and methods for regulating information flow during interactions |
US10606989B2 (en) | 2011-09-07 | 2020-03-31 | Elwha Llc | Computational systems and methods for verifying personal information during transactions |
US10546295B2 (en) * | 2011-09-07 | 2020-01-28 | Elwha Llc | Computational systems and methods for regulating information flow during interactions |
US20130060624A1 (en) * | 2011-09-07 | 2013-03-07 | Elwha LLC, a limited liability company of the State of Delaware | Computational systems and methods for regulating information flow during interactions |
US9690853B2 (en) | 2011-09-07 | 2017-06-27 | Elwha Llc | Computational systems and methods for regulating information flow during interactions |
WO2013036816A1 (en) * | 2011-09-08 | 2013-03-14 | Silver Spring Networks, Inc. | Systems and methods for securing the manufacturing supply chain |
AU2011101296B4 (en) | 2011-09-15 | 2012-06-28 | Uniloc Usa, Inc. | Hardware identification through cookies |
US9106691B1 (en) | 2011-09-16 | 2015-08-11 | Consumerinfo.Com, Inc. | Systems and methods of identity protection and management |
US9117225B2 (en) | 2011-09-16 | 2015-08-25 | Visa International Service Association | Apparatuses, methods and systems for transforming user infrastructure requests inputs to infrastructure design product and infrastructure allocation outputs |
US10223730B2 (en) | 2011-09-23 | 2019-03-05 | Visa International Service Association | E-wallet store injection search apparatuses, methods and systems |
CN103828289B (en) * | 2011-09-27 | 2017-08-22 | 皇家飞利浦有限公司 | Group membership is to a group secret management |
US9203613B2 (en) | 2011-09-29 | 2015-12-01 | Amazon Technologies, Inc. | Techniques for client constructed sessions |
US9197409B2 (en) | 2011-09-29 | 2015-11-24 | Amazon Technologies, Inc. | Key derivation techniques |
US9178701B2 (en) | 2011-09-29 | 2015-11-03 | Amazon Technologies, Inc. | Parameter based key derivation |
US20130085800A1 (en) * | 2011-10-03 | 2013-04-04 | Sap Ag | System and Method of Business Risk Based Authorization |
US8738516B1 (en) | 2011-10-13 | 2014-05-27 | Consumerinfo.Com, Inc. | Debt services candidate locator |
US9497220B2 (en) | 2011-10-17 | 2016-11-15 | Blackberry Limited | Dynamically generating perimeters |
US9161226B2 (en) | 2011-10-17 | 2015-10-13 | Blackberry Limited | Associating services to perimeters |
US9613219B2 (en) | 2011-11-10 | 2017-04-04 | Blackberry Limited | Managing cross perimeter access |
US8799227B2 (en) | 2011-11-11 | 2014-08-05 | Blackberry Limited | Presenting metadata from multiple perimeters |
CN102496218A (en) * | 2011-12-06 | 2012-06-13 | 广州广电运通金融电子股份有限公司 | Method and system for processing service of automatic teller machine |
US9953378B2 (en) * | 2012-04-27 | 2018-04-24 | Visa International Service Association | Social checkout widget generation and integration apparatuses, methods and systems |
WO2013090611A2 (en) * | 2011-12-13 | 2013-06-20 | Visa International Service Association | Dynamic widget generator apparatuses, methods and systems |
US10223710B2 (en) | 2013-01-04 | 2019-03-05 | Visa International Service Association | Wearable intelligent vision device apparatuses, methods and systems |
US11308227B2 (en) | 2012-01-09 | 2022-04-19 | Visa International Service Association | Secure dynamic page content and layouts apparatuses, methods and systems |
US10262148B2 (en) | 2012-01-09 | 2019-04-16 | Visa International Service Association | Secure dynamic page content and layouts apparatuses, methods and systems |
US8984276B2 (en) * | 2012-01-10 | 2015-03-17 | Jpmorgan Chase Bank, N.A. | System and method for device registration and authentication |
US9262604B2 (en) | 2012-02-01 | 2016-02-16 | Blackberry Limited | Method and system for locking an electronic device |
AU2013214801B2 (en) | 2012-02-02 | 2018-06-21 | Visa International Service Association | Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems |
US9698975B2 (en) | 2012-02-15 | 2017-07-04 | Blackberry Limited | Key management on device for perimeters |
US8931045B2 (en) | 2012-02-16 | 2015-01-06 | Blackberry Limited | Method and apparatus for management of multiple grouped resources on device |
US9077622B2 (en) | 2012-02-16 | 2015-07-07 | Blackberry Limited | Method and apparatus for automatic VPN login on interface selection |
US9306948B2 (en) | 2012-02-16 | 2016-04-05 | Blackberry Limited | Method and apparatus for separation of connection data by perimeter type |
CA2799903C (en) | 2012-02-17 | 2017-10-24 | Research In Motion Limited | Certificate management method based on connectivity and policy |
CA2800504C (en) | 2012-02-17 | 2019-09-10 | Research In Motion Limited | Designation of classes for certificates and keys |
US9559845B2 (en) * | 2012-03-01 | 2017-01-31 | Ologn Technologies Ag | Systems, methods and apparatuses for the secure transmission of media content |
WO2013128273A1 (en) | 2012-03-01 | 2013-09-06 | Ologn Technologies Ag | Systems, methods and apparatuses for the secure transmission and restricted use of media content |
US10332112B2 (en) * | 2012-03-27 | 2019-06-25 | International Business Machines Corporation | Authentication for transactions using near field communication |
US8892865B1 (en) | 2012-03-27 | 2014-11-18 | Amazon Technologies, Inc. | Multiple authority key derivation |
US9215076B1 (en) * | 2012-03-27 | 2015-12-15 | Amazon Technologies, Inc. | Key generation for hierarchical data access |
US8739308B1 (en) | 2012-03-27 | 2014-05-27 | Amazon Technologies, Inc. | Source identification for unauthorized copies of content |
CN104246808A (en) * | 2012-03-30 | 2014-12-24 | 英特尔公司 | Client security scoring |
US9853959B1 (en) | 2012-05-07 | 2017-12-26 | Consumerinfo.Com, Inc. | Storage and maintenance of personal data |
WO2014171924A1 (en) * | 2013-04-16 | 2014-10-23 | Otis Elevator Company | Controlling traffic without integrating with a security vendor |
US9369466B2 (en) | 2012-06-21 | 2016-06-14 | Blackberry Limited | Managing use of network resources |
US9660972B1 (en) | 2012-06-25 | 2017-05-23 | Amazon Technologies, Inc. | Protection from data security threats |
US8959337B2 (en) | 2012-06-25 | 2015-02-17 | International Business Machines Corporation | Digital certificate issuer-correlated digital signature verification |
US9258118B1 (en) | 2012-06-25 | 2016-02-09 | Amazon Technologies, Inc. | Decentralized verification in a distributed system |
US8972762B2 (en) | 2012-07-11 | 2015-03-03 | Blackberry Limited | Computing devices and methods for resetting inactivity timers on computing devices |
CN103748943A (en) * | 2012-08-17 | 2014-04-23 | 华为技术有限公司 | User equipment pairing processing method, network side device, and user equipment |
US9087191B2 (en) | 2012-08-24 | 2015-07-21 | Vmware, Inc. | Method and system for facilitating isolated workspace for applications |
US9094413B2 (en) * | 2012-08-27 | 2015-07-28 | Vmware, Inc. | Configuration profile validation on iOS Using SSL and redirect |
US9054863B2 (en) * | 2012-09-04 | 2015-06-09 | Rockwell Automation Asia Pacific Business Center Pte. Ltd. | Industrial protocol system authentication and firewall |
US9767269B2 (en) * | 2012-10-15 | 2017-09-19 | Nec Corporation | Security-function-design support device, security-function-design support method, and program |
US8656016B1 (en) | 2012-10-24 | 2014-02-18 | Blackberry Limited | Managing application execution and data access on a device |
US9075955B2 (en) | 2012-10-24 | 2015-07-07 | Blackberry Limited | Managing permission settings applied to applications |
US9654541B1 (en) | 2012-11-12 | 2017-05-16 | Consumerinfo.Com, Inc. | Aggregating user web browsing data |
US9916621B1 (en) | 2012-11-30 | 2018-03-13 | Consumerinfo.Com, Inc. | Presentation of credit score factors |
US9241259B2 (en) | 2012-11-30 | 2016-01-19 | Websense, Inc. | Method and apparatus for managing the transfer of sensitive information to mobile devices |
US9462332B2 (en) | 2012-12-05 | 2016-10-04 | At&T Intellectual Property I, L.P. | Method and apparatus for controlling a media device |
US9239937B2 (en) * | 2013-01-07 | 2016-01-19 | Lenovo (Singapore) Pte. Ltd. | Targeted security policy override |
US9077759B2 (en) | 2013-01-18 | 2015-07-07 | Apple Inc. | Conflict resolution for keychain syncing |
US9197700B2 (en) * | 2013-01-18 | 2015-11-24 | Apple Inc. | Keychain syncing |
CN104969176B (en) | 2013-01-29 | 2019-12-27 | 黑莓有限公司 | Method, device and medium for managing access of application to certificate and secret key |
US9697263B1 (en) | 2013-03-04 | 2017-07-04 | Experian Information Solutions, Inc. | Consumer data request fulfillment system |
US8972400B1 (en) | 2013-03-11 | 2015-03-03 | Consumerinfo.Com, Inc. | Profile data management |
US10102570B1 (en) | 2013-03-14 | 2018-10-16 | Consumerinfo.Com, Inc. | Account vulnerability alerts |
US9406085B1 (en) | 2013-03-14 | 2016-08-02 | Consumerinfo.Com, Inc. | System and methods for credit dispute processing, resolution, and reporting |
US8959595B2 (en) | 2013-03-15 | 2015-02-17 | Bullaproof, Inc. | Methods and systems for providing secure transactions |
AU2013100802B4 (en) | 2013-04-11 | 2013-11-14 | Uniloc Luxembourg S.A. | Device authentication using inter-person message metadata |
US10685398B1 (en) | 2013-04-23 | 2020-06-16 | Consumerinfo.Com, Inc. | Presenting credit score information |
US8695068B1 (en) | 2013-04-25 | 2014-04-08 | Uniloc Luxembourg, S.A. | Device authentication using display device irregularity |
WO2014183106A2 (en) | 2013-05-10 | 2014-11-13 | Proxense, Llc | Secure element as a digital pocket |
US9407440B2 (en) | 2013-06-20 | 2016-08-02 | Amazon Technologies, Inc. | Multiple authority data security and access |
US9521000B1 (en) | 2013-07-17 | 2016-12-13 | Amazon Technologies, Inc. | Complete forward access sessions |
US9641339B2 (en) | 2013-07-31 | 2017-05-02 | Arista Networks, Inc. | System and method for authentication for field replaceable units |
EP3029879B1 (en) | 2013-08-05 | 2018-07-04 | Sony Corporation | Information processing device, information processing method, and computer program |
US9311500B2 (en) | 2013-09-25 | 2016-04-12 | Amazon Technologies, Inc. | Data security using request-supplied keys |
US9237019B2 (en) | 2013-09-25 | 2016-01-12 | Amazon Technologies, Inc. | Resource locators with keys |
US20150091842A1 (en) | 2013-09-30 | 2015-04-02 | Synaptics Incorporated | Matrix sensor for image touch sensing |
US9298325B2 (en) | 2013-09-30 | 2016-03-29 | Synaptics Incorporated | Processing system for a capacitive sensing device |
US10042489B2 (en) | 2013-09-30 | 2018-08-07 | Synaptics Incorporated | Matrix sensor for image touch sensing |
US10756906B2 (en) | 2013-10-01 | 2020-08-25 | Kalman Csaba Toth | Architecture and methods for self-sovereign digital identity |
US9646150B2 (en) * | 2013-10-01 | 2017-05-09 | Kalman Csaba Toth | Electronic identity and credentialing system |
EP2860904A1 (en) * | 2013-10-08 | 2015-04-15 | Thomson Licensing | Method for signing a set of binary elements, and updating such signature, corresponding electronic device and computer program product |
US10243945B1 (en) | 2013-10-28 | 2019-03-26 | Amazon Technologies, Inc. | Managed identity federation |
US9942396B2 (en) | 2013-11-01 | 2018-04-10 | Adobe Systems Incorporated | Document distribution and interaction |
US9058626B1 (en) | 2013-11-13 | 2015-06-16 | Jpmorgan Chase Bank, N.A. | System and method for financial services device usage |
US10325314B1 (en) | 2013-11-15 | 2019-06-18 | Consumerinfo.Com, Inc. | Payment reporting systems |
US10102536B1 (en) | 2013-11-15 | 2018-10-16 | Experian Information Solutions, Inc. | Micro-geographic aggregation system |
US9477737B1 (en) | 2013-11-20 | 2016-10-25 | Consumerinfo.Com, Inc. | Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules |
US9282107B1 (en) * | 2013-11-21 | 2016-03-08 | Intuit Inc. | Secure verification of website claims |
US9529851B1 (en) | 2013-12-02 | 2016-12-27 | Experian Information Solutions, Inc. | Server architecture for electronic data quality processing |
US9420007B1 (en) | 2013-12-04 | 2016-08-16 | Amazon Technologies, Inc. | Access control using impersonization |
US9544149B2 (en) * | 2013-12-16 | 2017-01-10 | Adobe Systems Incorporated | Automatic E-signatures in response to conditions and/or events |
CN104767613B (en) * | 2014-01-02 | 2018-02-13 | 腾讯科技(深圳)有限公司 | Signature verification method, apparatus and system |
US9374368B1 (en) | 2014-01-07 | 2016-06-21 | Amazon Technologies, Inc. | Distributed passcode verification system |
US9292711B1 (en) | 2014-01-07 | 2016-03-22 | Amazon Technologies, Inc. | Hardware secret usage limits |
US9369461B1 (en) | 2014-01-07 | 2016-06-14 | Amazon Technologies, Inc. | Passcode verification using hardware secrets |
US9262642B1 (en) | 2014-01-13 | 2016-02-16 | Amazon Technologies, Inc. | Adaptive client-aware session security as a service |
US9619614B2 (en) * | 2014-02-03 | 2017-04-11 | Roberto Rodriguez | Method, apparatus, and computer-readable medium for integrating and sharing patient-related information via an authenticated application programming interface |
US10262362B1 (en) | 2014-02-14 | 2019-04-16 | Experian Information Solutions, Inc. | Automatic generation of code for attributes |
US10771255B1 (en) | 2014-03-25 | 2020-09-08 | Amazon Technologies, Inc. | Authenticated storage operations |
US20150281468A1 (en) * | 2014-03-27 | 2015-10-01 | Globalpay Solutions Usa, Inc. | Method for Financing Purchases for Others Using a Sender's Charge Account |
US9892457B1 (en) | 2014-04-16 | 2018-02-13 | Consumerinfo.Com, Inc. | Providing credit data in search results |
US9413533B1 (en) | 2014-05-02 | 2016-08-09 | Nok Nok Labs, Inc. | System and method for authorizing a new authenticator |
US9577999B1 (en) | 2014-05-02 | 2017-02-21 | Nok Nok Labs, Inc. | Enhanced security for registration of authentication devices |
US10558969B2 (en) * | 2014-06-23 | 2020-02-11 | Visa International Service Association | Modified confirmation element data for transaction confirmation |
US9258117B1 (en) | 2014-06-26 | 2016-02-09 | Amazon Technologies, Inc. | Mutual authentication with symmetric secrets and signatures |
US10326597B1 (en) | 2014-06-27 | 2019-06-18 | Amazon Technologies, Inc. | Dynamic response signing capability in a distributed system |
US9455979B2 (en) | 2014-07-31 | 2016-09-27 | Nok Nok Labs, Inc. | System and method for establishing trust using secure transmission protocols |
US9749131B2 (en) | 2014-07-31 | 2017-08-29 | Nok Nok Labs, Inc. | System and method for implementing a one-time-password using asymmetric cryptography |
JP6219248B2 (en) * | 2014-08-25 | 2017-10-25 | 株式会社東芝 | Information processing apparatus and communication apparatus |
WO2016040920A1 (en) * | 2014-09-14 | 2016-03-17 | Thompson Aerospace, Inc. | Method and system for security and authentication of aircraft data transmissions |
US9736154B2 (en) | 2014-09-16 | 2017-08-15 | Nok Nok Labs, Inc. | System and method for integrating an authentication service within a network architecture |
US9489508B2 (en) | 2014-11-13 | 2016-11-08 | Seagate Technology Llc | Device functionality access control using unique device credentials |
US20160173502A1 (en) * | 2014-12-15 | 2016-06-16 | International Business Machines Corporation | Jurisdictional cloud data access |
US10333696B2 (en) | 2015-01-12 | 2019-06-25 | X-Prime, Inc. | Systems and methods for implementing an efficient, scalable homomorphic transformation of encrypted data with minimal data expansion and improved processing efficiency |
US11216468B2 (en) | 2015-02-08 | 2022-01-04 | Visa International Service Association | Converged merchant processing apparatuses, methods and systems |
US10157339B2 (en) | 2015-03-03 | 2018-12-18 | WonderHealth, LLC | Access control for encrypted data in machine-readable identifiers |
US9774571B2 (en) | 2015-03-10 | 2017-09-26 | Microsoft Technology Licensing, Llc | Automatic provisioning of meeting room device |
US20160269409A1 (en) | 2015-03-13 | 2016-09-15 | Microsoft Technology Licensing, Llc | Meeting Join for Meeting Device |
SE539942C2 (en) * | 2015-03-25 | 2018-02-06 | Crunchfish Ab | Asset authentication in a dynamic, proximity-based network of communication devices |
KR102284954B1 (en) * | 2015-04-08 | 2021-08-03 | 삼성전자 주식회사 | Method and apparatus for downloading a profile in a wireless communication system |
US11140171B1 (en) | 2015-06-05 | 2021-10-05 | Apple Inc. | Establishing and verifying identity using action sequences while protecting user privacy |
US10868672B1 (en) | 2015-06-05 | 2020-12-15 | Apple Inc. | Establishing and verifying identity using biometrics while protecting user privacy |
US10122689B2 (en) | 2015-06-16 | 2018-11-06 | Amazon Technologies, Inc. | Load balancing with handshake offload |
US10122692B2 (en) | 2015-06-16 | 2018-11-06 | Amazon Technologies, Inc. | Handshake offload |
US10878399B1 (en) | 2015-07-02 | 2020-12-29 | Jpmorgan Chase Bank, N.A. | System and method for implementing payment with a mobile payment device |
US11521203B2 (en) * | 2015-07-09 | 2022-12-06 | Cryptography Research, Inc. | Generating a cryptographic key based on transaction data of mobile payments |
JP6483827B2 (en) * | 2015-07-13 | 2019-03-13 | 日本電信電話株式会社 | Agreement agreement method, agreement verification method, agreement agreement system, agreement validation device, agreement agreement device, agreement agreement program and agreement validation program |
US10129035B2 (en) | 2015-08-10 | 2018-11-13 | Data I/O Corporation | Device birth certificate |
US9935777B2 (en) | 2015-08-31 | 2018-04-03 | Adobe Systems Incorporated | Electronic signature framework with enhanced security |
US20170134280A1 (en) * | 2015-11-11 | 2017-05-11 | Mastercard International Incorporated | Method and system for validation of hashed data via acceptance frames |
US10067587B2 (en) | 2015-12-29 | 2018-09-04 | Synaptics Incorporated | Routing conductors in an integrated display device and sensing device |
US20170200244A1 (en) * | 2016-01-07 | 2017-07-13 | Adobe Systems Incorporated | Systems and Techniques for Integrating Electronic Signature Platforms with Social Messaging Applications for Authenticated Electronic Documents |
CN105471918B (en) * | 2016-01-13 | 2018-06-12 | 中山大学 | A kind of agency's weight Universal designated verifier signature method |
US10476680B2 (en) | 2016-02-03 | 2019-11-12 | Ememory Technology Inc. | Electronic device with self-protection and anti-cloning capabilities and related method |
US10863558B2 (en) * | 2016-03-30 | 2020-12-08 | Schweitzer Engineering Laboratories, Inc. | Communication device for implementing trusted relationships in a software defined network |
US11120450B1 (en) * | 2016-05-11 | 2021-09-14 | United Services Automobile Association (Usaa) | Dynamic risk assessment for security features |
US10347215B2 (en) | 2016-05-27 | 2019-07-09 | Adobe Inc. | Multi-device electronic signature framework |
US10116440B1 (en) | 2016-08-09 | 2018-10-30 | Amazon Technologies, Inc. | Cryptographic key management for imported cryptographic keys |
WO2018063167A1 (en) | 2016-09-27 | 2018-04-05 | Visa International Service Association | Distributed electronic record and transaction history |
US9742742B1 (en) | 2016-11-18 | 2017-08-22 | Vaultara LLC | Secure data transfer system and method |
US10715520B2 (en) * | 2016-12-08 | 2020-07-14 | Mastercard International Incorporated | Systems and methods for decentralized biometric enrollment |
US10366392B2 (en) | 2017-01-12 | 2019-07-30 | Bank Of America Corporation | Marker code generation for resource distribution authority flagging |
CN116205724A (en) | 2017-01-31 | 2023-06-02 | 益百利信息解决方案公司 | Large scale heterogeneous data ingestion and user resolution |
US20180248869A1 (en) * | 2017-02-28 | 2018-08-30 | Panasonic Intellectual Property Management Co., Ltd. | Mobile device theme park or resort experience dongle |
US10503919B2 (en) | 2017-04-10 | 2019-12-10 | Adobe Inc. | Electronic signature framework with keystroke biometric authentication |
US11526955B2 (en) * | 2017-05-30 | 2022-12-13 | Entersekt International Limited | Protocol-based system and method for establishing a multi-party contract |
US10489609B1 (en) * | 2017-06-06 | 2019-11-26 | Xilinx, Inc. | Restricting programmable integrated circuits to specific applications |
SG10201705868TA (en) * | 2017-07-18 | 2019-02-27 | Mastercard International Inc | Electronic signature processing apparatus and methods |
US10447486B2 (en) * | 2017-07-19 | 2019-10-15 | Spyrus, Inc. | Remote attestation of a security module's assurance level |
US10713657B2 (en) * | 2017-08-01 | 2020-07-14 | Capital One Services, Llc | Systems and methods for estimating authenticity of local network of device initiating remote transaction |
CN107395370B (en) * | 2017-09-05 | 2020-07-14 | 深圳奥联信息安全技术有限公司 | Identification-based digital signature method and device |
US10666446B2 (en) * | 2017-11-15 | 2020-05-26 | Xage Security, Inc. | Decentralized enrollment and revocation of devices |
CN109982150B (en) * | 2017-12-27 | 2020-06-23 | 国家新闻出版广电总局广播科学研究院 | Trust chain establishing method of intelligent television terminal and intelligent television terminal |
US20210004906A1 (en) * | 2018-02-08 | 2021-01-07 | 2Bc Innovations, Llc | Modifying a portfolio of blockchain-encoded rived longevity-contingent instruments |
US20200402167A1 (en) * | 2018-02-08 | 2020-12-24 | 2Bc Innovations, Llc | Updating a portfolio of blockchain-encoded rived longevity-contingent instruments |
US10795986B2 (en) | 2018-02-12 | 2020-10-06 | Ge Energy Power Conversion Technology Limited | Method and system for authenticating a component in a power converter |
US11188897B2 (en) * | 2018-02-13 | 2021-11-30 | Bank Of America Corporation | Multi-tiered digital wallet security |
EP3537337B1 (en) * | 2018-03-05 | 2023-10-25 | Nxp B.V. | User authentication system and method for enrolling fingerprint reference data |
US10887305B1 (en) | 2018-03-30 | 2021-01-05 | Mckesson Corporation | Method and apparatus for generating and providing a temporary password to control access to a record created in response to an electronic message |
EP3564846A1 (en) | 2018-04-30 | 2019-11-06 | Merck Patent GmbH | Methods and systems for automatic object recognition and authentication |
WO2019246399A1 (en) * | 2018-06-20 | 2019-12-26 | Google Llc | Digital ledger for unique item ids with ownership |
US11373202B2 (en) * | 2018-07-16 | 2022-06-28 | Mastercard International Incorporated | Method and system for referral fraud prevention via blockchain |
US20200074541A1 (en) | 2018-09-05 | 2020-03-05 | Consumerinfo.Com, Inc. | Generation of data structures based on categories of matched data items |
US10963434B1 (en) | 2018-09-07 | 2021-03-30 | Experian Information Solutions, Inc. | Data architecture for supporting multiple search models |
US11301853B2 (en) * | 2018-09-13 | 2022-04-12 | Paypal, Inc. | Speculative transaction operations for recognized devices |
US10489781B1 (en) * | 2018-10-02 | 2019-11-26 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
CN109493023B (en) * | 2018-10-17 | 2022-01-25 | 珠海横琴井通容智科技信息有限公司 | Mobile payment settlement method based on tamper-proof encryption algorithm |
US11315179B1 (en) | 2018-11-16 | 2022-04-26 | Consumerinfo.Com, Inc. | Methods and apparatuses for customized card recommendations |
US11050571B2 (en) | 2019-02-14 | 2021-06-29 | Carrott Richard F | Systems for producing and maintaining verified electronic signatures |
US11238656B1 (en) | 2019-02-22 | 2022-02-01 | Consumerinfo.Com, Inc. | System and method for an augmented reality experience via an artificial intelligence bot |
US11765164B2 (en) * | 2019-02-26 | 2023-09-19 | Amazon Technologies, Inc. | Server-based setup for connecting a device to a local area network |
US10425230B1 (en) * | 2019-03-01 | 2019-09-24 | Capital One Services, Llc | Identity and electronic signature verification in blockchain |
TWI772654B (en) * | 2019-06-21 | 2022-08-01 | 天宿智能科技股份有限公司 | Escrowing system for cross-blockchain third-party settlement and method thereof |
US11783342B1 (en) * | 2019-07-09 | 2023-10-10 | Wells Fargo Bank, N.A. | Blockchain blacklist anti-money laundering system (BBAMLS) |
US11941065B1 (en) | 2019-09-13 | 2024-03-26 | Experian Information Solutions, Inc. | Single identifier platform for storing entity data |
US11349660B2 (en) * | 2019-09-19 | 2022-05-31 | Bose Corporation | Secure self-identification of a device |
US20210111902A1 (en) * | 2019-10-11 | 2021-04-15 | Qualcomm Incorporated | System information protection at a network function in the core network |
US11526859B1 (en) | 2019-11-12 | 2022-12-13 | Bottomline Technologies, Sarl | Cash flow forecasting using a bottoms-up machine learning approach |
US11532040B2 (en) | 2019-11-12 | 2022-12-20 | Bottomline Technologies Sarl | International cash management software using machine learning |
TWI725623B (en) * | 2019-11-15 | 2021-04-21 | 倍加科技股份有限公司 | Point-to-point authority management method based on manager's self-issued tickets |
US11659001B2 (en) | 2019-12-12 | 2023-05-23 | General Electric Company | Non-intrusive replay attack detection system |
US20240046258A1 (en) * | 2019-12-18 | 2024-02-08 | Wells Fargo Bank, N.A. | Group payment accounts |
FR3106909B1 (en) | 2020-01-31 | 2022-02-18 | St Microelectronics Grenoble 2 | IC CONFIGURED TO PERFORM SYMMETRIC ENCRYPTION OPERATIONS WITH SECRET KEY PROTECTION |
US11121864B1 (en) * | 2020-03-13 | 2021-09-14 | International Business Machines Corporation | Secure private key distribution between endpoint instances |
CN111401901B (en) * | 2020-03-23 | 2021-06-04 | 腾讯科技(深圳)有限公司 | Authentication method and device of biological payment device, computer device and storage medium |
US11704671B2 (en) | 2020-04-02 | 2023-07-18 | Bottomline Technologies Limited | Financial messaging transformation-as-a-service |
US11539648B2 (en) * | 2020-07-27 | 2022-12-27 | Bytedance Inc. | Data model of a messaging service |
CN112039674B (en) * | 2020-08-06 | 2021-07-20 | 珠海格力电器股份有限公司 | Central control system access and signature identification generation method and device and storage medium |
US11658832B2 (en) | 2020-09-22 | 2023-05-23 | Bank Of America Corporation | Information security using data control ledgers |
US11763296B2 (en) | 2020-09-22 | 2023-09-19 | Bank Of America Corporation | Information security using integrated data control ledgers |
US11593351B2 (en) | 2020-09-22 | 2023-02-28 | Bank Of America Corporation | Error correction for data control ledgers |
US11573953B2 (en) | 2020-09-22 | 2023-02-07 | Bank Of America Corporation | Error correction for integrated data control ledgers |
US20220245122A1 (en) * | 2021-01-29 | 2022-08-04 | Docusign, Inc. | Document package modifications based on organization policies in a document management platform |
WO2022192659A1 (en) * | 2021-03-12 | 2022-09-15 | Visa International Service Association | System, method, and computer program product for secure client device and consumer authentication |
CN112948831B (en) * | 2021-03-12 | 2024-02-13 | 安天科技集团股份有限公司 | Application risk identification method and device |
US11880377B1 (en) | 2021-03-26 | 2024-01-23 | Experian Information Solutions, Inc. | Systems and methods for entity resolution |
US20230011621A1 (en) * | 2021-07-10 | 2023-01-12 | Artema Labs, Inc | Artifact Origination and Content Tokenization |
US11790057B2 (en) | 2021-08-17 | 2023-10-17 | Sap Se | Controlling program execution using an access key |
US11336564B1 (en) | 2021-09-01 | 2022-05-17 | Schweitzer Engineering Laboratories, Inc. | Detection of active hosts using parallel redundancy protocol in software defined networks |
US11750502B2 (en) | 2021-09-01 | 2023-09-05 | Schweitzer Engineering Laboratories, Inc. | Detection of in-band software defined network controllers using parallel redundancy protocol |
US20230385840A1 (en) * | 2022-05-27 | 2023-11-30 | Capital One Services, Llc | System and method for reducing government identification fraud |
US11843619B1 (en) * | 2022-10-07 | 2023-12-12 | Uab 360 It | Stateless system to enable data breach notification |
Citations (99)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3962539A (en) * | 1975-02-24 | 1976-06-08 | International Business Machines Corporation | Product block cipher system for data security |
US4200770A (en) * | 1977-09-06 | 1980-04-29 | Stanford University | Cryptographic apparatus and method |
US4218582A (en) * | 1977-10-06 | 1980-08-19 | The Board Of Trustees Of The Leland Stanford Junior University | Public key cryptographic apparatus and method |
US4405829A (en) * | 1977-12-14 | 1983-09-20 | Massachusetts Institute Of Technology | Cryptographic communications system and method |
US4408203A (en) * | 1978-01-09 | 1983-10-04 | Mastercard International, Inc. | Security system for electronic funds transfer system |
US4424414A (en) * | 1978-05-01 | 1984-01-03 | Board Of Trustees Of The Leland Stanford Junior University | Exponentiation cryptographic apparatus and method |
US4652698A (en) * | 1984-08-13 | 1987-03-24 | Ncr Corporation | Method and system for providing system security in a remote terminal environment |
US4734564A (en) * | 1985-05-02 | 1988-03-29 | Visa International Service Association | Transaction system with off-line risk assessment |
US4748668A (en) * | 1986-07-09 | 1988-05-31 | Yeda Research And Development Company Limited | Method, apparatus and article for identification and signature |
US4798668A (en) * | 1986-01-31 | 1989-01-17 | Union Oil Company Of California | Extraction of hydrocarbon-containing solids |
US4823388A (en) * | 1984-06-25 | 1989-04-18 | Kabushiki Kaisha Toshiba | Communications network using an enciphering and deciphering device |
US4825050A (en) * | 1983-09-13 | 1989-04-25 | Transaction Security Corporation | Security transaction system for financial data |
US4850017A (en) * | 1987-05-29 | 1989-07-18 | International Business Machines Corp. | Controlled use of cryptographic keys via generating station established control values |
US4856077A (en) * | 1986-04-28 | 1989-08-08 | Eric Rothfjell | Method of signature verification and device for carrying out the method |
US4868877A (en) * | 1988-02-12 | 1989-09-19 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
US4879747A (en) * | 1988-03-21 | 1989-11-07 | Leighton Frank T | Method and system for personal identification |
US4885788A (en) * | 1986-02-17 | 1989-12-05 | Hitachi, Ltd. | IC card |
US4897920A (en) * | 1987-06-19 | 1990-02-06 | Dunbar Donald W | Sheath cutting tool |
US4928298A (en) * | 1984-08-07 | 1990-05-22 | Nix Company, Ltd. | Information-bearing sheet for X-ray film |
US4944021A (en) * | 1984-04-18 | 1990-07-24 | Nec Corporation | Identification system employing verification of fingerprints |
US4995086A (en) * | 1986-05-06 | 1991-02-19 | Siemens Aktiengesellschaft | Arrangement and procedure for determining the authorization of individuals by verifying their fingerprints |
US5001752A (en) * | 1989-10-13 | 1991-03-19 | Fischer Addison M | Public/key date-time notary facility |
US5018196A (en) * | 1985-09-04 | 1991-05-21 | Hitachi, Ltd. | Method for electronic transaction with digital signature |
US5025373A (en) * | 1988-06-30 | 1991-06-18 | Jml Communications, Inc. | Portable personal-banking system |
US5097504A (en) * | 1986-03-19 | 1992-03-17 | Infoscript | Method and device for qualitative saving of digitized data |
US5140634A (en) * | 1987-09-07 | 1992-08-18 | U.S Philips Corporation | Method and apparatus for authenticating accreditations and for authenticating and signing messages |
US5209208A (en) * | 1989-08-08 | 1993-05-11 | Robert Bosch Gmbh | Fuel injection pump for diesel internal combustion engines |
US5214703A (en) * | 1990-05-18 | 1993-05-25 | Ascom Tech Ag | Device for the conversion of a digital block and use of same |
US5225978A (en) * | 1989-01-25 | 1993-07-06 | Usisys Corp. | Document processing system having integrated expert module |
US5231668A (en) * | 1991-07-26 | 1993-07-27 | The United States Of America, As Represented By The Secretary Of Commerce | Digital signature algorithm |
US5280527A (en) * | 1992-04-14 | 1994-01-18 | Kamahira Safe Co., Inc. | Biometric token for authorizing access to a host system |
US5412703A (en) * | 1993-02-04 | 1995-05-02 | Institute For Radiological Image Science, Inc. | Reduced partial volume artifacts in image reconstruction, with application to X-ray computed tomography |
US5422953A (en) * | 1993-05-05 | 1995-06-06 | Fischer; Addison M. | Personal date/time notary device |
US5453601A (en) * | 1991-11-15 | 1995-09-26 | Citibank, N.A. | Electronic-monetary system |
US5455865A (en) * | 1989-05-09 | 1995-10-03 | Digital Equipment Corporation | Robust packet routing over a distributed network containing malicious failures |
US5473143A (en) * | 1991-09-23 | 1995-12-05 | Atm Communications International, Inc. | ATM/POS based electronic mail system |
US5502766A (en) * | 1992-04-17 | 1996-03-26 | Secure Computing Corporation | Data enclave and trusted path system |
US5509071A (en) * | 1994-04-01 | 1996-04-16 | Microelectronics And Computer Technology Corporation | Electronic proof of receipt |
US5534855A (en) * | 1992-07-20 | 1996-07-09 | Digital Equipment Corporation | Method and system for certificate based alias detection |
US5539828A (en) * | 1994-05-31 | 1996-07-23 | Intel Corporation | Apparatus and method for providing secured communications |
US5557518A (en) * | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
US5563946A (en) * | 1994-04-25 | 1996-10-08 | International Business Machines Corporation | Method and apparatus for enabling trial period use of software products: method and apparatus for passing encrypted files between data processing systems |
US5568552A (en) * | 1994-09-07 | 1996-10-22 | Intel Corporation | Method for providing a roving software license from one node to another node |
US5577120A (en) * | 1995-05-01 | 1996-11-19 | Lucent Technologies Inc. | Method and apparatus for restrospectively identifying an individual who had engaged in a commercial or retail transaction or the like |
US5586036A (en) * | 1994-07-05 | 1996-12-17 | Pitney Bowes Inc. | Postage payment system with security for sensitive mailer data and enhanced carrier data functionality |
US5590197A (en) * | 1995-04-04 | 1996-12-31 | V-One Corporation | Electronic payment system and method |
US5598474A (en) * | 1994-03-29 | 1997-01-28 | Neldon P Johnson | Process for encrypting a fingerprint onto an I.D. card |
US5604801A (en) * | 1995-02-03 | 1997-02-18 | International Business Machines Corporation | Public key data communications system under control of a portable security device |
US5606609A (en) * | 1994-09-19 | 1997-02-25 | Scientific-Atlanta | Electronic document verification system and method |
US5615266A (en) * | 1995-07-13 | 1997-03-25 | Motorola, Inc | Secure communication setup method |
US5615268A (en) * | 1995-01-17 | 1997-03-25 | Document Authentication Systems, Inc. | System and method for electronic transmission storage and retrieval of authenticated documents |
US5619574A (en) * | 1995-02-13 | 1997-04-08 | Eta Technologies Corporation | Personal access management system |
US5619177A (en) * | 1995-01-27 | 1997-04-08 | Mjb Company | Shape memory alloy microactuator having an electrostatic force and heating means |
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 |
US5625690A (en) * | 1993-11-15 | 1997-04-29 | Lucent Technologies Inc. | Software pay per use system |
US5636280A (en) * | 1994-10-31 | 1997-06-03 | Kelly; Tadhg | Dual key reflexive encryption security system |
US5659616A (en) * | 1994-07-19 | 1997-08-19 | Certco, Llc | Method for securely using digital signatures in a commercial cryptographic system |
US5659626A (en) * | 1994-10-20 | 1997-08-19 | Calspan Corporation | Fingerprint identification system |
US5666420A (en) * | 1995-03-21 | 1997-09-09 | Micali; Silvio | Simultaneous electronic transactions |
US5671258A (en) * | 1994-12-20 | 1997-09-23 | 3Com Corporation | Clock recovery circuit and receiver using same |
US5671279A (en) * | 1995-11-13 | 1997-09-23 | Netscape Communications Corporation | Electronic commerce using a secure courier system |
US5671285A (en) * | 1995-12-13 | 1997-09-23 | Newman; Bruce D. | Secure communication system |
US5677953A (en) * | 1993-09-14 | 1997-10-14 | Spyrus, Inc. | System and method for access control for portable data storage media |
US5677955A (en) * | 1995-04-07 | 1997-10-14 | Financial Services Technology Consortium | Electronic funds transfer instruments |
US5687322A (en) * | 1989-05-01 | 1997-11-11 | Credit Verification Corporation | Method and system for selective incentive point-of-sale marketing in response to customer shopping histories |
US5692047A (en) * | 1995-12-08 | 1997-11-25 | Sun Microsystems, Inc. | System and method for executing verifiable programs with facility for using non-verifiable programs from trusted sources |
US5694471A (en) * | 1994-08-03 | 1997-12-02 | V-One Corporation | Counterfeit-proof identification card |
US5708780A (en) * | 1995-06-07 | 1998-01-13 | Open Market, Inc. | Internet server access control and monitoring systems |
US5715314A (en) * | 1994-10-24 | 1998-02-03 | Open Market, Inc. | Network sales system |
US5719950A (en) * | 1994-03-24 | 1998-02-17 | Minnesota Mining And Manufacturing Company | Biometric, personal authentication system |
US5721779A (en) * | 1995-08-28 | 1998-02-24 | Funk Software, Inc. | Apparatus and methods for verifying the identity of a party |
US5724424A (en) * | 1993-12-16 | 1998-03-03 | Open Market, Inc. | Digital active advertising |
US5745886A (en) * | 1995-06-07 | 1998-04-28 | Citibank, N.A. | Trusted agents for open distribution of electronic money |
US5751813A (en) * | 1996-04-29 | 1998-05-12 | Motorola, Inc. | Use of an encryption server for encrypting messages |
US5774525A (en) * | 1995-01-23 | 1998-06-30 | International Business Machines Corporation | Method and apparatus utilizing dynamic questioning to provide secure access control |
US5778072A (en) * | 1995-07-07 | 1998-07-07 | Sun Microsystems, Inc. | System and method to transparently integrate private key operations from a smart card with host-based encryption services |
US5781123A (en) * | 1994-10-14 | 1998-07-14 | Robert Bosch Gmbh | Operator control logging device for an electrical device |
US5781723A (en) * | 1996-06-03 | 1998-07-14 | Microsoft Corporation | System and method for self-identifying a portable information device to a computing unit |
US5790677A (en) * | 1995-06-29 | 1998-08-04 | Microsoft Corporation | System and method for secure electronic commerce transactions |
US5788953A (en) * | 1994-03-23 | 1998-08-04 | Hyd Kutato-Fejleszto Kft. | Hygienic and cosmetic preparations for preventing and treating skin-diseases as well as a process for obtaining same |
US5796857A (en) * | 1993-10-21 | 1998-08-18 | Nec Corporation | Apparatus for fingerprint verification using different verification method in accordance with quality grade data |
US5798640A (en) * | 1995-07-19 | 1998-08-25 | Vdo Adolf Schindling Ag | Passive magnetic position sensor |
US5809144A (en) * | 1995-08-24 | 1998-09-15 | Carnegie Mellon University | Method and apparatus for purchasing and delivering digital goods over a network |
US5812666A (en) * | 1995-03-31 | 1998-09-22 | Pitney Bowes Inc. | Cryptographic key management and validation system |
US5817123A (en) * | 1992-06-02 | 1998-10-06 | General Surgical Innovations, Inc. | Apparatus and method for developing an anatomic space for laparoscopic procedures with laparoscopic visualization |
US5825884A (en) * | 1996-07-01 | 1998-10-20 | Thomson Consumer Electronics | Method and apparatus for operating a transactional server in a proprietary database environment |
US5878172A (en) * | 1994-10-28 | 1999-03-02 | Oki Electric Industry Co., Ltd. | Image encoding and decoding method and apparatus using edge synthesis and inverse wavelet transform |
US5878143A (en) * | 1996-08-16 | 1999-03-02 | Net 1, Inc. | Secure transmission of sensitive information over a public/insecure communications medium |
US5928298A (en) * | 1996-02-23 | 1999-07-27 | Koyo Seiko Co., Ltd. | Electric power steering apparatus |
US6049874A (en) * | 1996-12-03 | 2000-04-11 | Fairbanks Systems Group | System and method for backing up computer files over a wide area computer network |
US6073237A (en) * | 1997-11-06 | 2000-06-06 | Cybercash, Inc. | Tamper resistant method and apparatus |
US6594759B1 (en) * | 1996-12-04 | 2003-07-15 | Esignx Corporation | Authorization firmware for conducting transactions with an electronic transaction system and methods therefor |
US6601171B1 (en) * | 1999-02-18 | 2003-07-29 | Novell, Inc. | Deputization in a distributed computing system |
US6615264B1 (en) * | 1999-04-09 | 2003-09-02 | Sun Microsystems, Inc. | Method and apparatus for remotely administered authentication and access control |
US6691232B1 (en) * | 1999-08-05 | 2004-02-10 | Sun Microsystems, Inc. | Security architecture with environment sensitive credential sufficiency evaluation |
US6751729B1 (en) * | 1998-07-24 | 2004-06-15 | Spatial Adventures, Inc. | Automated operation and security system for virtual private networks |
US6775772B1 (en) * | 1999-10-12 | 2004-08-10 | International Business Machines Corporation | Piggy-backed key exchange protocol for providing secure low-overhead browser connections from a client to a server using a trusted third party |
US6990588B1 (en) * | 1998-05-21 | 2006-01-24 | Yutaka Yasukura | Authentication card system |
US7130066B1 (en) * | 1998-09-04 | 2006-10-31 | Canon Kabushiki Kaisha | Apparatus for performing a service in cooperation with another apparatus on a network |
Family Cites Families (112)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US501196A (en) * | 1893-07-11 | Whip-hanger | ||
JPS5331209B2 (en) * | 1973-10-05 | 1978-09-01 | ||
JPS6256043A (en) * | 1985-09-04 | 1987-03-11 | Hitachi Ltd | Electronic transaction system |
FR2592502B1 (en) * | 1985-12-26 | 1990-03-30 | Lefevre Jean Pierre | SEQUENTIAL STORAGE CERTIFIER |
US4797920A (en) | 1987-05-01 | 1989-01-10 | Mastercard International, Inc. | Electronic funds transfer system with means for verifying a personal identification number without pre-established secret keys |
CA2011396C (en) | 1989-03-03 | 1995-01-03 | Kazue Tanaka | Cipher-key distribution system |
GB2237670B (en) * | 1989-11-03 | 1993-04-07 | De La Rue Syst | Reciprocal transfer system |
US5396558A (en) * | 1992-09-18 | 1995-03-07 | Nippon Telegraph And Telephone Corporation | Method and apparatus for settlement of accounts by IC cards |
US5675138A (en) | 1993-04-02 | 1997-10-07 | Psc, Inc. | Non-contact actuated trigger apparatus for bar code laser scanner |
CA2176032A1 (en) | 1994-01-13 | 1995-07-20 | Bankers Trust Company | Cryptographic system and method with key escrow feature |
US5787172A (en) | 1994-02-24 | 1998-07-28 | The Merdan Group, Inc. | Apparatus and method for establishing a cryptographic link between elements of a system |
US5799087A (en) | 1994-04-28 | 1998-08-25 | Citibank, N.A. | Electronic-monetary system |
GB9410337D0 (en) | 1994-05-24 | 1994-07-13 | Cryptech Systems Inc | Key transmission system |
US5546463A (en) * | 1994-07-12 | 1996-08-13 | Information Resource Engineering, Inc. | Pocket encrypting and authenticating communications device |
US5475886A (en) * | 1994-09-14 | 1995-12-19 | Klear-Vu Corporation | Combination pillow and chair cushion with tie string accomodating pocket |
JP3563783B2 (en) | 1994-10-19 | 2004-09-08 | キヤノン株式会社 | Composite image forming device |
US6044154A (en) * | 1994-10-31 | 2000-03-28 | Communications Devices, Inc. | Remote generated, device identifier key for use with a dual-key reflexive encryption security system |
US5555751A (en) * | 1994-10-31 | 1996-09-17 | Strickland; Frederick W. | Semiautomatic operated handcuffs with pivotal arcuate blades |
US6950810B2 (en) * | 1994-11-28 | 2005-09-27 | Indivos Corporation | Tokenless biometric electronic financial transactions via a third party identicator |
US5764789A (en) * | 1994-11-28 | 1998-06-09 | Smarttouch, Llc | Tokenless biometric ATM access system |
US5870723A (en) * | 1994-11-28 | 1999-02-09 | Pare, Jr.; David Ferrin | Tokenless biometric transaction authorization method and system |
WO1996024997A1 (en) * | 1995-02-08 | 1996-08-15 | Cryptomathic A/S | Electronic negotiable documents |
FR2733379B1 (en) | 1995-04-20 | 1997-06-20 | Gemplus Card Int | PROCESS FOR GENERATING ELECTRONIC SIGNATURES, ESPECIALLY FOR SMART CARDS |
US6000522A (en) | 1995-06-12 | 1999-12-14 | Alice A Johnson | Multi-compartment and acceptors computerized vending machine |
US5817723A (en) | 1995-09-07 | 1998-10-06 | E. I. Du Pont De Nemours And Company | Toughened thermoplastic polymer compositions |
US5999629A (en) | 1995-10-31 | 1999-12-07 | Lucent Technologies Inc. | Data encryption security module |
US6279112B1 (en) * | 1996-10-29 | 2001-08-21 | Open Market, Inc. | Controlled transfer of information in computer networks |
US5949881A (en) | 1995-12-04 | 1999-09-07 | Intel Corporation | Apparatus and method for cryptographic companion imprinting |
US5943423A (en) | 1995-12-15 | 1999-08-24 | Entegrity Solutions Corporation | Smart token system for secure electronic transactions and identification |
US5919574A (en) * | 1995-12-29 | 1999-07-06 | The United States Of America, As Represented By The Secretary Of Agriculture | Biodegradable laminated films fabricated from pectin and chitosan |
US5870475A (en) * | 1996-01-19 | 1999-02-09 | Northern Telecom Limited | Facilitating secure communications in a distribution network |
IL117085A (en) | 1996-02-08 | 2005-07-25 | Milsys Ltd | Secure computer system |
US6085320A (en) * | 1996-05-15 | 2000-07-04 | Rsa Security Inc. | Client/server protocol for proving authenticity |
US5848161A (en) | 1996-05-16 | 1998-12-08 | Luneau; Greg | Method for providing secured commerical transactions via a networked communications system |
US5677120A (en) * | 1996-05-23 | 1997-10-14 | Eastman Kodak Company | Tellurium complexes as chemical sensitizers for silver halides |
US5802592A (en) * | 1996-05-31 | 1998-09-01 | International Business Machines Corporation | System and method for protecting integrity of alterable ROM using digital signatures |
US5862327A (en) * | 1996-06-10 | 1999-01-19 | Tactica Corporation | Activity based long-lived transaction system |
US6253027B1 (en) * | 1996-06-17 | 2001-06-26 | Hewlett-Packard Company | System, method and article of manufacture for exchanging software and configuration data over a multichannel, extensible, flexible architecture |
US6373950B1 (en) * | 1996-06-17 | 2002-04-16 | Hewlett-Packard Company | System, method and article of manufacture for transmitting messages within messages utilizing an extensible, flexible architecture |
US6324525B1 (en) | 1996-06-17 | 2001-11-27 | Hewlett-Packard Company | Settlement of aggregated electronic transactions over a network |
US5884270A (en) | 1996-09-06 | 1999-03-16 | Walker Asset Management Limited Partnership | Method and system for facilitating an employment search incorporating user-controlled anonymous communications |
US5884272A (en) | 1996-09-06 | 1999-03-16 | Walker Asset Management Limited Partnership | Method and system for establishing and maintaining user-controlled anonymous communications |
US5982506A (en) * | 1996-09-10 | 1999-11-09 | E-Stamp Corporation | Method and system for electronic document certification |
US6023509A (en) * | 1996-09-30 | 2000-02-08 | Intel Corporation | Digital signature purpose encoding |
US5956404A (en) | 1996-09-30 | 1999-09-21 | Schneier; Bruce | Digital signature with auditing bits |
US6029150A (en) * | 1996-10-04 | 2000-02-22 | Certco, Llc | Payment and transactions in electronic commerce system |
FI113224B (en) * | 1996-11-11 | 2004-03-15 | Nokia Corp | Implementation of invoicing in a data communication system |
US6285991B1 (en) * | 1996-12-13 | 2001-09-04 | Visa International Service Association | Secure interactive electronic account statement delivery system |
US5903882A (en) | 1996-12-13 | 1999-05-11 | Certco, Llc | Reliance server for electronic transaction system |
US6021202A (en) * | 1996-12-20 | 2000-02-01 | Financial Services Technology Consortium | Method and system for processing electronic documents |
US5887131A (en) | 1996-12-31 | 1999-03-23 | Compaq Computer Corporation | Method for controlling access to a computer system by utilizing an external device containing a hash value representation of a user password |
CA2287379C (en) * | 1997-01-10 | 2005-10-04 | Silicon Gaming-Nevada | Method and apparatus for providing authenticated, secure on-line communication between remote locations |
US5991292A (en) | 1997-03-06 | 1999-11-23 | Nortel Networks Corporation | Network access in multi-service environment |
US6105012A (en) * | 1997-04-22 | 2000-08-15 | Sun Microsystems, Inc. | Security system and method for financial institution server and client web browser |
US6282522B1 (en) | 1997-04-30 | 2001-08-28 | Visa International Service Association | Internet payment system using smart card |
WO1998050875A2 (en) * | 1997-05-09 | 1998-11-12 | Gte Government Systems Corporation | Biometric certificates |
US6202151B1 (en) | 1997-05-09 | 2001-03-13 | Gte Service Corporation | System and method for authenticating electronic transactions using biometric certificates |
JPH10327147A (en) * | 1997-05-21 | 1998-12-08 | Hitachi Ltd | Electronic authenticating and notarizing method and its system |
US6085976A (en) * | 1998-05-22 | 2000-07-11 | Sehr; Richard P. | Travel system and methods utilizing multi-application passenger cards |
FI104667B (en) * | 1997-07-14 | 2000-04-14 | Nokia Networks Oy | Implementation of access service |
US5910988A (en) | 1997-08-27 | 1999-06-08 | Csp Holdings, Inc. | Remote image capture with centralized processing and storage |
US6161180A (en) | 1997-08-29 | 2000-12-12 | International Business Machines Corporation | Authentication for secure devices with limited cryptography |
US6213391B1 (en) * | 1997-09-10 | 2001-04-10 | William H. Lewis | Portable system for personal identification based upon distinctive characteristics of the user |
US6000832A (en) * | 1997-09-24 | 1999-12-14 | Microsoft Corporation | Electronic online commerce card with customer generated transaction proxy number for online transactions |
US5883810A (en) | 1997-09-24 | 1999-03-16 | Microsoft Corporation | Electronic online commerce card with transactionproxy number for online transactions |
US6061794A (en) * | 1997-09-30 | 2000-05-09 | Compaq Computer Corp. | System and method for performing secure device communications in a peer-to-peer bus architecture |
US5970147A (en) * | 1997-09-30 | 1999-10-19 | Intel Corporation | System and method for configuring and registering a cryptographic device |
US6125349A (en) * | 1997-10-01 | 2000-09-26 | At&T Corp. | Method and apparatus using digital credentials and other electronic certificates for electronic transactions |
US6111956A (en) | 1997-10-23 | 2000-08-29 | Signals, Inc. | Method for secure key distribution over a nonsecure communications network |
US6061799A (en) * | 1997-10-31 | 2000-05-09 | International Business Machines Corp. | Removable media for password based authentication in a distributed system |
US6292897B1 (en) * | 1997-11-03 | 2001-09-18 | International Business Machines Corporation | Undeniable certificates for digital signature verification |
US6385728B1 (en) * | 1997-11-26 | 2002-05-07 | International Business Machines Corporation | System, method, and program for providing will-call certificates for guaranteeing authorization for a printer to retrieve a file directly from a file server upon request from a client in a network computer system environment |
WO1999028452A1 (en) | 1997-11-28 | 1999-06-10 | Mochida Pharmaceutical Co., Ltd. | Matrilysin antisense compounds |
US5991399A (en) * | 1997-12-18 | 1999-11-23 | Intel Corporation | Method for securely distributing a conditional use private key to a trusted entity on a remote system |
US6314519B1 (en) * | 1997-12-22 | 2001-11-06 | Motorola, Inc. | Secure messaging system overlay for a selective call signaling system |
US6084969A (en) * | 1997-12-31 | 2000-07-04 | V-One Corporation | Key encryption system and method, pager unit, and pager proxy for a two-way alphanumeric pager network |
JP2002509313A (en) * | 1998-01-16 | 2002-03-26 | メディアドナ、インコーポレイテッド | System and method for authenticating a peer component |
US6192405B1 (en) | 1998-01-23 | 2001-02-20 | Novell, Inc. | Method and apparatus for acquiring authorized access to resources in a distributed system |
US6144949A (en) | 1998-02-12 | 2000-11-07 | Motorola, Inc. | Radio frequency communication system with subscribers arranged to authenticate a received message |
US6233565B1 (en) * | 1998-02-13 | 2001-05-15 | Saranac Software, Inc. | Methods and apparatus for internet based financial transactions with evidence of payment |
US6233577B1 (en) * | 1998-02-17 | 2001-05-15 | Phone.Com, Inc. | Centralized certificate management system for two-way interactive communication devices in data networks |
US6108644A (en) * | 1998-02-19 | 2000-08-22 | At&T Corp. | System and method for electronic transactions |
US6230269B1 (en) * | 1998-03-04 | 2001-05-08 | Microsoft Corporation | Distributed authentication system and method |
US6161181A (en) | 1998-03-06 | 2000-12-12 | Deloitte & Touche Usa Llp | Secure electronic transactions using a trusted intermediary |
US6199052B1 (en) * | 1998-03-06 | 2001-03-06 | Deloitte & Touche Usa Llp | Secure electronic transactions using a trusted intermediary with archive and verification request services |
US6073242A (en) * | 1998-03-19 | 2000-06-06 | Agorics, Inc. | Electronic authority server |
US6532451B1 (en) * | 1998-03-23 | 2003-03-11 | Novell, Inc. | Nested strong loader apparatus and method |
US6484260B1 (en) | 1998-04-24 | 2002-11-19 | Identix, Inc. | Personal identification system |
GB2353623B (en) * | 1998-05-05 | 2003-01-08 | Jay Chieh Chen | Systems for electronic transactions |
US6189096B1 (en) | 1998-05-06 | 2001-02-13 | Kyberpass Corporation | User authentification using a virtual private key |
US6655585B2 (en) * | 1998-05-11 | 2003-12-02 | Citicorp Development Center, Inc. | System and method of biometric smart card user authentication |
US6102287A (en) * | 1998-05-15 | 2000-08-15 | International Business Machines Corporation | Method and apparatus for providing product survey information in an electronic payment system |
US6263447B1 (en) * | 1998-05-21 | 2001-07-17 | Equifax Inc. | System and method for authentication of network users |
US6092202A (en) * | 1998-05-22 | 2000-07-18 | N*Able Technologies, Inc. | Method and system for secure transactions in a computer system |
US6317829B1 (en) | 1998-06-19 | 2001-11-13 | Entrust Technologies Limited | Public key cryptography based security system to facilitate secure roaming of users |
US6167518A (en) | 1998-07-28 | 2000-12-26 | Commercial Electronics, Llc | Digital signature providing non-repudiation based on biological indicia |
US6226618B1 (en) * | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
KR100358426B1 (en) | 1998-08-18 | 2003-01-29 | 한국전자통신연구원 | Electronic Cash Transaction Method |
WO2000028452A1 (en) * | 1998-11-05 | 2000-05-18 | Secure Accounts Ltd. | Secure architecture for exchange executes digitally signed contracts |
EP1129436A1 (en) * | 1998-11-10 | 2001-09-05 | Kent Ridge Digital Labs | A method of encryption and apparatus therefor |
US6154543A (en) | 1998-11-25 | 2000-11-28 | Hush Communications Anguilla, Inc. | Public key cryptosystem with roaming user capability |
US6070154A (en) * | 1998-11-27 | 2000-05-30 | Activepoint Ltd. | Internet credit card security |
US6567913B1 (en) * | 1998-12-24 | 2003-05-20 | Pitney Bowes Inc. | Selective security level certificate meter |
US6571339B1 (en) * | 1998-12-30 | 2003-05-27 | Intel Corporation | Use of a processor identification for authentication |
US6418472B1 (en) * | 1999-01-19 | 2002-07-09 | Intel Corporation | System and method for using internet based caller ID for controlling access to an object stored in a computer |
US6671805B1 (en) * | 1999-06-17 | 2003-12-30 | Ilumin Corporation | System and method for document-driven processing of digitally-signed electronic documents |
AU761974B2 (en) * | 1999-04-28 | 2003-06-12 | Unicate B.V. | Transaction method and system for data networks, like internet |
CA2271178A1 (en) | 1999-05-06 | 1999-07-06 | Connotech Experts-Conseils Inc. | Server-side public key cryptography apparatus with private key protection and isolation from public networks |
US6594633B1 (en) * | 1999-07-07 | 2003-07-15 | Vincent S. Broerman | Real estate computer network |
US6609198B1 (en) | 1999-08-05 | 2003-08-19 | Sun Microsystems, Inc. | Log-on service providing credential level change without loss of session continuity |
US6757832B1 (en) * | 2000-02-15 | 2004-06-29 | Silverbrook Research Pty Ltd | Unauthorized modification of values in flash memory |
CA2354372A1 (en) * | 2001-02-23 | 2002-08-23 | Efunds Corporation | Electronic payment and authentication system with debit and identification data verification and electronic check capabilities |
-
2001
- 2001-08-06 JP JP2002518678A patent/JP2004506245A/en not_active Withdrawn
- 2001-08-06 CA CA2418050A patent/CA2418050C/en not_active Expired - Lifetime
- 2001-08-06 US US09/923,075 patent/US20020016913A1/en not_active Abandoned
- 2001-08-06 AU AU2001287164A patent/AU2001287164B2/en not_active Ceased
- 2001-08-06 CA CA2417901A patent/CA2417901C/en not_active Expired - Lifetime
- 2001-08-06 WO PCT/US2001/024572 patent/WO2002013445A2/en active Application Filing
- 2001-08-06 WO PCT/US2001/024563 patent/WO2002013444A2/en active Application Filing
- 2001-08-06 EP EP01965856A patent/EP1317816A4/en not_active Ceased
- 2001-08-06 AU AU2001287165A patent/AU2001287165A1/en not_active Abandoned
- 2001-08-06 CA CA2417922A patent/CA2417922C/en not_active Expired - Lifetime
- 2001-08-06 CA CA2417770A patent/CA2417770C/en not_active Expired - Lifetime
- 2001-08-06 US US09/923,213 patent/US7500272B2/en not_active Expired - Fee Related
- 2001-08-06 AU AU2001278205A patent/AU2001278205A1/en not_active Abandoned
- 2001-08-06 WO PCT/US2001/041587 patent/WO2002013455A1/en active Application Filing
- 2001-08-06 US US10/312,164 patent/US7200749B2/en not_active Expired - Lifetime
- 2001-08-06 CA CA2417919A patent/CA2417919C/en not_active Expired - Lifetime
- 2001-08-06 JP JP2002518685A patent/JP2004506380A/en not_active Withdrawn
- 2001-08-06 EP EP01966672A patent/EP1316171A4/en not_active Ceased
- 2001-08-06 JP JP2002518667A patent/JP2004515840A/en not_active Withdrawn
- 2001-08-06 AU AU2001283128A patent/AU2001283128A1/en not_active Abandoned
- 2001-08-06 CA CA002417916A patent/CA2417916A1/en not_active Abandoned
- 2001-08-06 EP EP01966671A patent/EP1316168A4/en not_active Ceased
- 2001-08-06 AU AU2001284721A patent/AU2001284721A1/en not_active Abandoned
- 2001-08-06 WO PCT/US2001/024567 patent/WO2002013434A1/en active Application Filing
- 2001-08-06 AU AU8716401A patent/AU8716401A/en active Pending
- 2001-08-06 EP EP01963801A patent/EP1320953A4/en not_active Withdrawn
- 2001-08-06 JP JP2002518677A patent/JP2004519874A/en not_active Withdrawn
- 2001-08-06 EP EP01961902A patent/EP1320956A4/en not_active Ceased
- 2001-08-06 AU AU2001286415A patent/AU2001286415A1/en not_active Abandoned
- 2001-08-06 JP JP2002518668A patent/JP2004517381A/en not_active Withdrawn
- 2001-08-06 WO PCT/US2001/041586 patent/WO2002013435A1/en active Search and Examination
- 2001-08-06 JP JP2002518399A patent/JP2004506361A/en not_active Withdrawn
- 2001-08-06 WO PCT/US2001/041562 patent/WO2002013116A1/en active Application Filing
- 2001-08-06 EP EP01956178A patent/EP1323089A4/en not_active Ceased
-
2003
- 2003-01-31 US US10/248,604 patent/US7143284B2/en not_active Expired - Lifetime
- 2003-01-31 US US10/248,605 patent/US6938156B2/en not_active Expired - Lifetime
- 2003-01-31 US US10/248,603 patent/US6851054B2/en not_active Expired - Lifetime
- 2003-01-31 US US10/248,606 patent/US6950940B2/en not_active Expired - Lifetime
- 2003-02-01 US US10/248,627 patent/US6892302B2/en not_active Expired - Lifetime
- 2003-02-01 US US10/248,625 patent/US6915430B2/en not_active Expired - Lifetime
- 2003-02-01 US US10/248,624 patent/US7028185B2/en not_active Expired - Lifetime
- 2003-02-01 US US10/248,629 patent/US6959381B2/en not_active Expired - Lifetime
- 2003-02-01 US US10/248,628 patent/US6957336B2/en not_active Expired - Lifetime
- 2003-02-01 US US10/248,626 patent/US7047414B2/en not_active Expired - Lifetime
- 2003-02-01 US US10/248,620 patent/US6952773B2/en not_active Expired - Lifetime
-
2008
- 2008-08-05 AU AU2008203506A patent/AU2008203506B2/en not_active Ceased
-
2009
- 2009-01-16 US US12/355,712 patent/US7784106B2/en not_active Expired - Fee Related
Patent Citations (99)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3962539A (en) * | 1975-02-24 | 1976-06-08 | International Business Machines Corporation | Product block cipher system for data security |
US4200770A (en) * | 1977-09-06 | 1980-04-29 | Stanford University | Cryptographic apparatus and method |
US4218582A (en) * | 1977-10-06 | 1980-08-19 | The Board Of Trustees Of The Leland Stanford Junior University | Public key cryptographic apparatus and method |
US4405829A (en) * | 1977-12-14 | 1983-09-20 | Massachusetts Institute Of Technology | Cryptographic communications system and method |
US4408203A (en) * | 1978-01-09 | 1983-10-04 | Mastercard International, Inc. | Security system for electronic funds transfer system |
US4424414A (en) * | 1978-05-01 | 1984-01-03 | Board Of Trustees Of The Leland Stanford Junior University | Exponentiation cryptographic apparatus and method |
US4825050A (en) * | 1983-09-13 | 1989-04-25 | Transaction Security Corporation | Security transaction system for financial data |
US4944021A (en) * | 1984-04-18 | 1990-07-24 | Nec Corporation | Identification system employing verification of fingerprints |
US4823388A (en) * | 1984-06-25 | 1989-04-18 | Kabushiki Kaisha Toshiba | Communications network using an enciphering and deciphering device |
US4928298A (en) * | 1984-08-07 | 1990-05-22 | Nix Company, Ltd. | Information-bearing sheet for X-ray film |
US4652698A (en) * | 1984-08-13 | 1987-03-24 | Ncr Corporation | Method and system for providing system security in a remote terminal environment |
US4734564A (en) * | 1985-05-02 | 1988-03-29 | Visa International Service Association | Transaction system with off-line risk assessment |
US5018196A (en) * | 1985-09-04 | 1991-05-21 | Hitachi, Ltd. | Method for electronic transaction with digital signature |
US4798668A (en) * | 1986-01-31 | 1989-01-17 | Union Oil Company Of California | Extraction of hydrocarbon-containing solids |
US4885788A (en) * | 1986-02-17 | 1989-12-05 | Hitachi, Ltd. | IC card |
US5097504A (en) * | 1986-03-19 | 1992-03-17 | Infoscript | Method and device for qualitative saving of digitized data |
US4856077A (en) * | 1986-04-28 | 1989-08-08 | Eric Rothfjell | Method of signature verification and device for carrying out the method |
US4995086A (en) * | 1986-05-06 | 1991-02-19 | Siemens Aktiengesellschaft | Arrangement and procedure for determining the authorization of individuals by verifying their fingerprints |
US4748668A (en) * | 1986-07-09 | 1988-05-31 | Yeda Research And Development Company Limited | Method, apparatus and article for identification and signature |
US4850017A (en) * | 1987-05-29 | 1989-07-18 | International Business Machines Corp. | Controlled use of cryptographic keys via generating station established control values |
US4897920A (en) * | 1987-06-19 | 1990-02-06 | Dunbar Donald W | Sheath cutting tool |
US5140634A (en) * | 1987-09-07 | 1992-08-18 | U.S Philips Corporation | Method and apparatus for authenticating accreditations and for authenticating and signing messages |
US4868877A (en) * | 1988-02-12 | 1989-09-19 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
US4879747A (en) * | 1988-03-21 | 1989-11-07 | Leighton Frank T | Method and system for personal identification |
US5025373A (en) * | 1988-06-30 | 1991-06-18 | Jml Communications, Inc. | Portable personal-banking system |
US5225978A (en) * | 1989-01-25 | 1993-07-06 | Usisys Corp. | Document processing system having integrated expert module |
US5687322A (en) * | 1989-05-01 | 1997-11-11 | Credit Verification Corporation | Method and system for selective incentive point-of-sale marketing in response to customer shopping histories |
US5455865A (en) * | 1989-05-09 | 1995-10-03 | Digital Equipment Corporation | Robust packet routing over a distributed network containing malicious failures |
US5209208A (en) * | 1989-08-08 | 1993-05-11 | Robert Bosch Gmbh | Fuel injection pump for diesel internal combustion engines |
US5001752A (en) * | 1989-10-13 | 1991-03-19 | Fischer Addison M | Public/key date-time notary facility |
US5214703A (en) * | 1990-05-18 | 1993-05-25 | Ascom Tech Ag | Device for the conversion of a digital block and use of same |
US5231668A (en) * | 1991-07-26 | 1993-07-27 | The United States Of America, As Represented By The Secretary Of Commerce | Digital signature algorithm |
US5473143A (en) * | 1991-09-23 | 1995-12-05 | Atm Communications International, Inc. | ATM/POS based electronic mail system |
US5453601A (en) * | 1991-11-15 | 1995-09-26 | Citibank, N.A. | Electronic-monetary system |
US5280527A (en) * | 1992-04-14 | 1994-01-18 | Kamahira Safe Co., Inc. | Biometric token for authorizing access to a host system |
US5502766A (en) * | 1992-04-17 | 1996-03-26 | Secure Computing Corporation | Data enclave and trusted path system |
US5817123A (en) * | 1992-06-02 | 1998-10-06 | General Surgical Innovations, Inc. | Apparatus and method for developing an anatomic space for laparoscopic procedures with laparoscopic visualization |
US5534855A (en) * | 1992-07-20 | 1996-07-09 | Digital Equipment Corporation | Method and system for certificate based alias detection |
US5412703A (en) * | 1993-02-04 | 1995-05-02 | Institute For Radiological Image Science, Inc. | Reduced partial volume artifacts in image reconstruction, with application to X-ray computed tomography |
US5422953A (en) * | 1993-05-05 | 1995-06-06 | Fischer; Addison M. | Personal date/time notary device |
US5677953A (en) * | 1993-09-14 | 1997-10-14 | Spyrus, Inc. | System and method for access control for portable data storage media |
US5796857A (en) * | 1993-10-21 | 1998-08-18 | Nec Corporation | Apparatus for fingerprint verification using different verification method in accordance with quality grade data |
US5625690A (en) * | 1993-11-15 | 1997-04-29 | Lucent Technologies Inc. | Software pay per use system |
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 |
US5724424A (en) * | 1993-12-16 | 1998-03-03 | Open Market, Inc. | Digital active advertising |
US5788953A (en) * | 1994-03-23 | 1998-08-04 | Hyd Kutato-Fejleszto Kft. | Hygienic and cosmetic preparations for preventing and treating skin-diseases as well as a process for obtaining same |
US5719950A (en) * | 1994-03-24 | 1998-02-17 | Minnesota Mining And Manufacturing Company | Biometric, personal authentication system |
US5598474A (en) * | 1994-03-29 | 1997-01-28 | Neldon P Johnson | Process for encrypting a fingerprint onto an I.D. card |
US5509071A (en) * | 1994-04-01 | 1996-04-16 | Microelectronics And Computer Technology Corporation | Electronic proof of receipt |
US5563946A (en) * | 1994-04-25 | 1996-10-08 | International Business Machines Corporation | Method and apparatus for enabling trial period use of software products: method and apparatus for passing encrypted files between data processing systems |
US5557518A (en) * | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
US5539828A (en) * | 1994-05-31 | 1996-07-23 | Intel Corporation | Apparatus and method for providing secured communications |
US5586036A (en) * | 1994-07-05 | 1996-12-17 | Pitney Bowes Inc. | Postage payment system with security for sensitive mailer data and enhanced carrier data functionality |
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 |
US5568552A (en) * | 1994-09-07 | 1996-10-22 | Intel Corporation | Method for providing a roving software license from one node to another node |
US5606609A (en) * | 1994-09-19 | 1997-02-25 | Scientific-Atlanta | Electronic document verification system and method |
US5781123A (en) * | 1994-10-14 | 1998-07-14 | Robert Bosch Gmbh | Operator control logging device for an electrical device |
US5659626A (en) * | 1994-10-20 | 1997-08-19 | Calspan Corporation | Fingerprint identification system |
US5715314A (en) * | 1994-10-24 | 1998-02-03 | Open Market, Inc. | Network sales system |
US5878172A (en) * | 1994-10-28 | 1999-03-02 | Oki Electric Industry Co., Ltd. | Image encoding and decoding method and apparatus using edge synthesis and inverse wavelet transform |
US5636280A (en) * | 1994-10-31 | 1997-06-03 | Kelly; Tadhg | Dual key reflexive encryption security system |
US5671258A (en) * | 1994-12-20 | 1997-09-23 | 3Com Corporation | Clock recovery circuit and receiver using same |
US5615268A (en) * | 1995-01-17 | 1997-03-25 | Document Authentication Systems, Inc. | System and method for electronic transmission storage and retrieval of authenticated documents |
US5774525A (en) * | 1995-01-23 | 1998-06-30 | International Business Machines Corporation | Method and apparatus utilizing dynamic questioning to provide secure access control |
US5619177A (en) * | 1995-01-27 | 1997-04-08 | Mjb Company | Shape memory alloy microactuator having an electrostatic force and heating means |
US5604801A (en) * | 1995-02-03 | 1997-02-18 | International Business Machines Corporation | Public key data communications system under control of a portable security device |
US5619574A (en) * | 1995-02-13 | 1997-04-08 | Eta Technologies Corporation | Personal access management system |
US5666420A (en) * | 1995-03-21 | 1997-09-09 | Micali; Silvio | Simultaneous electronic transactions |
US5812666A (en) * | 1995-03-31 | 1998-09-22 | Pitney Bowes Inc. | Cryptographic key management and validation system |
US5590197A (en) * | 1995-04-04 | 1996-12-31 | V-One Corporation | Electronic payment system and method |
US5677955A (en) * | 1995-04-07 | 1997-10-14 | Financial Services Technology Consortium | Electronic funds transfer instruments |
US5577120A (en) * | 1995-05-01 | 1996-11-19 | Lucent Technologies Inc. | Method and apparatus for restrospectively identifying an individual who had engaged in a commercial or retail transaction or the like |
US5745886A (en) * | 1995-06-07 | 1998-04-28 | Citibank, N.A. | Trusted agents for open distribution of electronic money |
US5708780A (en) * | 1995-06-07 | 1998-01-13 | Open Market, Inc. | Internet server access control and monitoring systems |
US5790677A (en) * | 1995-06-29 | 1998-08-04 | Microsoft Corporation | System and method for secure electronic commerce transactions |
US5778072A (en) * | 1995-07-07 | 1998-07-07 | Sun Microsystems, Inc. | System and method to transparently integrate private key operations from a smart card with host-based encryption services |
US5615266A (en) * | 1995-07-13 | 1997-03-25 | Motorola, Inc | Secure communication setup method |
US5798640A (en) * | 1995-07-19 | 1998-08-25 | Vdo Adolf Schindling Ag | Passive magnetic position sensor |
US5809144A (en) * | 1995-08-24 | 1998-09-15 | Carnegie Mellon University | Method and apparatus for purchasing and delivering digital goods over a network |
US5721779A (en) * | 1995-08-28 | 1998-02-24 | Funk Software, Inc. | Apparatus and methods for verifying the identity of a party |
US5671279A (en) * | 1995-11-13 | 1997-09-23 | Netscape Communications Corporation | Electronic commerce using a secure courier system |
US5692047A (en) * | 1995-12-08 | 1997-11-25 | Sun Microsystems, Inc. | System and method for executing verifiable programs with facility for using non-verifiable programs from trusted sources |
US5671285A (en) * | 1995-12-13 | 1997-09-23 | Newman; Bruce D. | Secure communication system |
US5928298A (en) * | 1996-02-23 | 1999-07-27 | Koyo Seiko Co., Ltd. | Electric power steering apparatus |
US5751813A (en) * | 1996-04-29 | 1998-05-12 | Motorola, Inc. | Use of an encryption server for encrypting messages |
US5781723A (en) * | 1996-06-03 | 1998-07-14 | Microsoft Corporation | System and method for self-identifying a portable information device to a computing unit |
US5825884A (en) * | 1996-07-01 | 1998-10-20 | Thomson Consumer Electronics | Method and apparatus for operating a transactional server in a proprietary database environment |
US5878143A (en) * | 1996-08-16 | 1999-03-02 | Net 1, Inc. | Secure transmission of sensitive information over a public/insecure communications medium |
US6049874A (en) * | 1996-12-03 | 2000-04-11 | Fairbanks Systems Group | System and method for backing up computer files over a wide area computer network |
US6594759B1 (en) * | 1996-12-04 | 2003-07-15 | Esignx Corporation | Authorization firmware for conducting transactions with an electronic transaction system and methods therefor |
US6073237A (en) * | 1997-11-06 | 2000-06-06 | Cybercash, Inc. | Tamper resistant method and apparatus |
US6990588B1 (en) * | 1998-05-21 | 2006-01-24 | Yutaka Yasukura | Authentication card system |
US6751729B1 (en) * | 1998-07-24 | 2004-06-15 | Spatial Adventures, Inc. | Automated operation and security system for virtual private networks |
US7130066B1 (en) * | 1998-09-04 | 2006-10-31 | Canon Kabushiki Kaisha | Apparatus for performing a service in cooperation with another apparatus on a network |
US6601171B1 (en) * | 1999-02-18 | 2003-07-29 | Novell, Inc. | Deputization in a distributed computing system |
US6615264B1 (en) * | 1999-04-09 | 2003-09-02 | Sun Microsystems, Inc. | Method and apparatus for remotely administered authentication and access control |
US6691232B1 (en) * | 1999-08-05 | 2004-02-10 | Sun Microsystems, Inc. | Security architecture with environment sensitive credential sufficiency evaluation |
US6775772B1 (en) * | 1999-10-12 | 2004-08-10 | International Business Machines Corporation | Piggy-backed key exchange protocol for providing secure low-overhead browser connections from a client to a server using a trusted third party |
Cited By (180)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8904180B2 (en) | 2001-03-09 | 2014-12-02 | Ca, Inc. | Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys |
WO2002073861A2 (en) * | 2001-03-09 | 2002-09-19 | Arcot Systems, Inc. | Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys |
US7711122B2 (en) | 2001-03-09 | 2010-05-04 | Arcot Systems, Inc. | Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys |
US20100172504A1 (en) * | 2001-03-09 | 2010-07-08 | Arcot Systems, Inc. | Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys |
US20020126850A1 (en) * | 2001-03-09 | 2002-09-12 | Arcot Systems, Inc. | Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys |
US8290165B2 (en) | 2001-03-09 | 2012-10-16 | Ca, Inc. | Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys |
WO2002073861A3 (en) * | 2001-03-09 | 2003-10-30 | Arcot Systems Inc | Method and apparatus for cryptographic key storage wherein key servers are authenticated by possession and secure distribution of stored keys |
US20030051150A1 (en) * | 2001-09-10 | 2003-03-13 | Jung Jin Ho | Method for encrypting multimedia data |
US7769695B2 (en) | 2001-09-21 | 2010-08-03 | Yt Acquisition Corporation | System and method for purchase benefits at a point of sale |
US7778933B2 (en) * | 2001-09-21 | 2010-08-17 | Yt Acquisition Corporation | System and method for categorizing transactions |
US20090006239A1 (en) * | 2001-09-21 | 2009-01-01 | Yt Acquisition Corporation | System and method for categorizing transactions |
US20050125658A1 (en) * | 2001-10-23 | 2005-06-09 | Yoshihiro Tsukamoto | Information processing apparatus |
US20040083394A1 (en) * | 2002-02-22 | 2004-04-29 | Gavin Brebner | Dynamic user authentication |
US10521624B2 (en) | 2002-05-29 | 2019-12-31 | Sony Corporation | Object device including an IC chip |
US8601277B2 (en) * | 2002-05-29 | 2013-12-03 | Sony Corporation | Information processing system |
US9858456B2 (en) | 2002-05-29 | 2018-01-02 | Sony Corporation | Information processing system |
US20060080539A1 (en) * | 2002-05-29 | 2006-04-13 | Akiko Asami | Information processing system |
US8909935B2 (en) | 2002-05-29 | 2014-12-09 | Sony Corporation | Information processing system |
US20060156027A1 (en) * | 2002-07-24 | 2006-07-13 | Blake Christopher I | Method of secure transmission |
EP1547002A4 (en) * | 2002-07-24 | 2007-08-22 | Bqt Solutions Australia Pty Lt | A method of secure transmission |
EP1547002A1 (en) * | 2002-07-24 | 2005-06-29 | BQT Solutions Pty Ltd | A method of secure transmission |
US20080290161A1 (en) * | 2002-07-24 | 2008-11-27 | Bqt Solutions (Australia) Pty Ltd | Method of secure transmission |
US8190529B2 (en) * | 2002-07-30 | 2012-05-29 | Sony Mobile Communications Japan, Inc. | Information processing system, information communication terminal and method, information processing apparatus and method, recording medium, and program for internet transaction |
US20050086171A1 (en) * | 2002-07-30 | 2005-04-21 | Makoto Abe | Information processing system, information communication terminal and method, information processing device and method, recording medium, and program |
US7437330B1 (en) * | 2002-09-20 | 2008-10-14 | Yt Acquisition Corp. | System and method for categorizing transactions |
US20040129776A1 (en) * | 2002-09-26 | 2004-07-08 | Samsung Electronics Co., Ltd. | Security monitor apparatus and method using smart card |
US7392941B2 (en) * | 2002-09-26 | 2008-07-01 | Samsung Electronics Co., Ltd. | Security monitor apparatus and method using smart card |
EP1573689B1 (en) * | 2002-10-24 | 2018-05-23 | Giesecke+Devrient Mobile Security GmbH | Method for carrying out a secure electronic transaction using a portable data support |
US20060242691A1 (en) * | 2002-10-24 | 2006-10-26 | Gisela Meister | Method for carrying out a secure electronic transaction using a portable data support |
US20040083366A1 (en) * | 2002-10-24 | 2004-04-29 | Nachenberg Carey S. | Securing executable content using a trusted computing platform |
US7694139B2 (en) * | 2002-10-24 | 2010-04-06 | Symantec Corporation | Securing executable content using a trusted computing platform |
US8205249B2 (en) * | 2002-10-24 | 2012-06-19 | Giesecke & Devrient Gmbh | Method for carrying out a secure electronic transaction using a portable data support |
US7892087B1 (en) * | 2002-12-02 | 2011-02-22 | Sca Promotions, Inc. | Authentication of game results |
US20110130190A1 (en) * | 2002-12-02 | 2011-06-02 | Hamman Robert D | Authentication of Game Results |
US8052048B1 (en) | 2002-12-26 | 2011-11-08 | Diebold Self-Service Systems Division Of Diebold, Incorporated | Automated banking machine that operates responsive to data bearing records |
US8100323B1 (en) | 2002-12-26 | 2012-01-24 | Diebold Self-Service Systems Division Of Diebold, Incorporated | Apparatus and method for verifying components of an ATM |
US7565545B2 (en) * | 2003-02-19 | 2009-07-21 | International Business Machines Corporation | Method, system and program product for auditing electronic transactions based on biometric readings |
US20040162987A1 (en) * | 2003-02-19 | 2004-08-19 | International Business Machines Corporation | Method, system and program product for auditing electronic transactions based on biometric readings |
US7492899B2 (en) * | 2003-08-05 | 2009-02-17 | Zte Corporation | Authentication method for media gateway |
US20060236101A1 (en) * | 2003-08-05 | 2006-10-19 | Kezhi Qiao | Authentication method for medic gateway |
US20050039016A1 (en) * | 2003-08-12 | 2005-02-17 | Selim Aissi | Method for using trusted, hardware-based identity credentials in runtime package signature to secure mobile communications and high-value transaction execution |
US20080288029A1 (en) * | 2004-03-15 | 2008-11-20 | Healy Scott J | System And Method For Securely Exchanging Sensitive Information With An Implantable Medical Device |
US20050204134A1 (en) * | 2004-03-15 | 2005-09-15 | Von Arx Jeffrey A. | System and method for securely authenticating a data exchange session with an implantable medical device |
US8331563B2 (en) | 2004-03-15 | 2012-12-11 | Cardiac Pacemakers, Inc. | System and method for providing secure communication of sensitive information |
US7831828B2 (en) * | 2004-03-15 | 2010-11-09 | Cardiac Pacemakers, Inc. | System and method for securely authenticating a data exchange session with an implantable medical device |
US20090043362A1 (en) * | 2004-03-15 | 2009-02-12 | Healy Scott J | System and method for providing secure communication of sensitive information |
US7475245B1 (en) | 2004-03-15 | 2009-01-06 | Cardiac Pacemakers, Inc. | System and method for providing secure exchange of sensitive information with an implantable medical device |
US8327139B2 (en) | 2004-03-15 | 2012-12-04 | Cardiac Pacemakers, Inc. | System and method for securely exchanging sensitive information with an implantable medical device |
US20070226513A1 (en) * | 2004-05-06 | 2007-09-27 | Fukio Handa | Ic Card for Encryption or Decryption Process and Encrypted Communication System and Encrypted Communication Method Using the Same |
US20110213973A1 (en) * | 2004-05-06 | 2011-09-01 | Dai Nippon Printing Co., Ltd. | Ic card for encryption or decryption process and encrypted communication system and encrypted communication method using the same |
US8595813B2 (en) | 2004-05-06 | 2013-11-26 | Dai Nippon Printing Co., Ltd. | IC card for encryption or decryption process and encrypted communication system and encrypted communication method using the same |
US20070049265A1 (en) * | 2005-08-30 | 2007-03-01 | Kaimal Biju R | Apparatus and method for local device management |
US20070046424A1 (en) * | 2005-08-31 | 2007-03-01 | Davis Michael L | Device authentication using a unidirectional protocol |
US8183980B2 (en) | 2005-08-31 | 2012-05-22 | Assa Abloy Ab | Device authentication using a unidirectional protocol |
WO2007048839A1 (en) * | 2005-10-28 | 2007-05-03 | Gemplus | Method for securing payments by cutting out amounts |
FR2892875A1 (en) * | 2005-10-28 | 2007-05-04 | Gemplus Sa | METHOD OF SECURING PAYMENTS BY CUTTING AMOUNTS |
US8281386B2 (en) * | 2005-12-21 | 2012-10-02 | Panasonic Corporation | Systems and methods for automatic secret generation and distribution for secure systems |
US20070143838A1 (en) * | 2005-12-21 | 2007-06-21 | Thomas Milligan | Systems and methods for automatic secret generation and distribution for secure systems |
US20070237366A1 (en) * | 2006-03-24 | 2007-10-11 | Atmel Corporation | Secure biometric processing system and method of use |
US20070226787A1 (en) * | 2006-03-24 | 2007-09-27 | Atmel Corporation | Method and system for secure external TPM password generation and use |
US7849312B2 (en) | 2006-03-24 | 2010-12-07 | Atmel Corporation | Method and system for secure external TPM password generation and use |
US8261072B2 (en) | 2006-03-24 | 2012-09-04 | Atmel Corporation | Method and system for secure external TPM password generation and use |
US20070226496A1 (en) * | 2006-03-24 | 2007-09-27 | Atmel Corporation | Method and system for secure external TPM password generation and use |
US20110047036A1 (en) * | 2006-06-08 | 2011-02-24 | Master Card International Incorporated | All-in-one proximity payment device with local authentication |
US9401063B2 (en) * | 2006-06-08 | 2016-07-26 | Mastercard International Incorporated | All-in-one proximity payment device with local authentication |
WO2007143740A2 (en) * | 2006-06-08 | 2007-12-13 | Mastercard International Incorporated | All-in-one proximity payment device with local authentication |
WO2007143740A3 (en) * | 2006-06-08 | 2008-07-31 | Mastercard International Inc | All-in-one proximity payment device with local authentication |
US20130246793A1 (en) * | 2006-06-19 | 2013-09-19 | Newsecure Innovations Inc. | Method and apparatus for encryption and pass-through handling of confidential information in software applications |
US20150074403A1 (en) * | 2006-10-10 | 2015-03-12 | Qualcomm Incorporated | Method and apparatus for mutual authentication |
US9112860B2 (en) * | 2006-10-10 | 2015-08-18 | Qualcomm Incorporated | Method and apparatus for mutual authentication |
US9047727B2 (en) * | 2006-12-26 | 2015-06-02 | Oberthur Technologies | Portable electronic device and method for securing such device |
US20100017881A1 (en) * | 2006-12-26 | 2010-01-21 | Oberthur Technologies | Portable Electronic Device and Method for Securing Such Device |
US8666906B1 (en) | 2007-10-01 | 2014-03-04 | Google Inc. | Discrete verification of payment information |
US20090153290A1 (en) * | 2007-12-14 | 2009-06-18 | Farpointe Data, Inc., A California Corporation | Secure interface for access control systems |
US9949132B2 (en) * | 2008-07-09 | 2018-04-17 | Samsung Electronics Co., Ltd | Near field communication (NFC) device and method for selectively securing records in a near field communication data exchange format (NDEF) message |
US20150281970A1 (en) * | 2008-07-09 | 2015-10-01 | Samsung Electronics Co., Ltd. | Near field communication (nfc) device and method for selectively securing records in a near field communication data exchange format (ndef) message |
US8943562B2 (en) | 2008-08-11 | 2015-01-27 | Assa Abloy Ab | Secure Wiegand communications |
US8923513B2 (en) | 2008-08-11 | 2014-12-30 | Assa Abloy Ab | Secure wiegand communications |
US20100034375A1 (en) * | 2008-08-11 | 2010-02-11 | Assa Abloy Ab | Secure wiegand communications |
US8358783B2 (en) | 2008-08-11 | 2013-01-22 | Assa Abloy Ab | Secure wiegand communications |
US20100039220A1 (en) * | 2008-08-14 | 2010-02-18 | Assa Abloy Ab | Rfid reader with embedded attack detection heuristics |
US20100241690A1 (en) * | 2009-03-20 | 2010-09-23 | Microsoft Corporation | Component and dependency discovery |
US9596089B2 (en) * | 2010-06-28 | 2017-03-14 | Bundesdruckerei Gmbh | Method for generating a certificate |
US20130318354A1 (en) * | 2010-06-28 | 2013-11-28 | Bundesdruckerei Gmbh | Method for generating a certificate |
US9118666B2 (en) | 2010-06-30 | 2015-08-25 | Google Inc. | Computing device integrity verification |
US9081985B1 (en) | 2010-06-30 | 2015-07-14 | Google Inc. | System and method for operating a computing device in a secure mode |
US8700895B1 (en) | 2010-06-30 | 2014-04-15 | Google Inc. | System and method for operating a computing device in a secure mode |
US20130173467A1 (en) * | 2011-12-29 | 2013-07-04 | Ebay Inc. | Methods and systems for using a co-located group as an authorization mechanism |
US9811827B2 (en) | 2012-02-28 | 2017-11-07 | Google Inc. | System and method for providing transaction verification |
US10839383B2 (en) | 2012-02-28 | 2020-11-17 | Google Llc | System and method for providing transaction verification |
US10366218B2 (en) | 2013-03-22 | 2019-07-30 | Nok Nok Labs, Inc. | System and method for collecting and utilizing client data for risk assessment during authentication |
US10776464B2 (en) | 2013-03-22 | 2020-09-15 | Nok Nok Labs, Inc. | System and method for adaptive application of authentication policies |
US10706132B2 (en) | 2013-03-22 | 2020-07-07 | Nok Nok Labs, Inc. | System and method for adaptive user authentication |
CN105229596A (en) * | 2013-03-22 | 2016-01-06 | 诺克诺克实验公司 | High level of authentication technology and application |
US9898596B2 (en) | 2013-03-22 | 2018-02-20 | Nok Nok Labs, Inc. | System and method for eye tracking during authentication |
US11929997B2 (en) | 2013-03-22 | 2024-03-12 | Nok Nok Labs, Inc. | Advanced authentication techniques and applications |
US10282533B2 (en) | 2013-03-22 | 2019-05-07 | Nok Nok Labs, Inc. | System and method for eye tracking during authentication |
US10268811B2 (en) | 2013-03-22 | 2019-04-23 | Nok Nok Labs, Inc. | System and method for delegating trust to a new authenticator |
US10270748B2 (en) | 2013-03-22 | 2019-04-23 | Nok Nok Labs, Inc. | Advanced authentication techniques and applications |
US10762181B2 (en) | 2013-03-22 | 2020-09-01 | Nok Nok Labs, Inc. | System and method for user confirmation of online transactions |
US10176310B2 (en) | 2013-03-22 | 2019-01-08 | Nok Nok Labs, Inc. | System and method for privacy-enhanced data synchronization |
US9961077B2 (en) | 2013-05-30 | 2018-05-01 | Nok Nok Labs, Inc. | System and method for biometric authentication with device attestation |
US20150066509A1 (en) * | 2013-08-30 | 2015-03-05 | Hon Hai Precision Industry Co., Ltd. | Electronic device and method for encrypting and decrypting document based on voiceprint techology |
US10798087B2 (en) | 2013-10-29 | 2020-10-06 | Nok Nok Labs, Inc. | Apparatus and method for implementing composite authenticators |
US9887983B2 (en) | 2013-10-29 | 2018-02-06 | Nok Nok Labs, Inc. | Apparatus and method for implementing composite authenticators |
US10121144B2 (en) | 2013-11-04 | 2018-11-06 | Apple Inc. | Using biometric authentication for NFC-based payments |
AU2014342529B2 (en) * | 2013-11-04 | 2018-01-18 | Apple Inc. | Using biometric authentication for NFC-based payments |
WO2015066028A1 (en) * | 2013-11-04 | 2015-05-07 | Apple Inc. | Using biometric authentication for nfc-based payments |
US20160314469A1 (en) * | 2013-12-31 | 2016-10-27 | Feitian Technologies Co., Ltd. | Method for generating off-line authentication credentials by intelligent card |
US10448230B2 (en) | 2014-04-25 | 2019-10-15 | Alibaba Group Holding Limited | Data transmission |
US9591616B2 (en) | 2014-04-25 | 2017-03-07 | Alibaba Group Holding Limited | Data transmission |
US10326761B2 (en) | 2014-05-02 | 2019-06-18 | Nok Nok Labs, Inc. | Web-based user authentication techniques and applications |
DE102014108911A1 (en) * | 2014-06-25 | 2015-12-31 | Paschalis Papagrigoriou | Clock with advanced functionality to secure electronic transactions with secure electronic signatures |
US10084761B1 (en) * | 2014-06-27 | 2018-09-25 | Wickr Inc | In-band identity verification and man-in-the-middle defense |
US9465845B2 (en) * | 2014-07-10 | 2016-10-11 | Bank Of America Corporation | Dynamic card validation |
US20160104162A1 (en) * | 2014-07-10 | 2016-04-14 | Bank Of America Corporation | Dynamic card validation |
US9875347B2 (en) | 2014-07-31 | 2018-01-23 | Nok Nok Labs, Inc. | System and method for performing authentication using data analytics |
US10148630B2 (en) | 2014-07-31 | 2018-12-04 | Nok Nok Labs, Inc. | System and method for implementing a hosted authentication service |
US9871789B2 (en) | 2014-10-31 | 2018-01-16 | Advantest Corporation | Authentication system, authentication method and service providing system |
CN104821021A (en) * | 2015-03-30 | 2015-08-05 | 无锡市崇安区科技创业服务中心 | Password information automatic push-based locker control system |
US11544367B2 (en) | 2015-05-05 | 2023-01-03 | Ping Identity Corporation | Systems, apparatus and methods for secure electrical communication of biometric personal identification information to validate the identity of an individual |
US11263302B2 (en) | 2015-08-24 | 2022-03-01 | Giesecke+Devrient Mobile Security Gmbh | Transaction system |
WO2017032452A1 (en) * | 2015-08-24 | 2017-03-02 | Giesecke & Devrient Gmbh | Transaction system |
CN105447934A (en) * | 2015-11-13 | 2016-03-30 | 珠海唯码科技有限公司 | Multiple remote authentication digital anti-theft lock |
EP3171315A1 (en) * | 2015-11-23 | 2017-05-24 | Xiaomi Inc. | Payment verification system, method and apparatus, computer program and recording medium |
GB2547954A (en) * | 2016-03-03 | 2017-09-06 | Zwipe As | Attack resistant biometric authorised device |
US20190065716A1 (en) * | 2016-03-03 | 2019-02-28 | Zwipe As | Attack resistant biometric authorised device |
GB2547954B (en) * | 2016-03-03 | 2021-12-22 | Zwipe As | Attack resistant biometric authorised device |
WO2017152150A1 (en) * | 2016-03-04 | 2017-09-08 | ShoCard, Inc. | Method and system for authenticated login using static or dynamic codes |
US11134075B2 (en) | 2016-03-04 | 2021-09-28 | Ping Identity Corporation | Method and system for authenticated login using static or dynamic codes |
US11658961B2 (en) | 2016-03-04 | 2023-05-23 | Ping Identity Corporation | Method and system for authenticated login using static or dynamic codes |
US10587609B2 (en) | 2016-03-04 | 2020-03-10 | ShoCard, Inc. | Method and system for authenticated login using static or dynamic codes |
US11263415B2 (en) | 2016-03-07 | 2022-03-01 | Ping Identity Corporation | Transferring data files using a series of visual codes |
US11544487B2 (en) | 2016-03-07 | 2023-01-03 | Ping Identity Corporation | Large data transfer using visual codes with feedback confirmation |
US11062106B2 (en) | 2016-03-07 | 2021-07-13 | Ping Identity Corporation | Large data transfer using visual codes with feedback confirmation |
US20170294053A1 (en) * | 2016-04-07 | 2017-10-12 | Yeon Technologies Co., Ltd. | Method, system and communication terminal for patrol with scanning tags |
US10528857B2 (en) * | 2016-07-04 | 2020-01-07 | Kabushiki Kaisha Toshiba | IC card, portable electronic device, and information processing method |
US20190095771A1 (en) * | 2016-07-04 | 2019-03-28 | Kabushiki Kaisha Toshiba | Ic card, portable electronic device, and information processing method |
US10769635B2 (en) | 2016-08-05 | 2020-09-08 | Nok Nok Labs, Inc. | Authentication techniques including speech and/or lip movement analysis |
US10637853B2 (en) | 2016-08-05 | 2020-04-28 | Nok Nok Labs, Inc. | Authentication techniques including speech and/or lip movement analysis |
US10452877B2 (en) | 2016-12-16 | 2019-10-22 | Assa Abloy Ab | Methods to combine and auto-configure wiegand and RS485 |
US10237070B2 (en) | 2016-12-31 | 2019-03-19 | Nok Nok Labs, Inc. | System and method for sharing keys across authenticators |
US10091195B2 (en) | 2016-12-31 | 2018-10-02 | Nok Nok Labs, Inc. | System and method for bootstrapping a user binding |
US11799668B2 (en) | 2017-02-06 | 2023-10-24 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US11323272B2 (en) | 2017-02-06 | 2022-05-03 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US11456998B2 (en) * | 2017-06-07 | 2022-09-27 | Virtual Connect Technologies, Inc. | System and method for encryption, storage and transmission of digital information |
US10708244B2 (en) * | 2017-06-07 | 2020-07-07 | Virtual Connect Technologies, Inc. | System and method for encryption, storage and transmission of digital information |
US20190034934A1 (en) * | 2017-07-28 | 2019-01-31 | Alclear, Llc | Biometric payment |
CN107491678A (en) * | 2017-08-16 | 2017-12-19 | 合肥庆响网络科技有限公司 | Computer iris recognition start-up system |
US20210075598A1 (en) * | 2017-09-22 | 2021-03-11 | NEC Laboratories Europe GmbH | Scalable byzantine fault-tolerant protocol with partial tee support |
US11546145B2 (en) * | 2017-09-22 | 2023-01-03 | Nec Corporation | Scalable byzantine fault-tolerant protocol with partial tee support |
US20200259651A1 (en) * | 2017-10-30 | 2020-08-13 | Visa International Service Association | Multi-party threshold authenticated encryption |
US11552797B2 (en) * | 2017-10-30 | 2023-01-10 | Visa International Service Association | Multi-party threshold authenticated encryption |
US11868995B2 (en) | 2017-11-27 | 2024-01-09 | Nok Nok Labs, Inc. | Extending a secure key storage for transaction confirmation and cryptocurrency |
US11206133B2 (en) | 2017-12-08 | 2021-12-21 | Ping Identity Corporation | Methods and systems for recovering data using dynamic passwords |
US11777726B2 (en) | 2017-12-08 | 2023-10-03 | Ping Identity Corporation | Methods and systems for recovering data using dynamic passwords |
US11646889B2 (en) | 2017-12-19 | 2023-05-09 | Riddle & Code Gmbh | Dongles and method for providing a digital signature |
US11831409B2 (en) | 2018-01-12 | 2023-11-28 | Nok Nok Labs, Inc. | System and method for binding verifiable claims |
US11093655B2 (en) | 2018-04-25 | 2021-08-17 | Blockchain ASICs Inc. | Cryptographic ASIC with onboard permanent context storage and exchange |
US11093654B2 (en) * | 2018-04-25 | 2021-08-17 | Blockchain ASICs Inc. | Cryptographic ASIC with self-verifying unique internal identifier |
US11042669B2 (en) | 2018-04-25 | 2021-06-22 | Blockchain ASICs Inc. | Cryptographic ASIC with unique internal identifier |
US11057187B2 (en) * | 2018-08-09 | 2021-07-06 | Guardtime Sa | Blockchain-assisted hash-based data signature system and method |
DE102018119530A1 (en) * | 2018-08-10 | 2020-02-13 | Bundesdruckerei Gmbh | Network module for providing a communication link between a data processing entity and a communication network |
US11818265B2 (en) | 2018-10-17 | 2023-11-14 | Ping Identity Corporation | Methods and systems for creating and recovering accounts using dynamic passwords |
US11082221B2 (en) | 2018-10-17 | 2021-08-03 | Ping Identity Corporation | Methods and systems for creating and recovering accounts using dynamic passwords |
US10979227B2 (en) | 2018-10-17 | 2021-04-13 | Ping Identity Corporation | Blockchain ID connect |
US11722301B2 (en) | 2018-10-17 | 2023-08-08 | Ping Identity Corporation | Blockchain ID connect |
US11516212B2 (en) * | 2018-11-19 | 2022-11-29 | Authentrend Technology Inc. | Multi-functional authentication apparatus and operating method for the same |
US20200162455A1 (en) * | 2018-11-19 | 2020-05-21 | Authentrend Technology Inc. | Multi-functional authentication apparatus and operating method for the same |
US11736219B2 (en) | 2018-12-28 | 2023-08-22 | Kabushiki Kaisha Toshiba | Communication control device and communication control system |
CN109872233A (en) * | 2019-01-17 | 2019-06-11 | 深圳壹账通智能科技有限公司 | Contract signing method, apparatus, computer equipment and storage medium |
US11792024B2 (en) | 2019-03-29 | 2023-10-17 | Nok Nok Labs, Inc. | System and method for efficient challenge-response authentication |
US20200364722A1 (en) * | 2019-05-16 | 2020-11-19 | Alclear, Llc | Biometric payment processing that configures payment processing for a determined merchant of record |
CN110532807A (en) * | 2019-07-30 | 2019-12-03 | 平安科技(深圳)有限公司 | Electronic voucher generation method, device, computer equipment and storage medium |
CN110929300A (en) * | 2019-12-11 | 2020-03-27 | 中国人民解放军国防科技大学 | Trusted computing security chip construction method based on identification password |
US11804960B2 (en) * | 2020-01-31 | 2023-10-31 | Visa International Service Association | Distributed symmetric encryption |
US20220385463A1 (en) * | 2020-01-31 | 2022-12-01 | Visa International Service Association | Distributed symmetric encryption |
US11170130B1 (en) | 2021-04-08 | 2021-11-09 | Aster Key, LLC | Apparatus, systems and methods for storing user profile data on a distributed database for anonymous verification |
US20230062244A1 (en) * | 2021-09-01 | 2023-03-02 | Qualcomm Incorporated | Extended reality control of smart devices |
CN115660878A (en) * | 2022-11-03 | 2023-01-31 | 深圳标普云科技有限公司 | Electronic invoice realization method and system |
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7558965B2 (en) | Entity authentication in electronic communications by providing verification status of device | |
CA2417901C (en) | Entity authentication in electronic communications by providing verification status of device | |
US7552333B2 (en) | Trusted authentication digital signature (tads) system | |
US8737623B2 (en) | Systems and methods for remotely loading encryption keys in a card reader systems | |
US8447991B2 (en) | Card authentication system | |
US5781723A (en) | System and method for self-identifying a portable information device to a computing unit | |
US6073237A (en) | Tamper resistant method and apparatus | |
KR100768754B1 (en) | Portable electronic charge and authorization devices and methods therefor | |
US7568616B2 (en) | Authentication methods and apparatus for vehicle rentals and other applications | |
US8397988B1 (en) | Method and system for securing a transaction using a card generator, a RFID generator, and a challenge response protocol | |
US8251286B2 (en) | System and method for conducting secure PIN debit transactions | |
US20030101348A1 (en) | Method and system for determining confidence in a digital transaction | |
US20120095919A1 (en) | Systems and methods for authenticating aspects of an online transaction using a secure peripheral device having a message display and/or user input | |
KR20100006004A (en) | Autentification processing method and system using card, card terminal for authentification processing using card | |
US20180253573A1 (en) | Systems and Methods for Utilizing Magnetic Fingerprints Obtained Using Magnetic Stripe Card Readers to Derive Transaction Tokens | |
AU2008203481B2 (en) | Entity authentication in electronic communications by providing verification status of device | |
KR100643501B1 (en) | Key delivery method and the system for IC card issuing | |
Nithyanand | Securing plastic money using an rfid based protocol stack |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FIRST DATA CORPORATION, COLORADO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WHEELER, LYNN HENRY;WHEELER, ANNE M.;REEL/FRAME:012071/0049 Effective date: 20010805 |
|
AS | Assignment |
Owner name: CREDIT SUISSE, CAYMAN ISLANDS BRANCH, AS COLLATERA Free format text: SECURITY AGREEMENT;ASSIGNORS:FIRST DATA CORPORATION;CARDSERVICE INTERNATIONAL, INC.;FUNDSXPRESS, INC.;AND OTHERS;REEL/FRAME:020045/0165 Effective date: 20071019 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: LINKPOINT INTERNATIONAL, INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: DW HOLDINGS INC., COLORADO Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: CARDSERVICE INTERNATIONAL, INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: TELECHECK SERVICES, INC., TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: SIZE TECHNOLOGIES, INC., COLORADO Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: FUNDSXPRESS, INC., TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: TASQ TECHNOLOGY, INC., CALIFORNIA Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: FIRST DATA RESOURCES, LLC, COLORADO Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: INTELLIGENT RESULTS, INC., COLORADO Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: TELECHECK INTERNATIONAL, INC., TEXAS Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 Owner name: FIRST DATA CORPORATION, COLORADO Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:CREDIT SUISSE AG, CAYMAN ISLANDS BRANCH;REEL/FRAME:049902/0919 Effective date: 20190729 |