Conceptio › Archive › Google Patents

Google Patents open access

POS system with white box encryption key sharing — Clover Network, Llc. (US11615411B2)

Clover Network, Llc. · Google Patents

Google Patents · Patents

en google-patents intellectual-property patent

2. The computer readable media of claim 1 , wherein: the second device is a touch display device; and after the encrypting of the sensitive data, the sensitive data is an encrypted personal identification number. 3. The computer readable media of claim 2 , wherein the method further comprises: POS system with white box encryption key sharing — Clover Network, Llc. (US11615411B2)

Conceptio Open Archive

Analyze & explore related research in Conceptio

Connect this record directly into your research workflow or AI agent. Explore citations across open repositories, query full text, and export structured proof bundles.

Explore in Search →Connect via MCP / API ↗

ABSTRACT

Abstract

Systems, and associated methods, involving both a trusted and an untrusted device where sensitive data or keys are shared between those devices are disclosed. A disclosed method includes storing a key in a secure memory on a first device, receiving sensitive data via a user interface on a second device, generating a set of white box encryption instructions based on the key using a white box encryption generator on the first device, generating a complete data representation of the set of white box encryption instructions using a secure processor on the first device, transmitting the complete data representation from the first device to the second device, and encrypting the sensitive data using the complete data representation on the second device. The complete data representation is not Turing complete and is not executable with respect to the second device.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 16/169,351, filed on Oct. 24, 2018, which is a continuation of U.S. patent application Ser. No. 15/843,264, filed on Dec. 15, 2017, now U.S. Pat. No. 10,140,612, all of which are incorporated by reference in their entirety herein for all purposes.

BACKGROUND

In certain technical environments, a trusted device and an untrusted device are required to securely share information. As used herein, trust is defined with respect to the perspective of an observer, such as the manufacturer of a device, and relates to a level of confidence held by that observer as to how secure a system is. Generally, a manufacturer will be able to assure that the devices they produce are trusted, but cannot have the same level of confidence in devices produced by unrelated third parties. Therefore, the manufacturer must consider the possibility that data stored in the memory of an untrusted device can be monitored and extracted without the permission of the operator of that untrusted device.

A specific example of one of the technical environments mentioned above is illustrated in FIG. 1 . A secure card reader 100 can be paired with a smartphone 101 , or other device, for purposes of processing a payment. Secure card readers that are configured for use with standard smartphones and tablets are appealing from a user convenience perspective because of the flexibility they provide and the division of labor between a low-cost task-specific device and a more complex user interface device that is already widely available. Standard secure card readers that are available today will obtain sensitive data from a payment card 102 and encrypted it internally. The secure card reader can then transmit the encrypted data to a payment processor 103 . In this situation, the untrusted device (i.e., smartphone 101 ) is never in contact with unencrypted sensitive data, and instead merely provides a means for interfacing with the user. The term user input device is used herein to refer to the smartphone, tablet, or other discrete device that is operating in tandem with the secure card reader to communicate with a user and process a payment.

In certain payment flows, sensitive data is provided from a user via both the card reader and the separate user input device. For example, as shown in the bottom half of FIG. 1 , secure card reader 100 could be used to obtain a personal account number (PAN) from a magnetic stripe or chip on a debit card, while smartphone 101 is used to obtain a personal identification number (PIN) from the card holder using a touch screen. In this situation, both secure card reader 100 and smartphone 101 will need to encrypt the data they receive to maintain the required level of security associated with processing payments.

Secure card readers are widely available, but the ability to receive a âPIN on glassâ via the touch screen of any given smartphone is a functionality that is not widely available due to industry difficulties with extending standards-based security to an arbitrary smartphone. Therefore, because of the difficulty of sharing secure data and encryption keys with an unsecure or untrusted device, payment flows involving the entry of a pin on a smartphone are generally not supported by the convenient combination of a secure card reader and smartphone.

Secure communication between devices is often achieved through an exchange of keys such as those used for symmetric or asymmetric encryption. In the system of FIG. 1 , one solution that could mitigate security concerns would be to encrypt the PIN on smartphone 101 using a key 105 previously provided from the secure card reader 100 over line 104 . However, the untrusted nature of smartphone 101 complicates this approach. As mentioned previously, a key shared with an untrusted device could essentially be exposed when it is stored or used by an untrusted device. In an extreme case, an attacker could have the ability to monitor the execution of code on the untrusted device and extract the key. This extraction could be achieved by directly stealing the key data, monitoring the intermittent values generated in memory during an encryption process and extrapolating the key data, or monitoring the input-output of the encryption process over many samples to extrapolate the key data.

SUMMARY

Certain approaches disclosed herein relate to systems involving both a trusted and an untrusted device where sensitive data or keys are shared between those devices. The trusted and untrusted devices can be discrete devices. In the payments space, a secure trusted device could be a secure card reader and the untrusted device could be a user input device such as a smartphone or tablet with a touch screen or a dedicate keypad. In specific approaches, sensitive data is received on the untrusted device, and the data is secured on the untrusted device, but the untrusted device is not allowed to access any encryption keys held by the trusted device or any affiliated trusted element of the system.

Instead of delivering a key to an untrusted device, a secure device could instead locally conduct a procedure on a key to generate instructions that allow the untrusted device to perform either an encryption or a decryption in accordance with the key, without being able to reconstruct the key from those instructions. The instructions could then be delivered to the untrusted device and executed thereon to effectively allow the untrusted device to encrypt data in accordance with the key's encryption protocol without ever actually having access to the key itself or exposing the key values in the memory of the untrusted device. The instructions could be in the form of executable code. The instructions generated by the secure device can use certain techniques to thwart any attempt to extract the key via an analysis of the instructions.

The process of generating the instructions described above, and using it for purposes of either encryption or decryption on an untrusted device, is referred to as white box cryptography. The term âwhite boxâ is meant to refer to the fact that a system designer has no guarantee that an attacker will not be able to âlook insideâ the untrusted device while it is encrypting data and thereby extract the key used for that encryption. A module capable of generating either the encryption or decryption instructions from a cryptographic key can be referred to as a white box code generator. As used herein, the term âmoduleâ refers to both instructions stored on a non-transitory computer readable memory that are executable by a processor for purposes of instantiating a software object, and the software object itself.

FIG. 2 includes a basic block diagram 200 and flow chart 210 to illustrate approaches in which white box code is generated on a trusted device for purposes of conducting an encryption of data on an untrusted device. In block diagram 200 , a trusted device 201 includes a secure memory 202 and a secure processor 203 , while an untrusted device 204 includes a standard processor 205 and a user interface 206 . Secure memory 202 and secure processor 203 could be integrated on the same chip or could be separate elements, and could also both be located under a tamper mesh within trusted device 201 . Standard processor 205 could be any standard microcontroller or microprocessor. User interface 206 could be any means for receiving data from a user including a camera, touch screen, key pad, microphone, or any other system for receiving data from a user. User interface 206 could provide input data to a temporary working memory on device 204 and encrypted using standard processor 205 according to the procedure of flow chart 210 .

The steps of flow chart 210 include generating white box encryption code on a first device and using the code to encrypt sensitive data on another device. Certain benefits accrue to generating the white box encryption instructions locally on the secure device instead of providing them via a server. White box encryption instructions and their complete data representations can exceed 1 mebibyte in size. Since white box cryptography results in fairly large key sizes, generating the instructions on a server and then transmitting the keys to a local memory can be untenable from a network usage and individual transaction delay perspective.

Flow chart 210 includes a step 211 of storing, in a secure memory on a first device, such as secure device 201 , a key. The key could be a strong cryptographic key used for either symmetric or asymmetric encryption in accordance with a key protocol. The secure memory could be tamper resistant such that the key would be erased upon the device losing power or detecting a tamper. The secure memory, or at least a portion of the secure memory dedicated to storing the key, could be volatile memory.

Flow chart 210 also includes a step 212 of generating, using a white box encryption generator on a first device, such as secure device 201 , a set of white box encryption instructions based on the key. Step 212 can be configured to generate different white box encryption instructions for the same key based off a random input to the generation process. The random input could be a random configuration parameter of secure device 201 . The white box encryption instructions could be provided in the form of a code using a source code that can be interpreted, compiled, and executed on a second device, such as device 204 . Flow chart 210 also includes a step 213 of transmitting the white box encryption instructions from the first device to the second device. The instructions can be transmitted across a secure communication channel between the secure device and the untrusted device. The first device could be secure device 201 and the second device could be device 204 .

Flow chart 210 also includes a step 214 in which sensitive data is received on a user interface of the second device. The second device could be device 204 and the user interface could be user interface 206 . In the situation where <figure-callout id="206" label="user interface" filenames="US11615411-20230328-D00000.png,US11615411-20230

CROSS REFERENCE TO RELATED APPLICATIONS

BACKGROUND

SUMMARY

Flow chart 210 also includes a step 214 in which sensitive data is received on a user interface of the second device. The second device could be device 204 and the user interface could be user interface 206 . In the situation where user interface 206 is a touch screen, the data could be stored as touch coordinates representative of the set of data, or as the sensitive data itself, in a working memory of device 204 . The sensitive data could then be, in accordance with step 215 , encrypted using the white box encryption instructions on the second device using a standard processor on the second device. The second device could be device 204 and the standard processor could be processor 205 . As a result, the sensitive data received from user interface 206 will not be exposed for any appreciable duration of time on device 204 before it is encrypted, and processor 205 will never be in possession of the cryptographic key as it remains securely stored on secure device 201 . The sensitive data can also be received on a secure portion of device 204 and securely encrypted before being transferred out of the secure portion.

Using some of the approaches represented by FIG. 2 , executable code is transmitted from a secure device to an untrusted device for execution on the untrusted device. However, pushing executable code to a device is often subject to restrictions, and is sometimes outright prohibited. In some cases, distributing code to the untrusted device may require the involvement of a third party. For example, pushing code to an Android or iOS smartphone generally requires the code to be filtered through an applications store. The third-party process is out of the control of the system administrator responsible for assuring communication between the secure device and untrusted device. As a result, there is no guarantee that communication between the two devices will not be held up for an unacceptable period while executable code, such as the white box encryption instructions transmitted in step 213 , are sent to the untrusted device. In certain approaches, a different key may be required every time the untrusted device encrypts or decrypts a new set of sensitive data. As a result, the time spent by the third party to review the executable code destined for the untrusted device would be required for each communication between the devices and result in an unacceptably long delay. Furthermore, in some approaches, a different key is required based on which user is operating the secure device. This would require each person downloading the application to their smartphone to be provided with a specific version of the application which would likewise be untenable and difficult to administrate. Furthermore, in some approaches, the general method used in step 212 can be updated independently of the application on the phone. The updates reduce the burden associated with updating the white box techniques to protect against a newly discovered attack.

To address restrictions on providing executable code to the untrusted device, the instructions that implement the functionality of the key can be translated into data in a specific format that is amenable to use by a specialized module on the untrusted device. As a result, there is no need to transfer executable code from the secure device to the untrusted device and there is no need to push code through a third-party system. Numerous variations of the process for generating the executable code, translating the code back into data, and utilizing the data for an encryption or decryption are disclosed herein. Regardless of the approach used, the data will be a complete description of the executable code, but at the same time is not Turing complete, and does not contain instructions that can be executed by the untrusted device. In short, the data will enable a specialized module on the untrusted device to execute the same white box encryption as the executable code, while not itself being usable for general purpose computing.

FIG. 3 includes a basic block diagram 300 and flow chart 310 to illustrate approaches in which a complete data representation of white box code is generated on a trusted device for purposes of conducting an encryption of data on an untrusted device. Flow chart 310 is distinguishable from flow chart 210 due to the addition of a step 311 in which a secure processor on the first device is used to generate a complete data representation of the set of white box encryption instructions generated in step 212 . The secure processor could be secure processor 203 on secure device 201 . The secure processor could instantiate a data representation generator for purposes of executing step 311 .

The complete data representation can be transferred to the untrusted device and used to encrypt the sensitive data thereon. The complete data representation contains all the data necessary for a specialized module on the untrusted device to execute the white box encryption. The complete data representation can include a set of primitives from a library of primitives and a collection of data structures referenced by those primitives. The complete data representation can include a collection of lookup tables and a directed graph. The complete data representation will not be amenable to general purpose computing and can exist in memory exclusive of any executable instructions from the perspective of the untrusted device. Flow chart 310 also includes a step 312 of transmitting the complete data representation from the first device to a second device. The representation can be transmitted across a secure communication channel between the first device and the second device. Flow chart 310 also includes a step 315 of encrypting the sensitive data using a standard processor on the second device. The standard processor could be processor 205 on second device 204 . Step 315 could involve a specialized module on the second device parsing the complete data representation to determine the steps necessary to encrypt the sensitive data in accordance with the key protocol. The specialized module could be a virtual machine instantiated using the standard processor. The complete data representation could thereby be parsed by the specialized module, while at the same time not being Turing complete with respect to the untrusted device and standard processor.

A disclosed method includes storing a key in a secure memory on a first device, receiving sensitive data via a user interface on a second device, generating a set of white box encryption instructions based on the key using a white box encryption generator on the first device, generating a complete data representation of the set of white box encryption instructions using a secure processor on the first device, transmitting the complete data representation from the first device to the second device, and encrypting the sensitive data using the complete data representation on the second device. The complete data representation is not executable.

A disclosed system includes a secure device with a secure processor and a secure memory, an unsecure device with a standard processor, a secure communication channel between the secure device and the unsecure device, a key stored in the secure memory, a white box encryption instruction generator: (i) instantiated by the secure processor; and (ii) programmed to generate a set of white box encryption instructions using the key, a data representation generator: (i) instantiated by the secure processor; and (ii) programmed to generate a complete data representation of the set of white box encryption instructions using the set of white box encryption instructions, and a virtual machine: (i) instantiated by the standard processor; and (ii) programmed to encrypt sensitive data using the complete data representation.

Another disclosed system includes an untrusted device with a user interface to receive sensitive data, a processor on the untrusted device, an operating system instantiated on the untrusted device by the processor, a secure card reader device, a wireless communication channel between the untrusted device and the secure card reader device, and a key stored in the secure card reader device. A memory on the secure card reader device stores instructions to: generate a set of white box encryption instructions using the key and generate a complete data representation of the white box encryption instructions. The system also includes an application instantiated on the untrusted device and programmed to encrypt the sensitive data using the complete data representation. The complete data representation does not include executable code for the operating system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates two examples of how a secure card reader can be paired with a smartphone to process payments.

FIG. 2 illustrates a block diagram and flow chart to illustrate approaches in which white box code is generated on a trusted device for purposes of conducting an encryption of data on an untrusted device in accordance with approaches disclosed herein.

FIG. 3 illustrates a block diagram and flow chart to illustrate approaches in which a complete data representation of a white box code instruction set is generated on a trusted device for purposes of conducting an encryption of data on an untrusted device in accordance with approaches disclosed herein.

FIG. 4 illustrates a data flow diagram of a secure card reader communicating with a smartphone for purposes of securely obtaining and transmitting both a personal account number (PAN) and a personal identification number (PIN) associated with a payment card to a payment processor server in accordance with approaches disclosed herein.

FIG. 5 illustrates a data flow diagram of a simplified version of the key rounds involved in a symmetric block cipher used to describe the approaches disclosed herein.

FIG. 6 illustrates two data flow diagrams for the decomposition of the symmetric block cipher in FIG. 5 into a set of lookup tables in accordance with approaches disclosed herein.

FIG. 7 illustrates two data flow diagrams to describe the translation of the key rounds involved in a symmetric block cipher into a set of lookup tables and a directed graph in accordance with the approaches disclosed herein.

FIG. 8 illustrates a conceptual diagram of, and a corresponding set of primitives in, a complete data representation of a set of white box encryption instructions in accordance with the approaches disclosed herein.

DETAILED DESCRIPTION

Systems and methods involving both a secure trusted and an untrusted device in which sensitive data or keys are shared between those devices are disclosed herein. The specific instance of the secure trusted device being a secure card reader and the untrusted device being a user interface device, such as a smartphone, is used for the sake of explanation. However, the concepts disclosed herein are more broadly applicable. A secure card reader can be manufactured by a payment device manufacturer to operate as a specialized trusted payments device. The secure card reader can include a secret key for encrypting payment information for delivery to a payments processor with whom the payment device manufacturer has an arrangement for payment processing. The secure card reader can also include a key used t generate white box encryption instructions for the untrusted device. An untrusted device can be an arbitrary smartphone, or other user interface device, with a specialized application installed for conducting some of the methods disclosed herein. The specialized application can be designed by the payment device manufacturer and distributed to smartphones by a third-party distribution system such as the Android or iOS application stores. Although this disclosure uses the specific environment of a secure card reader and smartphone as a vehicle for explanatory purposes, the approaches disclosed herein are more widely applicable to the communication or encryption of sensitive data in a system that includes untrusted devices generally, and they are not limited to payments technology.

FIG. 4 is a data flow diagram illustrating a secure card reader 400 communicating with a smartphone 410 for purposes of securely obtaining and transmitting both a personal account number (PAN) and a personal identification number (PIN) associated with a payment card 420 to a payment processor server 430 . Transmission of both the PIN and PAN to payment processor server 430 can be conducted using a secret key 401 stored in a secure memory on secure card reader 400 . The secret key can be referred to as a back-end key from a payment processing network. The secret key can be generated by a derived unique key per transaction (DUKPT) key set as provided by the payments processor that operates server 430 . The PIN can be securely transferred from smartphone 410 to secure card reader 400 , for further transmission on to payment processor server 430 using another key such as local encryption key 402 .

Local encryption key 402 can be a symmetric or asymmetric encryption key. Local encryption key 402 can be a public key associated with a public key certificate that is stored in a secure memory on secure card reader 400 which is either injected into the secure card reader in a key injection room in a manufacturing facility or injected into the secure card reader using a remote key injection (RKI) procedure. Local encryption key 402 can be used as part of a white box encryption protocol to facilitate secure communication with smartphone 410 without delivering local encryption key 402 itself to smartphone 410 . White box encryption conducted on smartphone 410 can use any number of encryption protocols or techniques. In particular, secure card reader 400 can generate, and smartphone 410 can use, white box instructions that implement the AES block cipher to encrypt the PIN in a format defined under the ISO 9564-1 (âPIN Blockâ) format. The ISO 9564-1 format may be used to encrypt both the PIN and the PAN to generate the PIN block. However, in certain approaches, it is beneficial to not transfer the PAN from secure card reader 400 unless it is encrypted with secret key 401 . As such, a random number generated on secure card reader 400 could be used in place of the PAN when generating the white box instructions. The random number would be stored by secure card reader 400 in association with, or as part of, local encryption key 402 so that it could be used to decrypt the PIN. The random number could be changed each time a set of white box instructions were generated by secure card reader 400 .

Secure card reader 400 is manufactured by a payment device manufacturer and includes certain security features such as a secure storage and execution environment with a secure processor and memory, tamper sensors, and tamper meshes for keeping encryption keys and sensitive payment data secure and isolated form attackers. Secure card reader 400 is a trusted device from the perspective of both the manufacturer of secure card reader 400 and the operator of payment processor server 430 as secure card reader 400 will meet certain standards required by that operator. For example, secure card reader 400 may be a payment card industry (PCI) compliant reader.

Secure card reader 400 can include means for receiving payment data from payment card 420 such as a magnetic stripe reader, chip reader, or an antenna for contactless cards. Smartphone 410 can include some of the above-mentioned security features as well, but is not required to include such features. Smartphone 410 can include a general processor and a user interface, such as a touch screen 411 , for receiving additional payment information from a user. In a specific approach, secure card reader 400 will obtain a PAN from payment card 420 and smartphone 410 will obtain a PIN from a holder of payment card 420 using touch screen 411 and a touch screen controller 412 . The smartphone could include a secure mode to prevent touch data from being used to determine the PIN. Using the following approach, the PIN can then be encrypted by local encryption key 402 , securely transferred to secure card reader 400 from smartphone 410 , and then encrypted using secret key 401 for transmission to payment processor server 430 .

Communication between secure card reader 400 and smartphone 410 can be conducted using a wired or wireless connection. In some approaches, smartphone 410 will provide power to secure card reader 400 using a wired connection, and communicate with secure card reader 400 using a wireless connection. In certain approaches, the wired connection will be provided via a micro-USB or similar interface. In certain approaches, the wired connection will be provided via a 3.5 or 2.5 mm jack that is otherwise used for stereo sound output or microphone input. The wireless connection can be conducted using any wireless protocol such as Bluetooth, Bluetooth Low Energy (BLE), Z-Wave, ZigBee, IrDA, or similar protocols. The data sent over the connection between secure card reader 400 and smartphone 410 can be encrypted and can be protected with cryptologic signatures.

FIG. 4 is illustrative of a class of systems in which a secure device includes encryption keys that cannot be used or stored outside of a trusted environment. The trusted environment could be one in which trust is measured from the perspective of the operator of payments processing server 430 and is set by an industry standard such as the PCI standards. Accordingly, both secret key 401 and local encryption key 402 cannot be stored, even temporarily, outside of the trusted environment. Secure communication between secure card reader 400 and smartphone 410 is therefore conducted without transferring local encryption key 402 to smartphone 410 . Furthermore, communication over a larger network than that set by the two discrete devices shown in FIG. 4 requires use of the secret key 401 , which is a stronger and more resource hungry encryption key than local encryption key 402 , and is intended to be secure enough to transfer payment data over a large network such as the Internet. As shown in the diagram, secure card reader 400 can leverage the large area network communication capabilities of the smartphone 410 to communicate with payments processing server 430 , or it can communicate directly with the server. The route taken by the encrypted payment information can depend on the capabilities of device 400 , the battery available on device 400 , or the relative strength of the network connection between the two devices. For example, device 400 could be designed to be low cost such that it only had local communication capabilities such as a modem for Bluetooth communications, while device 410 was a fully equipped smartphone with the ability to communicate via the Internet.

Although local encryption key 402 is never transferred from secure card reader 400 to smartphone 410 , communications from the smartphone 410 to the secure card reader 400 can be conducted over a secure channel as secured by the encryption protocol of local encryption key 402 using white box encryption. As illustrated, secure card reader 400 can use local encryption key 402 as the input to white box encryption generator 403 to generate a set of executable instructions that can be used to implement the encryption protocol of local encryption key 402 without being capable of revealing the key itself. White box encryption generator 403 can be a module instantiated on secure card reader 400 using a secure processor and memory.

White box encryption generator 403 can obfuscate the generated instructions to prevent an attacker from reconstructing the key using the instructions. For example, the instructions could include a set of lookup tables and the values in the tables could be used along with algebraic reconstruction techniques, that use the key values as unknowns, to solve for the key values based on the table values. However, obfuscation techniques could be used to thwart algebraic reconstruction. The obfuscation could utilize random configuration data 404 generated or previously stored within the secure area of secure card reader 400 to assure that the obfuscation could not be reverse engineered even if the exact approach was known. Configuration data 404 could be stored in a manner such that it would not be discoverable from outside the device without triggering a tamper event and thereby result in the keys on the device being erased, and additionally registered as compromised.

White box encryption can be conducted on smartphone 410 using the executable code generated by white box encryption generator 403 directly. The executable code can be transmitted from secure card reader 400 to smartphone 410 and executed by a processor on smartphone 410 using the sensitive data. The process can be conducted in a secure portion of smartphone 410 and may be conducted while the device is in a secure mode. However, there may be restrictions or prohibitions on pushing executable code to smartphone 410 . For example, code that needs to be pushed to smartphone 410 may need to be transferred through a third-party channel over which the manufacture of secure card reader 400 does not have control. In these approaches, the executable code could be translated into a data representation using a data representation generator, such as data representation generator 405 , prior to being transferred to smartphone 410 .

Data representation generator 405 may be a m

CLAIMS

Claims ( 20 )

What is claimed is:

1. Non-transitory computer readable media storing instructions which, when executed by one or more processors, cause the processors to execute a method, the method comprising:

storing, in a secure memory on a first device, a key;

generating, using a secure processor on the first device, a complete data representation of a set of white box encryption instructions, wherein the set of white box encryption instructions corresponds with the key;

transmitting the complete data representation from the first device to a second device;

receiving, via a user interface on the second device, sensitive data; and

encrypting, using a standard processor on the second device, the sensitive data using the complete data representation.

2. The computer readable media of claim 1 , wherein:

the second device is a touch display device; and

after the encrypting of the sensitive data, the sensitive data is an encrypted personal identification number.

3. The computer readable media of claim 2 , wherein the method further comprises:

forming a secure wireless connection between the first device and the touch display device;

wherein the transmitting of the complete data representation from the first device to the touch display device is conducted using the secure wireless connection; and

wherein the first device is a secure card reader.

4. The computer readable media of claim 3 , wherein the method further comprises:

deriving, using the secure processor on the secure card reader, the key using a random key generator and random configuration data on the first device;

transmitting, using the secure wireless connection, the encrypted personal identification number from the touch display device to the secure card reader;

re-encrypting, using the secure processor on the secure card reader, the personal identification number using a secret key; and

transmitting the re-encrypted personal identification number to a payment processor;

wherein the user interface is a touch screen.

5. The computer readable media of claim 4 , wherein the method further comprises:

receiving, using the secure card reader, a personal account number from a card;

encrypting, using the secure processor on the secure card reader, the personal account number using the secret key; and

transmitting the encrypted personal account number to the payment processor;

wherein the secret key is a derived unique key per transaction (DUKPT) key.

6. The computer readable media of claim 1 , wherein generating the complete data representation comprises:

generating a set of lookup tables using the key;

obfuscating, using an obfuscation module on the first device, the set of lookup tables with bijective mixing encodings to produce a set of obfuscated lookup tables; and

generating a directed graph and a set of primitive functions, wherein the set of primitive functions include data which fully describes the set of obfuscated lookup tables.

7. The computer readable media of claim 6 , wherein the method further comprises:

instantiating, using the standard processor on the second device, a virtual machine;

parsing, using the standard processor on the second device, the directed graph and the set of primitive functions from the complete data representation;

applying, using the standard processor on the second device, the sensitive data to the set of primitive functions in accordance with the directed graph;

updating the obfuscation module on the first device to an updated obfuscation module;

generating, using the secure processor and the updated obfuscation module on the first device, a second complete data representation of a second set of white box encryption instructions;

transmitting the second complete data representation from the first device to the second device; and

encrypting, using the virtual machine, a second set of sensitive data using the second complete data representation.

8. The computer readable media of claim 1 , wherein the method further comprises:

generating, on the first device, the key;

receiving, via the user interface on the second device, additional sets of sensitive data; and

generating, on the first device, a set of new keys; and

wherein each key in the set of new keys is uniquely generated in a one-to-one correspondence for each set of sensitive data in additional sets of sensitive data.

9. The computer readable media of claim 1 , wherein the method further comprises:

parsing, using the standard processor on the second device, a directed graph and a set of primitive functions from the complete data representation; and

applying, using the standard processor on the second device, the sensitive data to the set of primitive functions in accordance with the directed graph.

10. The computer readable media of claim 9 , wherein a primitive function in the set of primitive functions includes:

a unique identifier;

an array of binary data representing a lookup table; and

a flag to indicate if the primitive function generates a final result in the directed graph.

11. The computer readable media of claim 9 , wherein the method further comprises:

instantiating, using the standard processor on the second device, a virtual machine;

wherein the parsing and applying are conducted by the virtual machine; and

wherein the complete data representation is not Turing complete with respect to the standard processor.

12. A system comprising:

a secure device with a secure processor and a secure memory;

an unsecure device with a standard processor;

a secure communication channel between the secure device and the unsecure device; and

a key stored in the secure memory;

wherein the secure processor is programmed to: (i) generate a complete data representation of a set of white box encryption instructions using the set of white box encryption instructions, wherein the set of white box encryption instructions corresponds with the key; and (ii) transmit the complete data representation to the unsecure device; and

wherein the standard processor is programmed to encrypt sensitive data using the complete data representation.

13. The system of claim 12 , further comprising:

a touch screen on the unsecure device;

wherein the secure communication channel is a wireless communication channel;

wherein the secure device is a secure card reader device;

wherein the unsecure device is a touch display device; and

wherein the sensitive data is a personal identification number received via the touch screen.

14. The system of claim 12 , further comprising:

a secret key stored in the secure memory; and

a secure server programmed to decrypt the sensitive data using the secret key;

wherein the unsecure device is programmed to transmit the encrypted sensitive data to the secure device;

wherein the secure device is programmed to: (i) decrypt the encrypted sensitive data from the unsecure device using the key; and (ii) re-encrypt the sensitive data using the secret key; and

wherein the secret key is a derived unique key per transaction (DUKPT) key.

15. The system of claim 12 , further comprising:

a touch screen on the unsecure device that is programmed to receive the sensitive data;

a card reader on the secure device that is programmed to receive a personal account number from a card; and

a secure server;

wherein the sensitive data is a personal identification number;

wherein the personal account number and the personal identification number are transmitted to the secure server from the secure device; and

wherein the personal account number and the personal identification number are used by the secure server to process a payment.

16. The system of claim 12 , wherein:

the complete data representation is not executable by an operating system of the unsecure device; and

the complete data representation is not Turing complete.

17. The system of claim 12 , wherein the complete data representation is generated by:

generating a set of lookup tables using the key;

obfuscating, using an obfuscation module on the secure device, the set of lookup tables with bijective mixing encodings to produce a set of obfuscated lookup tables; and

generating a directed graph and a set of primitive functions, wherein the set of primitive functions include data which fully describes the set of obfuscated lookup tables.

18. The system of claim 12 , wherein the sensitive data is encrypted by:

parsing, using the standard processor on the unsecure device, a directed graph and a set of primitive functions from the complete data representation; and

applying, using the standard processor on the unsecure device, the sensitive data to the set of primitive functions in accordance with the directed graph.

19. A system comprising:

a first device with a user interface to receive sensitive data;

a secure device;

a wireless communication channel between the first device and the secure device;

a key stored in the secure device;

one or more computer readable media on the secure device storing instructions to:

generate a data representation of white box encryption instructions which correspond with the key; and

transmit the data representation to the first device; and

wherein the first device is programmed to encrypt the sensitive data using the data representation.

20. The system of claim 19 , wherein the secure device is programmed to generate the data representation by:

generating a set of lookup tables using the key;

obfuscating, using an obfuscation module on the secure device, the set of lookup tables with bijective mixing encodings to produce a set of obfuscated lookup tables; and

generating a directed graph and a set of primitive functions, wherein the set of primitive functions include data which fully describes the set of obfuscated lookup tables.

US17/079,252

2017-12-15

2020-10-23

POS system with white box encryption key sharing

Active

2038-11-22

US11615411B2

( en )

Priority Applications (1)

Application Number

Priority Date

Filing Date

Title

US17/079,252

US11615411B2

( en )

2017-12-15

2020-10-23

POS system with white box encryption key sharing

Applications Claiming Priority (3)

Application Number

Priority Date

Filing Date

Title

US15/843,264

US10140612B1

( en )

2017-12-15

POS system with white box encryption key sharing

US16/169,351

US10909532B2

( en )

2017-12-15

2018-10-24

POS system with white box encryption key sharing

US17/079,252

US11615411B2

( en )

2017-12-15

2020-10-23

POS system with white box encryption key sharing

Related Parent Applications (1)

Application Number

Title

Priority Date

Filing Date

US16/169,351

Continuation

US10909532B2

( en )

2017-12-15

2018-10-24

POS system with white box encryption key sharing

Publications (2)

Publication Number

Publication Date

US20210056546A1

US20210056546A1 ( en )

2021-02-25

US11615411B2

true

US11615411B2 ( en )

2023-03-28

Family

ID=64315478

Family Applications (3)

Application Number

Title

Priority Date

Filing Date

US15/843,264

Active

US10140612B1

( en )

2017-12-15

POS system with white box encryption key sharing

US16/169,351

Active

2038-07-28

US10909532B2

( en )

2017-12-15

2018-10-24

POS system with white box encryption key sharing

US17/079,252

Active

2038-11-22

US11615411B2

( en )

2017-12-15

2020-10-23

POS system with white box encryption key sharing

Family Applications Before (2)

Application Number

Title

Priority Date

Filing Date

US15/843,264

Active

US10140612B1

( en )

2017-12-15

POS system with white box encryption key sharing

US16/169,351

Active

2038-07-28

US10909532B2

( en )

2017-12-15

2018-10-24

POS system with white box encryption key sharing

Country Status (5)

Country

Link

( 3 )

US10140612B1

( en )

( 1 )

EP3499444A1

( en )

( 2 )

AU2018200866A1

( en )

( 1 )

BR102018015221B8

( en )

( 1 )

CA2993748C

( en )

Families Citing this family (22)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US10546302B2

( en )

2016-06-30

2020-01-28

Square, Inc.

Logical validation of devices against fraud and tampering

US20180187335A1

( en )

2017-01-01

2018-07-05

Lummus Corporation

Materials segregating seed cotton extractor cleaner

US10438198B1

( en )

2017-05-19

2019-10-08

Wells Fargo Bank, N.A.

Derived unique token per transaction

US10715536B2

( en )

2017-12-29

2020-07-14

Square, Inc.

Logical validation of devices against fraud and tampering

US10693662B2

( en )

2018-02-22

2020-06-23

Idlogiq Inc.

Methods for secure serialization of supply chain product units

US10833849B2

( en )

2018-03-21

2020-11-10

Clover Network, Inc.

Unified secure device provisioning

US11362824B2

( en )

2018-05-25

2022-06-14

Intertrust Technologies Corporation

Content management systems and methods using proxy reencryption

US11206130B2

( en )

2018-07-31

2021-12-21

Nxp B.V.

Customizing cryptographic keys between multiple hosts

US11507958B1

( en )

2018-09-26

2022-11-22

Block, Inc.

Trust-based security for transaction payments

US11494762B1

( en )

2018-09-26

2022-11-08

Block, Inc.

Device driver for contactless payments

US11429753B2

( en )

2018-09-27

2022-08-30

Citrix Systems, Inc.

Encryption of keyboard data to avoid being read by endpoint-hosted keylogger applications

CN109688584B

( en )

2018-12-27

2022-04-08

ç»å´å¿è¶ç§ææéå¬å¸

Data security storage system and method suitable for resource-limited network node

US11212090B1

( en )

2019-02-27

2021-12-28

Wells Fargo Bank, N.A.

Derived unique random key per transaction

TR201905756A2

( en )

2019-04-18

2019-05-21

Kartek Kart Ve Bilisim Teknolojileri Ticaret Anonim Sirketi

Software security system and method for PIN entry, storage and transmission to software-based POS (SoftPOS).

US10726681B1

( en )

2019-07-26

2020-07-28

Clover Network, Inc.

Advanced hardware system for self service checkout kiosk

JP7383949B2

( en )

2019-09-20

2023-11-21

å¯å£«é»æ©æ ªå¼ä¼ç¤¾

Information processing equipment and programs

CN110602138B

( en )

2019-09-26

2021-06-11

è¾è®¯ç§æï¼æ·±å³ï¼æéå¬å¸

Data processing method and device for block chain network, electronic equipment and storage medium

US11456855B2

( en )

2019-10-17

2022-09-27

Arm Limited

Obfuscating data at-transit

FR3103591A1

( en )

2019-11-22

2021-05-28

Orange

Secure data exchange process between a terminal and a server

JP7468687B2

( en )

2020-10-16

2024-04-16

æ¥æ¬é»ä¿¡é»è©±æ ªå¼ä¼ç¤¾

Secure computation system, secure computation device, secure computation method, and program

FR3144464A1

( en )

2022-12-22

2024-06-28

Banks And Acquirers International Holding

Method for securing data transmission, and corresponding system.

CN118677666B

( en )

2024-06-14

2025-03-28

ååç§æè¡ä»½æéå¬å¸

Data security transmission method, device, equipment and storage medium

Citations (23)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20050021989A1

( en )

2001-07-30

2005-01-27

Johnson Harold J.

Secure method and system for handling and distributing digital media

US20050039025A1

( en )

2003-07-22

2005-02-17

Alexander Main

Software conditional access system

US20070086586A1

( en )

2005-10-14

2007-04-19

Microsoft Corporation

Semi-public white-box cipher

US20080017712A1

( en )

2006-01-13

2008-01-24

Hart Annemarie D

Secure magnetic stripe reader

US20100189263A1

( en )

2008-11-05

2010-07-29

Mustang Microsystems, Inc.

Method and apparatus for generating and updating security codes

US20100296649A1

( en )

2007-09-13

2010-11-25

Irdeto B.V.

Cryptographic processing of content

US7971788B2

( en )

2001-05-31

2011-07-05

Gemalto Sa

Electronic payment terminal, smart card adapted to such a terminal and method for loading a secret key in such a terminal

US20120042170A1

( en )

2010-02-19

2012-02-16

Irdeto Corporate B.V.

Device and method for establishing secure trust key

US20140324708A1

( en )

2012-06-12

2014-10-30

Square, Inc.

Raw sensor input encryption for passcode entry security

US20140380311A1

( en )

2012-01-09

2014-12-25

Koninklijke Philips N.V.

Virtual machine device having key driven obfuscation and method

US20150154595A1

( en )

2013-12-02

2015-06-04

Mastercard International Incorporated

Method and system for secure authentication of user and mobile device without secure elements

US20150215117A1

( en )

2014-01-29

2015-07-30

Electronics And Telecommunications Research Insitute

White box encryption apparatus and method

US20150270951A1

( en )

2014-03-20

2015-09-24

Nxp B.V.

Security module for secure function execution on untrusted platform

US20160065370A1

( en )

2014-08-29

2016-03-03

Eric Le Saint

Methods for secure cryptogram generation

US20160261405A1

( en )

2015-03-04

2016-09-08

Apple Inc.

Computing key-schedules of the aes for use in white boxes

US20170180119A1

( en )

2015-12-16

2017-06-22

Nxp B.V.

Wide encoding of intermediate values within a white-box implementation

US20170195117A1

( en )

2014-09-18

2017-07-06

Huawei International Pte. Ltd.

Encryption function and decryption function generating method, encryption and decryption method and related apparatuses

EP3226164A1

( en )

2016-03-30

2017-10-04

Nxp B.V.

Watermarking input and output of a white-box implementation

US20170294148A1

( en )

2016-04-08

2017-10-12

Sony Corporation

Encryption device, encryption method, decryption device, and decryption method

US20170346629A1

( en )

2016-05-27

2017-11-30

Samsung Sds Co., Ltd.

Apparatus and method for public key encryption

US20180137272A1

( en )

2016-11-14

2018-05-17

Mastercard International Incorporated

Methods for securely storing sensitive data on mobile device

US20180219680A1

( en )

2017-02-02

2018-08-02

Mastercard International Incorporated

Methods and systems for securely storing sensitive data on smart cards

US20190272162A1

( en )

2017-08-08

2019-09-05

Crypto4A Technologies Inc.

Secure machine executable code deployment and execution method and system

2017

2017-12-15

US15/843,264

patent/US10140612B1/en

active

Active

2018

2018-01-30

CA2993748A

patent/CA2993748C/en

active

Active

2018-02-06

AU2018200866A

patent/AU2018200866A1/en

not_active

Abandoned

2018-07-25

BR102018015221A

patent/BR102018015221B8/en

active

IP Right Grant

2018-10-24

US16/169,351

patent/US10909532B2/en

active

Active

2018-12-13

EP18212437.0A

patent/EP3499444A1/en

not_active

Withdrawn

2019

2019-11-27

AU2019271965A

patent/AU2019271965B2/en

active

Active

2020

2020-10-23

US17/079,252

patent/US11615411B2/en

active

Active

Patent Citations (23)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US7971788B2

( en )

2001-05-31

2011-07-05

Gemalto Sa

Electronic payment terminal, smart card adapted to such a terminal and method for loading a secret key in such a terminal

US20050021989A1

( en )

2001-07-30

2005-01-27

Johnson Harold J.

Secure method and system for handling and distributing digital media

US20050039025A1

( en )

2003-07-22

2005-02-17

Alexander Main

Software conditional access system

US20070086586A1

( en )

2005-10-14

2007-04-19

Microsoft Corporation

Semi-public white-box cipher

US20080017712A1

( en )

2006-01-13

2008-01-24

Hart Annemarie D

Secure magnetic stripe reader

US20100296649A1

( en )

2007-09-13

2010-11-25

Irdeto B.V.

Cryptographic processing of content

US20100189263A1

( en )

2008-11-05

2010-07-29

Mustang Microsystems, Inc.

Method and apparatus for generating and updating security codes

US20120042170A1

( en )

2010-02-19

2012-02-16

Irdeto Corporate B.V.

Device and method for establishing secure trust key

US20140380311A1

( en )

2012-01-09

2014-12-25

Koninklijke Philips N.V.

Virtual machine device having key driven obfuscation and method

US20140324708A1

( en )

2012-06-12

2014-10-30

Square, Inc.

Raw sensor input encryption for passcode entry security

US20150154595A1

( en )

2013-12-02

2015-06-04

Mastercard International Incorporated

Method and system for secure authentication of user and mobile device without secure elements

US20150215117A1

( en )

2014-01-29

2015-07-30

Electronics And Telecommunications Research Insitute

White box encryption apparatus and method

US20150270951A1

( en )

2014-03-20

2015-09-24

Nxp B.V.

Security module for secure function execution on untrusted platform

US20160065370A1

( en )

2014-08-29

2016-03-03

Eric Le Saint

Methods for secure cryptogram generation

US20170195117A1

( en )

2014-09-18

2017-07-06

Huawei International Pte. Ltd.

Encryption function and decryption function generating method, encryption and decryption method and related apparatuses

US20160261405A1

( en )

2015-03-04

2016-09-08

Apple Inc.

Computing key-schedules of the aes for use in white boxes

US20170180119A1

( en )

2015-12-16

2017-06-22

Nxp B.V.

Wide encoding of intermediate values within a white-box implementation

EP3226164A1

( en )

2016-03-30

2017-10-04

Nxp B.V.

Watermarking input and output of a white-box implementation

US20170294148A1

( en )

2016-04-08

2017-10-12

Sony Corporation

Encryption device, encryption method, decryption device, and decryption method

US20170346629A1

( en )

2016-05-27

2017-11-30

Samsung Sds Co., Ltd.

Apparatus and method for public key encryption

US20180137272A1

( en )

2016-11-14

2018-05-17

Mastercard International Incorporated

Methods for securely storing sensitive data on mobile device

US20180219680A1

( en )

2017-02-02

2018-08-02

Mastercard International Incorporated

Methods and systems for securely storing sensitive data on smart cards

US20190272162A1

( en )

2017-08-08

2019-09-05

Crypto4A Technologies Inc.

Secure machine executable code deployment and execution method and system

Non-Patent Citations (23)

* Cited by examiner, â Cited by third party

Title

A. Souchet, Spotlight on an Unprotected AES 128 White-Box Implementation, GitHub Blog, Diary of a Reverse-Engineer, (Available at: https://doar-e.github.io/blog/2015/02/08/spotlight-on-an-unprotected-aes128-whiteboximplementation/) (Posted: Feb. 8, 2015) (Accessed on: Apr. 24, 2018).

Bhatia et al. (" Study on White-Box Cryptography: Key Whitening and Entropy Attacks ", Dec. 8, 2016, pp. 323-327) (Year: 2016).

Billet et al., " Cryptanalysis of a White Box AES Implementation ", Springer-Verlag Berlin Heidelberg, 2005, pp. 227-240 (Year: 2005).

Chow et al. (A White-Box DES Implementation for DRM Applications, Springer-Verlag Berlin Heidelberg, 2003, pp. 1-15). (Year: 2003).

Chow et al. (White-Box Cryptography and an AES Implementation, Springer-Verlag Berlin Heidelberg, 2003, pp. 261-281) (Year: 2003).

European Search Report dated Apr. 16, 2019 from European Application No. 18212437.0, 10 pages.

Examination Report dated Dec. 3, 2020 from Australian Patent Application No. 2019271965, 5 pages.

Examination Report dated Jul. 23, 2019 from Australian Application No. 2018200866, 54pages.

Examination Report dated May 2, 2019 from Australian Application No. 2018200866, 5 pages.

First Examination Report dated Feb. 17, 2020 from European Application No. 18212437.0, 11 pages.

Gan et al. (" Using Virtual Machine Protections to Enhance Whitebox Cryptography ", 20151EEE/ACM 1st International Workshop on Software Protection, 2015, pp. 17-23) (Year: 2015).

Michiels et al., " Mechanism for Software Tamper Resistance: An Application of White-Box Cryptography ", DRM'07, Oct. 29, 2007, pp. 82-89 (Year: 2007).

Notice of Acceptance dated Apr. 14, 2021 from Australian Application No. 2019271965, 3 pages.

Notice of Allowance dated Jul. 11, 2018 for U.S. Appl. No. 15/843,264.

Notice of Allowance dated Oct. 8, 2019 from Brazilian Application No. BR102018015221, 3 pages.

Notice of Allowance dated Oct. 8, 2019, Brazilian Application No. BR102018015221-1, 3 pages.

Notice of Allowance dated Sep. 15, 2020 from U.S. Appl. No. 16/169,351, 118 pages.

Office Action dated Mar. 7, 2018 for U.S. Appl. No. 15/843,264.

Su et al., " A White-Box CLEFIA implementation for mobile devices ", Sep. 2014, 8 pages, (Year: 2014).

Summons to Attend Oral Proceedings dated Oct. 7, 2020 from European Patent Application No. 18212437.0, 14 pages.

Wyseur, White-Box Cryptography: Hiding Keys in Software, Feb. 2012, 8 pages (Year: 2012).

Xiao et al., " A Secure Implementation of White-Box AES ", IEEE, 2009, 6 pages (Year: 2009).

Yoo et al., " A Method for Secure and Efficient Block Cipher using White-Box Cryptography ", ICUIMC'12, Feb. 20-22, 2012, 8 pages (Year: 2012).

Also Published As

Publication number

Publication date

US20190188703A1

( en )

2019-06-20

US10909532B2

( en )

2021-02-02

BR102018015221B1

( en )

2019-12-24

BR102018015221A2

( en )

2019-02-12

AU2019271965A1

( en )

2019-12-19

CA2993748C

( en )

2024-02-13

AU2019271965B2

( en )

2021-04-29

US20210056546A1

( en )

2021-02-25

US10140612B1

( en )

2018-11-27

CA2993748A1

( en )

2019-06-15

EP3499444A1

( en )

2019-06-19

AU2018200866A1

( en )

2019-07-04

BR102018015221B8

( en )

2022-06-28

POS system with white box encryption key sharing — Clover Network, Llc. (US11615411B2)

Analyze & explore related research in Conceptio

Related documents