BACKGROUND
Bluetooth Low Energy (BLE) provides an attractive wireless communication channel due to its low power requirements and ubiquity on mobile phones. However, with a range on the order of 10 meters and the ability to pass through walls, it can be difficult to ensure a connection is between the intended devices. These problems can be easily addressed if each device carries its own display and user input features, such as a fingerprint sensor or numeric keypad. The display, user input and fingerprint sensor add significant costs to the device, both in terms of the individual component costs as well as the processing power to operate them and the complexity of arranging the components on a physical form factor. Lower-cost devices may be produced by omitting some of these components but relying on a second device to provide the necessary UI functionality. This UI device may be controlled by the transaction counterparty, as in the familiar credit card point-of-sale device. Or, it may be a device such as a smartphone or a feature phone owned by the user. Or, it could be like a merchant point-of-sale device but not restricted to transactions with the merchant. Meanwhile, control of the private keys and transaction signing remains on the low-cost device.
Each of these scenarios presents unique operational and security challenges. In the case where the counterparty controls the UI device, there are obvious motives for theft. For example, if the low-cost user device is without a display, the UI device could display one amount while charging a larger amount. Or, if the user is required to enter their PIN or fingerprint into the UI device, these could be recorded in a database. While the PIN for fingerprint alone would not allow theft of funds without the user device holding the private key, the database may be later utilized with lost or stolen devices. Or, the same PIN or fingerprint might be used to authorize entirely independent services of high value.
SUMMARY
At least one of a user-buyer device or a point of sale (POS) device having a UI (user interface) is configured with hardware, software, or algorithmic protocols, configurations, and safeguards that combat attempted unauthorized activity and theft by malicious attackers. Such configurations are in place to safeguard transactions between an authenticated buyer-user device and a POS device. Using digital certificates at one or both of the POS device or buyer device enables the other party to verify the other party and ensure that some malicious device has not intercepted communications or performed some man-in-the-middle attack.
Configuring digital certificates or other certificates with codes, personally identifying information, PIN (personal identification number) or biometric requirements can help the buyer-user verify that their device is connected to and authorize a transaction at the POS device. Furthermore, using a set of approved digital certificates from a payment service provider ensures the buyer and counterparty (e.g., point of sale user) communicate with a verified source. Leveraging QR (quick response) codes or randomly generated codes coupled with the buyer device's unique digital certificate even further ensures that the POS device is connected to the correct and intended buyer.
This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.
DESCRIPTION OF THE DRAWINGS
FIG. 1 shows an illustrative representation of an executed transaction between two parties recorded at a remote service;
FIG. 2 shows illustrative user devices that may be used to purchase items at a counterparty or point of sale (POS) device;
FIG. 3 shows an illustrative representation of a malicious counterparty stealing from an honest buyer;
FIG. 4 shows an illustrative representation of a ‘buyer’s user device verifying a counterparties digital certificate;
FIG. 5 shows an illustrative representation of exemplary connection mechanisms between a user device and POS device;
FIG. 6 shows an illustrative representation of the user entering an input at their user device upon establishing a connection with a POS device;
FIG. 7 shows an illustrative representation of a malicious POS device interfering with the user's device's connection to an intended POS device;
FIG. 8 shows an illustrative representation of malicious buyer and POS devices interfering with the authentic buyer ‘device’s connection with an authentic POS device;
FIG. 9 shows an illustrative representation of the utilization of a PIN (personal identification code) or biometric scan to verify the authenticity of the user;
FIG. 10 shows an illustrative representation of digital certificates being configured with additional information for user verification at the authentic POS device;
FIG. 11 shows an illustrative representation of the manufacturing process of a smartcard or other user device;
FIG. 12 shows an illustrative representation of possible corruption within the manufacturing process;
FIG. 13 shows an illustrative representation of an authentic buyer ‘device’s digital certificate configured with a unique code for verification at the POS device;
FIG. 14 shows an illustrative representation of utilizing a QR (quick response) code at a buyer device to authenticate the user device's digital certificate;
FIG. 15 shows an illustrative representation of utilizing a randomly generated code so the POS device can uniquely identify the buyer device;
FIG. 16 shows an illustrative representation of utilizing an NFC (near field communication) connection so the POS device can uniquely identify the buyer device;
FIGS. 17-18 show illustrative flowcharts of the system leveraging hardware and software configurations to safeguard multi-party transactions from malicious attacks;
FIG. 19 shows a simplified block diagram of a computing device that may be used to implement the present secure pairing for payment devices; and
FIG. 20 shows a simplified block diagram of a computing device that may be used to implement the present secure pairing for payment devices.
Like reference numerals indicate like elements in the drawings. Elements are not drawn to scale unless otherwise indicated.
DETAILED DESCRIPTION
FIG. 1 shows an illustrative representation in which a buyer 110 executes a transaction with counterparty 120 and the transaction 125 is recorded with a remote ledger service or a financial service (individually and collectively represented by reference numeral 130). In a typical scenario, the buyer-user may attempt to execute a transaction with a counterparty, which can include a retail store, restaurant, service store, etc. The user 110 may use their smartcard or another capable device to transfer money to the ‘counterparty’s POS (point of sale) device 115 in exchange for goods or services. This transaction, once complete, may involve contacting and/or recording the transaction with a remote ledger service and/or a financial service, such as one or both parties' banks. A description for executing these transactions and recording them remotely can be viewed in U.S. Pat. No. 11,301,554, entitled Secure Tamper Resistant Smart Card,” filed Mar. 13, 2019, and U.S. application Ser. No. 17/449,677, entitled “Leveraging Tamper-Resistant Hardware to Transfer Digital Currency between Local Devices,” filed Oct. 1, 2021, the entire contents of both applications of which are hereby incorporated herein by reference.
The buyer device 105, in this example, is a smartcard configured with a chip 135 and a button 140 that the user 110 can press to initiate transactions or execute other programmed functions. The smartcard 105 may be configured similarly as discussed in U.S. Pat. No. 11,301,554, entitled “Secure Tamper Resistant Smart Card,” filed Mar. 13, 2019, the entire contents of which are hereby incorporated herein by reference. For example, the smartcard can include one or more chips (processors), hardware-based memory devices storing data and instructions, among other components and configurations disclosed in U.S. Pat. No. 11,301,554. FIG. 2 shows illustrative user devices that may be used herein, including an array of smartcards, including a smartcard without an input button 140, or a smartcard with a display interface 205. The additional configuration of the UI on the smartcard is also discussed in U.S. Pat. No. 11,301,554, referenced above, and the discussion therein is also incorporated herein by reference. Other devices that may be used can include computing devices like a tablet computer 210, smartphone 215, or other types of computing devices, including smartwatches, laptop computers, etc.
FIG. 3 shows an illustrative representation in which a user 110, using smartcard buyer device 105, initiates a transaction 305 at a POS device 115 having a user interface (UI) 310. In this regard, the disclosure herein typically focuses on scenarios in which the buyer device 105 is a ‘low-cost’ device that may not have a display or any user input control beyond a simple button. The benefit of using such a device is a low cost that makes such a device globally feasible. Low-cost payment devices are available in the form of traditional credit cards, but these generally require an expensive and highly trusted counterparty device to ensure security. This disclosure typically focuses on scenarios where the POS device is a low-power BLE (Bluetooth® low energy) device that is not necessarily trustworthy, although other forms of wired and wireless connections are also possible with the present implementation details. The low-cost buyer device may interact with a POS device 115 configured with a UI to enable some real-world communication between the buyer and counterparty. Thus, in most examples herein, a low-cost buyer device attempts a connection and transaction with a POS device having UI. Although a display screen is typically shown, other interfaces, such as speakers, a camera for capturing inputs, flashing lights, etc., are also possible.
In FIG. 3, the user 105 attempts a transaction 305 with the counterparty 210. Responsive to establishing a connection, the POS device 115 can request the user to either enter a PIN (personal identification number) or scan their finger for a biometric scan, among other user authenticating techniques (e.g., alpha-numeric password). Alternatively, the POS device may ask the user to verify that the transaction is approved for a certain amount, like $50. In both scenarios, the user cannot verify that the ‘counterparty’s device is not malicious and attempting to steal the ‘user’s credentials for future use or approve a different amount (e.g., $1,500).
FIG. 4 shows an illustrative representation in which a digital certificate 405 is generated and associated with approved POS device 115 for verification by a buyer device 105. Upon initiating the transaction 305, the user 110 may attempt to establish an authenticated, encrypted connection to the POS device 115 by sending a public key 430, along with a digital certificate 415, which has been signed by a payment service provider 410 to certify that the public key 430 belongs to an authorized buyer device 105. The digital certificate 415 may include the owner or user's name, identification of the payment service provider, the date from which the certificate is valid, an expiration date, and a serial number uniquely associated with the certificate, among other information depending on the specific implementation details. Thus, the first step shown in FIG. 4 includes evaluating bank/digital certificate to verify that the counterparty's public key belongs to an authorized account.
After verifying that the buyer public key 430 is authorized by the payment service provider 410, the POS device may return its own public key 420, along with the digital certificate 405, which a payment service provider has signed 410 to certify that the public key 420 belongs to an authorized POS device, allowing the buyer device 105 to verify that the public key 420 belongs to an authorized POS device 115. The POS device's digital certificate may be configured similarly to the buyer device's certificate. Each device may be configured with one or more pre-set public keys that enable it to authenticate that the counterparty certificate is authorized with a mutually trusted payment service provider 410. The payment service provider may be a remote service that generates secure digital certificates for authorized devices. Each device may create an account and go through a sign-up process before the provider issues a digital certificate. Thus, each device may verify that the counterparty device has a public key that has been authorized by the payment service provider and automatically aborts the payment transaction if the authorization fails. Aborting the transaction can include either one or both of the devices disconnecting from the other.
Diffie-Hellman key exchange allows two parties who share a public key with each other to derive a shared secret. Each party takes the Public Key provided by the other party and combines it with their own private key to generate a secret, which will be the same on both sides. If this key is then used in an Authenticated Encryption algorithm, a successful message exchange proves that each party knew the private key associated with the public key they shared in the initial exchange. If they didn't know the private key, they wouldn't be able to compute the same secret and the Authenticated Encryption would fail.
So, the successful Diffie-Hellman key exchange plus EAX proves the counterparty “owns” the public key they presented. If we have a digital certificate from a trusted third party, such as the payment service provider, that says the public key belongs to some unique user, then we are certain we are connected to that unique user, and there can be no man in the middle. The bank signature in the digital certificate proves that the owner of the public key in the certificate is that unique user and has whatever other properties are included in the certificate (e.g., phone number, etc.). Then, the Diffie-Hellman key exchange proves that the device currently holding that certificate knows the private key associated with that public key, thereby preventing certificate theft. Thus, the second step in FIG. 4 is to generate a Diffie-Hellman shared key for input into Authenticated Encryption algorithm, to establish a secure connection to the owner of the public key.
A Diffie-Hellman key exchange can then be used to generate a shared secret for input into an authenticated encryption scheme, such as the EAX (encrypt-then-authenticate) mode of AES (advanced encryption standard). As well as generating a shared secret, this step confirms that each device possesses the private key associated with the public key that the certificate has authorized in the preceding step. Thus, the buyer device 105 can establish a secure communication channel with an authentic POS device 115. The Diffie-Hellman key agreement is a method for two parties to agree on a shared secret without revealing this shared secret to eavesdroppers. The two parties exchange public keys, and each party then uses its own Diffie-Hellman private key with the other party's Diffie-Hellman public key to compute the same shared secret (the Diffie-Hellman shared secret). This shared secret is not revealed to eavesdroppers or malicious devices because, while they can know the public keys, they do not know the two Diffie-Hellman private keys to compute the shared secret.
FIG. 5 shows an illustrative representation in which the smartcard 105, or another buyer device, connects 505 to a POS device 115 over various methods. For example, the smartcard may be inserted into the POS device's receptacle or slot, relying on BLE, NFC (near field communication), WiFi or other over-the-air connection, or a USB (universal serial bus) or other wired connection. The connection 505 is the first step before any transaction between a user 110 and counterparty 120 can initiate. The connection is a point within the transaction that can result in malicious attacks and theft, and subsequent discussions at least partially deal with safeguarding against malicious attacks.
FIG. 6 shows an illustrative representation in which the user device 105 connects 505 with a POS device 115. In typical transactions, the UI 310 on the POS device provides some indication to the user of the transaction's progression. Here, the UI indicates that a connection was established and that the user should confirm the transaction for processing, such as by pressing an input at their user device 105. The user 110 can click/input 610 on the button 140 to initiate and execute the transaction with the POS device, as representatively illustrated by reference numeral 605. Failure to press the button within a pre-set period of time, such as 30 seconds, can result in a disconnection or transaction cancellation.
FIG. 7 shows an illustrative representation in which the user 110 intends to connect with counterparty 120, as represented by reference numeral 710. However, the buyer ‘device’s actual connection is with a malicious device 720, which may be considered a malicious POS device, malicious user device, malicious UI device, and the like. The user may not observe or be aware of the presence of a malicious device 720, but nonetheless, the user may not be able to control which device—within operational proximity—the user device connects to.
This attack is not possible because an authentic POS device 115 will not have the ability to simultaneously act in the role of a POS device and a buyer device 105. If a device has these capabilities, then the payment service provider will not grant it a certificate to act as a POS device or as a buyer device. Thus, neither the buyer device 105 nor the POS device 115 will connect to it.
FIG. 8 shows an illustrative representation in which multiple malicious devices are used to scam authenticated buyer devices 105 and POS devices 115. For example, while the authentic user and POS devices intend to connect with each other, as shown by reference numeral 805, a pair of actual connections with malicious devices may be established, as represented by reference numeral 810. The user device 105 is actually connected with malicious and hidden UI device 820 (e.g., a malicious POS device) operated by malicious user 825, and the visible POS device 115 is actually connected with a malicious and hidden user-buyer device 815 operated by malicious user 825. In typical implementations, since the malicious devices are authentic with payment provider certificates to establish connections with the visible user and POS devices 105,115, they cannot connect directly to each other. However, it is conceivable that a malicious person, or some electromechanical device, may operate both malicious devices in such a way that the visible POS device 115 appears to be responsive to inputs on the user device 105. For example, the POS device 115 may display the transaction amount as $20 and signal the connected malicious user device 815 to beep or flash a light requesting user approval. If instead of approving the transaction, the malicious person 825 operated on the hidden POS device 820 to request $1000, that would signal the user device 105 to beep or flash a light at the correct time. The user may then enter an input 610 on their device's button 140 to execute the $1000 transaction on the hidden POS device 810. Then, as soon as the hidden POS device 820 responds to the user button press, the malicious person can press the button on the hidden buyer device 815 to execute the $20 transaction displayed on the POS device 115. Thus, the authentic POS device 115 may display an executed transaction (e.g., “Approved for $20”) and the user leaves the store short $1,000, or $980 more than their intended amount.
FIGS. 9 and 10 show illustrative representations that can safeguard against malicious attacks shown in FIG. 8. In FIG. 9, the authenticated POS device 115 may be configured to request a PIN or biometric scan to authenticate the user 110. In this situation, the actually connected malicious buyer device 815 would not have a PIN or biometric scan that matches up to the authenticated user 110, resulting in the transaction being canceled for an incorrect PIN or scan. The ‘user’s input at the POS device 115 may occur before or after the user clicks the button 140.
In FIG. 10, the digital certificates 405 associated with buyer device 105 may be pre-configured with additional identifying information that is also transmitted to POS device 115. Identifying information can include the ‘user’s name, date of birth, phone number or partial number, or other identifying information. Accordingly, the POS device's UI 310 displays additional information that the authenticated user 110 can use to verify the authenticity of the transaction. For example, the UI displays the amount and the ‘user’s name. If the user does not recognize the name, then the user can choose not to click the button 140 to execute the transaction, which will result in transaction timeout and cancellation. In this scenario, since the authenticated user device 105 is not actually connected to the authenticated POS device 115, but rather the malicious buyer device 815 is connected, the authenticated POS device 115 displays the identifying information associated with the malicious buyer ‘device’s digital certificate 405. Each ‘device’s digital certificate is unique to that device. As the identifying information is encrypted with the digital certificate, the malicious buyer and POS devices are unable to steal the ‘user’s information as the authenticated POS device 115 independently verifies the unique digital certificate for each connected buyer device. A stolen certificate is useless because the thief will not know the private key that is necessary to complete the initial Diffie-Hellman key exchange.
FIG. 11 shows an illustrative representation in which a smartcard 105 or another buyer device 105 is created at a manufacturing facility 1110. During the manufacturing process 1105 of a buyer device, such as a smartcard, the facility may interoperate with a payment service provider 410 that generates and integrates the digital certificate 405 into the smartcard, as representatively illustrated by numeral 1115. Such as process helps safeguard the authenticity of the unique ‘device’s digital certificate. The devices may be connected to a local computer that is able to upload and configure the buyer devices, and the local device may have extensibility to the payment service provider. The created buyer devices may then be delivered to stores 1120 by deliverer 1145. When a user purchases or otherwise obtains the buyer device at a store 1125, as representatively illustrated by numeral 1130, an employee may be equipped to customize and configure the buyer device with user information, such as date of birth, name, phone number, etc. 1135. Then, the employee may communicate with the payment service provider to request an additional certificate that certifies the personal identifying information. Typically, this request may include the signed manufacturing certificate 405, so the payment service provider can issue a new certificate that links the personal identifying information to the existing device certificate or refuse to provide it if the manufacturing certificate 405 is not valid. From here, the user takes their new card home. Such employee-driven customization of the card can be identified as possible corruption, as shown by reference numeral 1205 in FIG. 12. For example, the employee may intentionally or unintentionally make an error or steal information for future malicious purposes.
FIG. 13 shows an illustrative representation in which a unique user code associated with the buyer device 105 is associated with the digital certificate and is output by POS devices upon connection to avoid relying on employee customizations (FIGS. 11-12). For example, a unique code or truncated version 1310 of the code with the digital certificate can be displayed on the POS device's UI 310. As these codes are generated at production and not selected by the user, in typical implementations, collisions and overlap among different users are unlikely.
FIG. 14 shows an illustrative representation in which, during production, a QR (quick response) code 1405 or other scannable or unique code is physically stamped on the buyer device 105. The QR code may be generated using some deterministic process (e.g., some deterministic algorithm based on a preceding step or input, such as the number of the card in the process) or randomly chosen with enough bits (e.g., 128) to make collision unlikely. The QR code is uniquely associated with the buyer ‘device’s digital certificate 405. A POS device 115 with a camera can capture the QR code and then uniquely identify the digital certificate associated with the QR code for connecting. If the digital certificate of the connected device does not match the referenced digital certificate in the scanned QR code, the POS device can deny the connection or transaction.
FIG. 15 shows an illustrative representation in which the buyer device 105, equipped with a UI, can display a randomly generated code. The POS device 115, upon connecting with the buyer device, prompts the user to input the randomly generated code from the user device to authenticate. The POS device may still additionally verify the unique digital certificate 405. Such dual authentication tactics can ensure that the POS device has identified, authenticated, and connected to the appropriate device. If the POS device is set up with a camera, it could capture the randomly generated code on the ‘user’s device, leverage specialized image generation processing, and verify the buyer device. This “out of band” code can then be combined with the key generated by Static Diffie-Hellman key exchange to establish a mutually authenticated secure communication channel
FIG. 16 shows an illustrative representation in which an NFC (near field communication) connection 1505 is leveraged by the POS device 115 to authenticate the buyer device 105. Standard NFC technology utilizes a high-powered device to read an unpowered device. However, the same basic technology may be adapted to transmit a randomly generated code between 2 low-powered devices. Alternatively, an optical coupling may be used to share a randomly generated code between 2 devices that are held close together to prevent any other device from intercepting the optical signal. The “out of band” NFC or optically transmitted code may be combined with the Static Diffie-Hellman key to establishing a mutually authenticated secure communication channel while eliminating the chance of connecting to any hidden devices.
FIGS. 17 and 18 show illustrative processes performed by a buyer-user computing device (e.g., smartcard), POS computing device, or a combination thereof. Although the steps are shown in sequential order, the features and actions therein may be alternatively arranged and/or certain steps may be added or removed. The process is exemplary only to show one specific implementation for understanding the present ‘disclosure’s features.
In step 1705, in FIG. 17, the user device establishes a connection with a POS device to initiate a transaction. The transaction can be, for example, the user device paying some monetary amount ($10, $20, $1,000, etc.) in exchange for goods or services from the operator of the POS device. Thus, the user can transfer $20 from the ‘user’s bank account to the POS operator's bank account. In step 1710, the user device transmits a public key to the POS device to initiate a verification process. In step 1715, the user device verifies a digital signature associated with the POS device responsive to transmitting the public key. In step 1720, upon verifying the digital certificate, the user device authorizes the execution of the transaction. Specifically, the user device authorizes a bank transfer of some amount to the POS operator's bank account.
In step 1805, in FIG. 18, the user device establishes a connection with a POS device to initiate a transaction. In step 1810, the user device transmits a public key to the POS device. In step 1815, upon the POS device authenticating the user device, the user device receives a public key associated with the POS device for authentication purposes. In step 1820, the user device verifies that the received public key indicates that the POS device is authenticated with a payment service provider. In step 1825, upon verifying the POS device, the user device authorizes the execution of the transaction.
FIG. 15 shows an illustrative architecture 1500 for a device, such as a smartphone, tablet, or laptop computer, capable of executing the various features described herein. The architecture 1500 illustrated in FIG. 15 includes one or more processors 1502 (e.g., central processing unit, dedicated AI chip, graphics processing unit, etc.), a system memory 1504, including RAM (random access memory) 1506, ROM (read-only memory) 1508, and long-term storage devices 1512. The system bus 1510 operatively and functionally couples the components in the architecture 1500. A basic input/output system containing the basic routines that help to transfer information between elements within the architecture 1500, such as during startup, is typically stored in the ROM 1508. The architecture 1500 further includes a long-term storage device 1512 for storing software code or other computer-executed code that is utilized to implement applications, the file system, and the operating system. The storage device 1512 is connected to the processor 1502 through a storage controller (not shown) connected to the bus 1510. The storage device 1512 and its associated computer-readable storage media provide non-volatile storage for the architecture 1500. Although the description of computer-readable storage media contained herein refers to a long-term storage device, such as a hard disk or CD-ROM drive, it may be appreciated by those skilled in the art that computer-readable storage media can be any available storage media that can be accessed by the architecture 1500, including solid stage drives and flash memory.
By way of example, and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. For example, computer-readable media includes, but is not limited to, RAM, ROM, EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), Flash memory or other solid state memory technology, CD-ROM, DVDs, HD-DVD (High Definition DVD), Blu-ray, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the architecture 1500.
According to various embodiments, the architecture 1500 may operate in a networked environment using logical connections to remote computers through a network. The architecture 1500 may connect to the network through a network interface unit 1516 connected to the bus 1510. It may be appreciated that the network interface unit 1516 also may be utilized to connect to other types of networks and remote computer systems. The architecture 1500 also may include an input/output controller 1518 for receiving and processing input from a number of other devices, including a keyboard, mouse, touchpad, touchscreen, control devices such as buttons and switches or electronic stylus (not shown in FIG. 15). Similarly, the input/output controller 1518 may provide output to a display screen, user interface, a printer, or other type of output device (also not shown in FIG. 15).
It may be appreciated that any software components described herein may, when loaded into the processor 1502 and executed, transform the processor 1502 and the overall architecture 1500 from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. The processor 1502 may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the processor 1502 may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the processor 1502 by specifying how the processor 1502 transitions between states, thereby transforming the transistors or other discrete hardware elements constituting the processor 1502.
Encoding the software modules presented herein also may transform the physical structure of the computer-readable storage media presented herein. The specific transformation of physical structure may depend on various factors in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable storage media, whether the computer-readable storage media is characterized as primary or secondary storage, and the like. For example, if the computer-readable storage media is implemented as semiconductor-based memory, the software disclosed herein may be encoded on the computer-readable storage media by transforming the physical state of the semiconductor memory. For example, the software may transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. The software also may transform the physical state of such components in order to store data thereupon.
As another example, the computer-readable storage media disclosed herein may be implemented using magnetic or optical technology. In such implementations, the software presented herein may transform the physical state of magnetic or optical media, when the software is encoded therein. These transformations may include altering the magnetic characteristics of particular locations within given magnetic media. These transformations also may include altering the physical features or characteristics of particular locations within given optical media to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.
In light of the above, it may be appreciated that many types of physical transformations take place in the architecture 1500 in order to store and execute the software components presented herein. It also may be appreciated that the architecture 1500 may include other types of computing devices, including wearable devices, handheld computers, embedded computer systems, smartphones, PDAs, and other types of computing devices known to those skilled in the art. It is also contemplated that the architecture 1500 may not include all of the components shown in FIG. 15, may include other components that are not explicitly shown in FIG. 15, or may utilize an architecture completely different from that shown in FIG. 15.
The computing device may further be configured with tamper-resistant hardware 1522 to execute various functions and operations discussed herein, such as the various transmissions performed by the sending computing device or the receiving computing device. The tamper-resistant hardware may be considered a device that is configured to make a private key unavailable outside its enclosure, require an authorization value in order to use its private key, be immutable, and prevent access after too many incorrect authorization value guesses, among other security features. While hardware features are discussed herein, the tamper-resistance may be configured as a hybrid of hardware and software, purely hardware, or purely software. The tamper-resistant device may exhibit signs of attempted corruption or may react when some physical intrusion is attempted. The tamper-resistant hardware may be a trusted platform module (TPM) or implemented as a Trusted Execution Environment (TEE) created as a portion of the exposed processor.
FIG. 16 is a simplified block diagram of an illustrative computer system 1600 such as a remote server, smartphone, tablet computer, laptop computer, or personal computer (PC) which the present disclosure may be implemented. Computer system 1600 includes a processor 1605, a system memory 1611, and a system bus 1614 that couples various system components including the system memory 1611 to the processor 1605. The system bus 1614 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, or a local bus using any of a variety of bus architectures. The system memory 1611 includes read only memory (ROM) 1617 and random access memory (RAM) 1621. A basic input/output system (BIOS) 1625, containing the basic routines that help to transfer information between elements within the computer system 1600, such as during startup, is stored in ROM 1617. The computer system 1600 may further include a hard disk drive 1628 for reading from and writing to an internally disposed hard disk, a magnetic disk drive 1630 for reading from or writing to a removable magnetic disk (e.g., a floppy disk), and an optical disk drive 1638 for reading from or writing to a removable optical disk 1643 such as a CD (compact disc), DVD (digital versatile disc), or other optical media. The hard disk drive 1628, magnetic disk drive 1630, and optical disk drive 1638 are connected to the system bus 1614 by a hard disk drive interface 1646, a magnetic disk drive interface 1649, and an optical drive interface 1652, respectively. The drives and their associated computer-readable storage media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1600. Although this illustrative example includes a hard disk, a removable magnetic disk 1633, and a removable optical disk 1643, other types of computer-readable storage media which can store data that is accessible by a computer such as magnetic cassettes, Flash memory cards, digital video disks, data cartridges, random access memories (RAMs), read only memories (ROMs), and the like may also be used in some applications of the present disclosure. In addition, as used herein, the term computer-readable storage media includes one or more instances of a media type (e.g., one or more magnetic disks, one or more CDs, etc.). For purposes of this specification and the claims, the phrase “computer-readable storage media” and variations thereof, are intended to cover non-transitory embodiments, and does not include waves, signals, and/or other transitory and/or intangible communication media.
A number of program modules may be stored on the hard disk, magnetic disk, optical disk 1643, ROM 1617, or RAM 1621, including an operating system 1655, one or more application programs 1657, other program modules 1660, and program data 1663. A user may enter commands and information into the computer system 1600 through input devices such as a keyboard 1666, pointing device (e.g., mouse) 1668, or touch-screen display 1673. Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, trackball, touchpad, touch-sensitive device, voice-command module or device, user motion or user gesture capture device, or the like. These and other input devices are often connected to the processor 1605 through a serial port interface 1671 that is coupled to the system bus 1614, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor 1673 or other type of display device is also connected to the system bus 1614 via an interface, such as a video adapter 1675. In addition to the monitor 1673, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The illustrative example shown in FIG. 16 also includes a host adapter 1678, a Small Computer System Interface (SCSI) bus 1683, and an external storage device 1676 connected to the SCSI bus 1683.
The computer system 1600 is operable in a networked environment using logical connections to one or more remote computers, such as a remote computer 1688. The remote computer 1688 may be selected as another personal computer, a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computer system 1600, although only a single representative remote memory/storage device 1690 is shown in FIG. 16. The logical connections depicted in FIG. 16 include a local area network (LAN) 1693 and a wide area network (WAN) 1695. Such networking environments are often deployed, for example, in offices, enterprise-wide computer networks, intranets, and the Internet.
When used in a LAN networking environment, the computer system 1600 is connected to the local area network 1693 through a network interface or adapter 1696. When used in a WAN networking environment, the computer system 1600 typically includes a broadband modem 1698, network gateway, or other means for establishing communications over the wide area network 1695, such as the Internet. The broadband modem 1698, which may be internal or external, is connected to the system bus 1614 via a serial port interface 1671. In a networked environment, program modules related to the computer system 1600, or portions thereof, may be stored in the remote memory storage device 1690. It is noted that the network connections shown in FIG. 16 are illustrative and other means of establishing a communications link between the computers may be used depending on the specific requirements of an application of the present disclosure.
Various illustrative implementations are disclosed herein. In one exemplary implementation there is a user computing device, comprising: one or more processors; and one or more hardware-based memory devices having instructions which, when executed by the one or more processors, cause the sending computing device to establish a connection with a point of sale (POS) device to initiate a transaction; transmit a public key to the POS device to initiate a verification process; verify a digital certificate associated with the POS device responsive to transmitting the public key; and upon verifying the POS device's digital certificate, authorize execution of the transaction.
In another example, the user computing device is configured with a digital certificate distinct from the POS device's digital certificate, in which the user computing ‘device’s digital certificate enables the POS device to authenticate the user computing device. As another example, the user computing ‘device’s digital certificate is further configured with information unique to the user computing device or the unique user of the user computing device. In another example, the information includes any one or more of a unique PIN (personal identification code), user biometrics, user date of birth, user name, or user phone number. As another example, the information is transmitted to the POS device with the digital certificate. In another example, the POS device's UI (user interface) exposes the received information associated with the user computing ‘device’s digital certificate for user verification. In another example, further including a physical stamp that is uniquely associated with and identifies the digital certificate associated with the user computing device. In another example, further including a button, in which the execution of the transaction occurs after the user presses the button and the POS device's digital certificate is verified.
In another exemplary embodiment, disclosed is one or more hardware-based memory devices storing computer-executable instructions which, when executed by one or more processors associated with a user computing device, cause the sending computing device to: establish a connection with a point of sale (POS) device to initiate a transaction; transmit a public key to the POS device to initiate a verification process; verify a digital certificate associated with the POS device responsive to transmitting the public key; and upon verifying the POS device's digital certificate, authorize execution of the transaction.
As another example, the user computing device is configured with a digital certificate distinct from the POS device's digital certificate, in which the user computing ‘device’s digital certificate enables the POS device to authenticate the user computing device. In another example, the user computing ‘device’s digital certificate is further configured with information unique to the user computing device or the unique user of the user computing device. As another example, the information includes any one or more of a unique PIN (personal identification code), user biometrics, user date of birth, user name, or user phone number. In another example, the information is transmitted to the POS device with the digital certificate. As another example, the POS device's UI (user interface) exposes the received information associated with the user computing ‘device’s digital certificate for user verification. In another example, further including a physical stamp that is uniquely associated with and identifies the digital certificate associated with the user computing device. As another example, further including a button, in which the execution of the transaction occurs after the user presses the button and the POS device's digital certificate is verified.
In another exemplary embodiment, disclosed is a method performed by a user computing device, comprising: establishing a connection with a point of sale (POS) device to initiate a transaction; transmitting a public key to the POS device to initiate an authentication process; upon the POS device authenticating the user device receiving a public key from the POS device for authentication purposes; verifying the received public key indicates the POS device is authenticated with a payment service provider; and upon verifying the POS device is authenticated with the payment service provider, authorizing execution of the transaction. In another example, the user computing device is configured with a digital certificate distinct from the POS device's digital certificate, in which the user computing ‘device’s digital certificate enables the POS device to authenticate the user computing device. As another example, the user computing ‘device’s digital certificate is further configured with information unique to the user computing device or the unique user of the user computing device. As another example, subsequent communications between the user device and the POS device are performed using a Diffie-Hellman key exchange based on the exchanged public keys.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Patent Application
20230146558
