Systems and methods for white-box device binding

Abstract

A method is disclosed. The method includes receiving, by a user device, an encrypted message from a server computer. The encrypted message is a message encrypted with a master secret key or a key derived from the master secret key. The user device signs the encrypted message with a secure element private key. The user device cryptographically recovers a secure element public key from an authenticated key using a whitebox using a server computer public key. The authenticated key is authenticated by the server computer and based on at least the secure element public key. The user device cryptographically recovers the encrypted message from the signed encrypted message using the whitebox using the secure element public key. The user device decrypts the encrypted message using the whitebox using the master secret key or the key derived from the master secret key in the whitebox to obtain the message.

Description

[0001] Cross-referencing related applications

[0002] This application is a PCT application of U.S. Provisional Application No. 63 / 027,208, filed on May 19, 2020, and claims priority thereto, which is incorporated herein by reference in its entirety for all purposes. Background Technology

[0003] Introducing white-box cryptography in the context of digital rights management (DRM) applications [4] [5]. In this context, the provider offers software programs that enable users to access specific content. The content may be issued by the provider in encrypted form, and the user's software is configured with a corresponding decryption key, enabling each user with the software program to decrypt the content. In this context, the decryption key corresponds to the content that the user has paid for (e.g., a streaming package that the user has purchased). It should be noted that many users often have software configured with the same decryption key because they have paid for the same content (e.g., the same package).

[0004] However, malicious users who have obtained the software, including the decryption key, can share the DRM application with other users. Furthermore, malicious users may attempt to create numerous copies of the software and sell them on the black market. To achieve this, malicious users might attempt to extract the decryption key from their program and then share that key with other users. Malicious users might also attempt to simply copy the complete software with the key embedded on it, thereby performing a code elevation attack. To achieve these goals, malicious users can examine the software code and collect input / output pairs. It should be noted that malicious users have complete control over the execution environment because the software runs on their own devices.

[0005] There are currently methods that make it difficult for malicious users to send their programs over the network (e.g., incompressibility [6]). In addition, current methods attempt to make white-box programs traceable. For example, by watermarking the program, the original owner of the program and their piracy attempt can be identified if a copy of the program is found (e.g., on the black market). Examples of leaker tracking schemes are given below: [3] [6].

[0006] However, such methods do not prevent malicious users from using code elevation attacks to copy code and / or keys.

[0007] The embodiments of this disclosure address this problem and other problems individually and collectively. Summary of the Invention

[0008] The embodiments relate to methods and systems for bonding white-box devices.

[0009] One embodiment of the present invention relates to a method comprising: receiving an encrypted message from a backend server computer by a user device, the encrypted message being a message encrypted by the backend server computer using a master secret key or a key derived from the master secret key; signing the encrypted message by the user device using a secure element using a secure element private key to obtain a signed encrypted message; recovering the secure element public key cryptographically by the user device using a white box using a backend server computer public key from an authenticated key, the authenticated key being authenticated by the backend server computer and at least based on the secure element public key, wherein the white box also stores the master secret key or a key derived from the master secret key; recovering the encrypted message cryptographically by the user device using the white box using the secure element public key from the signed encrypted message; and decrypting the encrypted message by the user device using the white box using the master secret key in the white box or a key derived from the master secret key to obtain the message.

[0010] Another embodiment of the present invention relates to a user device, comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to perform a method comprising: receiving an encrypted message from a back-end server computer, the encrypted message being a message encrypted by the back-end server computer using a master secret key or a key derived from the master secret key; signing the encrypted message using a secure element using a secure element private key to obtain a signed encrypted message; recovering the secure element public key cryptographically from an authenticated key using a white-box method using a back-end server computer public key, the authenticated key being authenticated by the back-end server computer; recovering the encrypted message cryptographically from the signed encrypted message using the secure element public key using a white-box method; and decrypting the encrypted message using a white-box method using the master secret key or a key derived from the master secret key to obtain the message.

[0011] Another embodiment of the present invention relates to a method comprising: receiving, by a backend server computer, a registration message including a security element public key from a user device, the user device having an application compiled by the backend server computer installed thereon; the backend server computer signing the security element public key using its private key to form an authenticated key; the backend server computer providing the authenticated key to the user device; the backend server computer obtaining a message including content to be provided to the application installed on the user device; the backend server computer encrypting the message using a master secret key or a key derived from the master secret key to obtain an encrypted message; and the backend server computer providing the encrypted message to the user device, wherein the user device uses a security element to sign the encrypted message using the security element private key to obtain a signed encrypted message, uses a white box in the application to cryptographically recover the security element public key from the authenticated key using the backend server computer public key, uses the white box to cryptographically recover the encrypted message from the signed encrypted message using the security element public key, and uses the white box to decrypt the encrypted message using the master secret key or a key derived from the master secret key to obtain the message.

[0012] More detailed information about embodiments of the present invention can be found in the detailed description and accompanying drawings. Attached Figure Description

[0013] Figure 1 A block diagram illustrating a white-box device bonding system according to an embodiment of the present invention is shown.

[0014] Figure 2 A block diagram illustrating a user device according to an embodiment of the present invention is shown.

[0015] Figure 3 The binding and secure message delivery process according to an embodiment of the present invention is illustrated.

[0016] Figure 4 The first part of a second process of an alternative binding and secure message delivery process according to an embodiment of the present invention is shown.

[0017] Figure 5 The second part of a second process of an alternative binding and secure messaging process according to an embodiment of the present invention is shown. Detailed Implementation

[0018] Before discussing the embodiments of this disclosure, some terms may be described in further detail.

[0019] "User" can include an individual. In some embodiments, a user can be associated with one or more personal accounts and / or mobile devices. In some embodiments, a user can also be referred to as a cardholder, account holder, or consumer.

[0020] A “user device” can be a device that can be operated by a user. Examples of user devices can include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (such as automobiles), simplified client devices, tablet PCs, and so on. Furthermore, a user device can be any type of wearable technology device, such as a watch, headphones, glasses, etc. A user device can include one or more processors capable of processing user input. A user device can also include one or more input sensors for receiving user input. As is known in the art, there are various input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. A user device can include any electronic device that can be operated by a user, and that can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (such as the Internet or a private network).

[0021] An "application" can be a computer program that can be used for a specific purpose. Applications are available from app stores. Applications can be installed on devices. Examples of applications include interactive applications, video streaming applications, data transfer applications, web access applications, social media applications, word processors, spreadsheet programs, web browsers, email clients, video games, photo editors, and so on.

[0022] A "white box" can include its internal, observable subsystems. A white box can be software included in an application. A white box can be viewed, but it is not easily modified.

[0023] A "public key" can include a publicly available cryptographic key. A public key can be obtained by anyone and used to encrypt messages intended for a specific recipient, making it possible to decode the encrypted message only by using a second key (e.g., a secret key) known only to the recipient. The public key can be used to verify signatures made using the secret key associated with it.

[0024] A "secret key" may include a cryptographic key that can be secretly used by the device. The secret key may be stored internally within a single device. The secret key may not be provided to other devices. The secret key can be used to decrypt encrypted messages that were encrypted using a public key associated with the secret key. The secret key can be used to sign messages, thereby forming a digital signature. The digital signature can be verified using the public key associated with the secret key.

[0025] The "master secret key" may include a symmetric cryptographic key. The master secret key can be used to create a secure communication channel between two devices that know (i.e., have stored) the master secret key.

[0026] A "secure element" can include secure hardware or software components. A secure element is protected against unauthorized access and can operate processes securely. A secure element can store confidential and password data. A secure element can be a tamper-proof hardware platform, such as a chip on a device. A secure element can be a tamper-proof software program, such as a virtual or emulated environment (e.g., Host Card Emulation (HCE)).

[0027] "Interaction" can include reciprocal effects or influences. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, etc. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate the payment.

[0028] "Interaction data" can include data related to the interaction and / or data recorded during the interaction. In some embodiments, interaction data can be transaction data of network data. Transaction data can include multiple data elements with data values.

[0029] A “password” can include obscure text, such as encrypted text. A password can be formed by encrypting input data using an encryption key, such as a symmetric encryption key. In some embodiments, the password is reversible, allowing the same symmetric key to be used to obtain the input used to form the password for decryption. In some embodiments, the password can also be a digital signature if the input data is encrypted using the private key of a public / private key pair. The digital signature can be verified using the public key of the public / private key pair. In some embodiments, the password can include a dynamic card verification value (dCVV).

[0030] In embodiments of the invention, the password can be generated in any suitable manner. In some embodiments, the password input may include data elements, including account identifiers, such as a master account, and variable data elements such as a counter, time of day, or interaction value. Such data can be included using encryption processes such as DES, Triple DES, or AES using any suitable encryption key. The encryption key may also be a uniquely derived key or UDK and may be generated based on device-specific information, such as an account, which can be encrypted using a master derived key (MDK). The password can be verified by another computer, such as a remote computer, by decrypting the password to its decrypted form and verifying the decrypted form with other data (e.g., the account number stored in a file), or by encrypting other input and comparing the encrypted result with the password.

[0031] A "resource provider" can be an entity that provides resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation departments, government entities, site and residential operators, etc.

[0032] The term "verification" and its derivatives can refer to the process of using information to determine whether a potential subject is valid under a given set of conditions. Verification can include any comparison of information to ensure that certain data or information is correct, valid, accurate, legitimate, and / or credible.

[0033] An "authorization request message" can be an electronic message requesting authorization for an interaction. In some embodiments, the message is sent to the transaction processing computer and / or the issuer of the payment card to request authorization for the transaction. According to some embodiments, the authorization request message may comply with International Organization for Standardization (ISO) 8583, a standard for systems that exchange information about electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by way of example only): service code, card verification value (CVV), dynamic card verification value (dCVV), primary account number or "account number" (PAN), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquiring bank identifier (BIN), card acceptor ID, information identifying the item being purchased, etc., and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0034] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or transaction processing computer. For example, an authorization response message may include one or more of the following status indicators: approved – the transaction is approved; rejected – the transaction is not approved; or call center – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or via the transaction processing computer). This code can serve as evidence of authorization.

[0035] "Authorizing entity" can be the entity requesting authorization. Instances of authorizing entities can be issuers, government agencies, document repositories, access administrators, etc. Authorizing entities can operate authorizing entity computers. "Issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. Issuers can also issue payment credentials stored on user devices, such as cellular phones, smart cards, tablets, or laptops, to consumers, or in some embodiments to portable devices.

[0036] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory may include non-transient computer-readable media whose storage contains instructions executable by a processor to implement a desired method. Instances of memory may include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0037] A “processor” can include means for performing a task. In some embodiments, a processor can include any suitable one or more data computing means. A processor can include one or more microprocessors that work together to perform a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor such as AMD’s Athlon, Duron, and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0038] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one instance, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0039] The embodiments of this disclosure provide white-box device binding for both digital rights management (DRM) applications and interactive applications. However, it should be understood that the embodiments provide white-box device binding for other types of applications.

[0040] White-box cryptography can be used in settings where security hardware may be limited and therefore most programs can be implemented in software. In such settings, device binding can be used to ensure that sensitive parts of a program cannot be copied and cannot run in other environments (e.g., as in code elevation attacks).

[0041] The embodiments allow for the efficient distribution of white-box applications. A trusted backend server computer can compile the white-box application (e.g., include the white-box application) once and distribute it through an app store. All users can download the same program, instead of the backend server computer needing to compile different applications for different users or user groups. However, each program needs to be configured to work only on a specific device to mitigate code elevation attacks. Depending on the application, each application may also need to use a different decryption key. For example, if the application is interactive, each user may need a different decryption key for the applications they have installed, making it impossible for one user to decrypt another user's content. The embodiments in this document demonstrate how this can be achieved using white-box cryptography and various obfuscation techniques.

[0042] Furthermore, for interactive applications, white-box cryptography can serve slightly different purposes than in DRM-based applications (e.g., video streaming applications). There are many different types of user devices (e.g., mobile phones) available to users. With this diversity, significant variations occur within the hardware. Many user devices have a secure element (SE), which can be used to perform sensitive cryptographic tasks. However, these SEs offer limited functionality and are not available on all phones. To support mobile interaction on phones without trusted hardware, “Host Card Emulation” (HCE) has been introduced. Implementations can be utilized regardless of the type of secure hardware and / or software included in the user device.

[0043] Mobile interactive HCE applications store user-related keys (e.g., limited-use keys (LUKs)). These keys are stored in encrypted form. Whenever a user wishes to perform an interaction, the user's device takes the encrypted LUK, decrypts it, and uses it to generate a password. The password is used to authenticate the user's device and allow the interaction to continue. Here, embodiments can ensure that only the user device holding these LUKs can decrypt them, and no other device can use them to perform interactions. White-box cryptography can be used to provide protection against adversaries (e.g., in the form of malware) who have compromised the user's device.

[0044] Malware can appear on a user's device without their knowledge. It may access program code that decrypts the limited-use key. Without further protection, an adversary could recover the decryption key and then decrypt the limited-use key. An adversary could also attempt to escalate the attack by simply copying the entire application with the encrypted limited-use key and running it on their own device. It should be noted that in the worst-case scenario, an adversary could gain root access to the user's device and potentially execute the user's interactive applications.

[0045] To mitigate the attacks described above, embodiments may use white-box cryptography to protect cryptographic keys, as well as secure elements that bind the application to the user's device. White-box cryptography prevents adversaries from simply reading the value of the decryption key, copying the entire application and running it on their chosen device, and / or compromising the confidentiality of the encrypted limited-use keys. It should be noted that the limited-use keys used in the embodiments are user-connected, and should be accessible to only one specific user for decryption and use. Therefore, in embodiments of the invention, each interactive application may be configured with a different white-box decryption key specific to each user.

[0046] As discussed above, code elevation attacks are a concern in both DRM and interaction settings. To mitigate these attacks, embodiments can ensure that white-box programs only run on intended devices. For this purpose, embodiments can use some form of device binding.

[0047] In DRM settings, device binding ensures that malicious users cannot obtain their white-box programs and distribute them to others for use by them without registration and / or paid access to the application. Here, due to device binding, white-box programs can only be used on devices registered by the user.

[0048] In DRM settings, encrypted data can be identical for all users. In contrast, in the interaction according to this embodiment, each user will have different inputs to their white-box program (a limited-use key associated with the white-box program). Therefore, in this case, device binding ensures that the white-box program can 1) be bound only to the device and 2) run only on inputs specific to that user. This additional feature can be referred to as "authentication binding," one goal of which is to bind the mobile application to a specific user. This ensures that only the owner of the limited-use key can decrypt and use them.

[0049] The security concept of white-box cryptography for mobile interactive applications has been studied in [1] [2]. The central concept relies on these characteristics of (device) hardware binding. However, this, along with other previous work, only provides a scheme that requires creating a specific white-box application for each user. The practicality of generating and distributing these user-specific white boxes can be severely limited. The embodiments improve this by introducing a scheme that provides device and authentication binding when distributing a single global white box suitable for all users.

[0050] Figure 1 A system according to an embodiment of the present disclosure is illustrated. The system includes a user device 102 that includes an application 104A comprising a white box 104B. The user device 102 may also include a security element 108. The system may also include a backend server computer 110 (also referred to as a backend or BE) and an application store 106. The application store 106 may run on the application server computer.

[0051] User device 102 can perform operational communication with application store 106 and backend server computer 110. Backend server computer 110 can perform operational communication with user device 102 and application store 106. Application store 106 can perform operational communication with user device 102 and backend server computer 110.

[0052] To simplify the explanation, Figure 1 A certain number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 All components shown are either fewer or more components.

[0053] At least Figure 1Messages between devices in the network can be sent using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); SSL; ISO (e.g., ISO 8583), etc. The communication network can include any one and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); Operational Mission as a Node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); etc. The communication network can use any suitable communication protocol to generate one or more secure communication channels. In some instances, the communication channel can include a secure communication channel, which can be established in any known manner, such as by using mutual authentication and session keys, and establishing a Secure Sockets Layer (SSL) session.

[0054] User device 102 may include, for example, a mobile device. User device 102 may communicate with application store 106 to download and then install applications (e.g., application 104A including white box 104B). User device 102 may also include a security element 108 that can prevent malicious tampering. Security element 108 can create password keys and perform password operations. Application 104A may be an application including white box 104B. For example, application 104A may be an interactive application, a streaming application, a communication application, an access application, etc.

[0055] Application store 106 may host one or more applications for download on user device 102. In some embodiments, application store 106 may include one or more server computers. In other embodiments, application store 106 may be a cloud storage system. Application store 106 may provide applications to user device 102 upon request.

[0056] Backend server computer 110 can create applications and white boxes. For example, backend server computer 110 can compile white boxes using appropriate cryptographic keys, as described herein. Backend server computer 110 may include a processor and a computer-readable medium coupled to the processor. The computer-readable medium may include code executable by the processor to perform methods including: obtaining a message from the backend server computer comprising content to be provided to an application installed on a user device; encrypting the message from the backend server computer using a master secret key or a key derived from the master secret key to obtain an encrypted message; and

[0057] The backend server computer provides the encrypted message to the user device, where the user device uses a secure element to sign the encrypted message with the secure element's private key to obtain a signed encrypted message. The white box in the application uses the backend server computer's public key to cryptographically recover the secure element's public key from the authenticated key. The white box uses the secure element's public key to cryptographically recover the encrypted message from the signed encrypted message. Finally, the white box uses the master secret key or a key derived from the master secret key to decrypt the encrypted message to obtain the message.

[0058] After obtaining application 104A from application store 106, user device 102 can register the downloaded application with backend server computer 110, which compiled application 104A. For example, user device 102 can provide the security element public key and / or user identifier generated by security element 108 to backend server computer 110 for registration.

[0059] Once registered, the backend server computer 110 can provide content to the application 104A on the user device 102. For example, the content may include videos, images, limited-use keys, and / or any data utilized by the application 104A.

[0060] As noted above, the architecture may include the following three parties: a back-end server computer (BE) 110, an application store 106, and a user device 102 operated by the user. The user device 102 may be a telephone with a secure element (SE). This refers to a public key / secret key (e.g., private key) pair generated at the backend server computer 110 and referred to as the server computer public key and the server computer secret key, respectively. This refers to the public key / secret key pair generated on the security element 108 of the user device 102 and referred to as the security element public key and the security element secret key, respectively.

[0061] Figure 1 The computers in the system can execute various cryptographic functions. For example, the backend server computer 110 can execute the SignBE function, which signs a value using the server computer's secret key. The backend server computer 110 can also execute the RecBE message recovery algorithm, which recovers a signed message based on the server computer's public key. The secure element 108 on the user device 102 can execute the SignSE function, which signs a value using the secure element's secret key. The secure element 108 can also execute the RecSE message recovery algorithm, which recovers a signed message based on the secure element's public key. Both message recovery algorithms can run on a white-box program.

[0062] This can represent the use of a key. Encrypted value . Indicates the use of key The value to be signed . This indicates that a key is hard-coded on it. The algorithm. `Comp` represents the compilation algorithm used for white-box programs. More precisely, `Comp` takes a (symmetric) master secret key MSK and a public key pK as input and returns a white-box program with both keys embedded within it: This compilation algorithm can be securely run by the backend server computer 110.

[0063] Figure 2 A block diagram of a user device 200 according to an embodiment is shown. The exemplary user device 200 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, a computer-readable medium 208, and a security element 210. The computer-readable medium 208 may include an application program 208A having a white box 208B.

[0064] Memory 202 can be used to store data and code. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (such as RAM, DRAM, ROM, flash memory, or any other suitable memory device). For example, memory 202 can store cryptographic keys, interactive data, user identifiers, etc.

[0065] Computer-readable medium 208 may include code executable by processor 204 to perform a method comprising: receiving, by a user device, an encrypted message from a back-end server computer, the encrypted message being a message encrypted by the back-end server computer using a master secret key or a key derived from the master secret key; signing, by the user device, the encrypted message using a secure element with a secure element private key to obtain a signed encrypted message; recovering, by the user device, using a white box, a secure element public key cryptographically from an authenticated key using a back-end server computer public key, the authenticated key being authenticated by the back-end server computer and at least based on the secure element public key, wherein the white box also stores the master secret key or a key derived from the master secret key; recovering, by the user device, the encrypted message cryptographically from the signed encrypted message using the secure element public key using the white box; and decrypting, by the user device, the encrypted message using the white box with the master secret key in the white box or a key derived from the master secret key to obtain the message.

[0066] Application 208A may include code or software executable by processor 204 to perform specific tasks. For example, if application 208A is an interactive application, it may include code or software executable by processor 204 to facilitate interaction, particularly for generating passwords. If application 208A is a video streaming application, it may include code or software executable by processor 204 to acquire video content and display it to the user of user device 200.

[0067] White box 208B may include code or software executable by processor 204 to perform cryptographic operations. White box 208B, in conjunction with processor 204, can cryptographically recover signed data and decrypt the data using a cryptographic key. For example, white box 208B, in conjunction with processor 204, can cryptographically recover a signed Secure Element public key. If the signed Secure Element public key is signed using a server computer secret key, white box 208B, in conjunction with processor 204, can cryptographically recover the Secure Element public key using the server computer public key, which corresponds to the server computer secret key used to sign the data. White box 208B, in conjunction with processor 204, can cryptographically recover signed data using a public key, which corresponds to the secret key used to sign the data using a message recoverable signing process. Further details regarding message recovery can be found in [7] and [8], which are incorporated herein by reference in their entirety for all purposes.

[0068] The white box 208B, in conjunction with the processor 204, can cryptographically recover an encrypted message from a signed encrypted message. For example, the encrypted message can be signed by the secure element 210 using a secure element secret key. Then, the white box 208B, in conjunction with the processor 204, can recover the encrypted message from the signed encrypted message using a secure element public key corresponding to the secure element secret key.

[0069] The white box 208B, in conjunction with the processor 204, can also decrypt encrypted messages. The white box 208B may include a master secret key, which is compiled into the white box 208B by the backend server computer. The white box 208B, in conjunction with the processor 204, can use the master secret key to decrypt encrypted messages and obtain the message.

[0070] Network interface 206 may include an interface that allows user device 200 to communicate with an external computer. Network interface 206 enables user device 200 to transfer data to and from another device (e.g., an application store, a back-end server computer, etc.). Some examples of network interface 206 may include a modem, a physical network interface (e.g., an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a PCMCIA slot and card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TM Data transmitted via network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may include data or instructions, may be provided between network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0071] The secure element 210 may include secure hardware components and / or secure software components. It can protect the secure element 210 from unauthorized access. For example, the secure element may be a tamper-proof hardware platform, such as a chip on a device, or it may be a tamper-proof software program, such as a virtual or emulated environment.

[0072] Secure element 210 can generate cryptographic key pairs locally. For example, secure element 210 can generate a secure element public key and a secure element secret key. Secure element 210 can also generate user identifiers. Furthermore, secure element 210 can sign data using a message recoverable signature process. For example, secure element 210 can use its secure element private key to sign an encrypted message to obtain a signed encrypted message, which can then be provided to white box 208B.

[0073] The embodiments may use the systems and devices described herein to at least bind the white box to the device. Figure 3-5 Examples of such methods are described. In some embodiments, user devices 306, 406, and 506 may each include Figure 1 and 2 User device 102 or user device 200.

[0074] Figure 3 A flowchart of a binding and secure message delivery process method according to an embodiment is shown. Figure 3The methods illustrated are described in the context of device binding for digital rights management. However, it should be understood that the invention can be applied to other situations.

[0075] As discussed herein, embodiments may include a process in which a backend server computer compiles a white-box application once for a security application (e.g., a DRM application) and stores the security application on an app store 304. Each user (e.g., each user who opts to download) can then download the same security application from app store 304 to their user device (e.g., user device 306). In this way, the backend server computer 302 does not need to compile a new white-box for each new user for security purposes. The backend server computer 302 only needs to provide encrypted messages (e.g., content) to each user.

[0076] Steps 320-326 may include a setup phase performed by the backend server computer 302 prior to providing the security application to the app store 304.

[0077] In step 320, the backend server computer 302 can generate the server computer public key. and server computer secret key ( The server computer's public key and private key can be a cryptographic key pair. In some embodiments, the backend server computer 302 may have a previously generated server computer public key and private key. The backend server computer 302 can then retrieve the server computer public key and private key from a secure storage device.

[0078] In step 322, after generating the server computer's public / secret key pair, the backend server computer 302 can generate a master secret key (MSK). The master secret key can be a symmetric key. The backend server computer 302 can generate the master secret key in any suitable manner capable of creating a symmetric cryptographic key.

[0079] In step 324, after generating the master secret key, the backend server computer 302 can compile the application. For example, the backend server computer 302 compiles an uncompiled application that includes a white-box component, wherein the server computer's public key and master secret key are embedded in the white-box program (e.g., ...). In some embodiments, the backend server computer 302 may obtain an uncompiled application for compilation. For example, the backend server computer 302 may obtain the uncompiled application from a database, a workplace computer, etc. After obtaining the uncompiled application, the backend server computer may use a compiler, a master secret key to the application, and the server computer's public key to compile the uncompiled application. Compiling the application may include converting application source code, which may be human-readable, into machine code, which may be executable by a computer. In some embodiments, the application may be compiled in such a way that the server computer's public key and master secret key are obfuscated within the white-box portion of the application.

[0080] As an illustrative example, the application could be a DRM-based application. The application could be a video streaming application, where, when installed on user device 306, the user can select a video within the application and then receive the selected video from backend server computer 302.

[0081] In step 326, after compiling the application including the white box, the backend server computer 302 can provide the application to the application store 304.

[0082] Steps 328-334 may include a download phase performed between the user device 306, which is attempting to download an application, and the application store 304.

[0083] In step 328, user device 306 (e.g., using the processor of user device 306, for example...) Figure 2 The processor 204 shown generates a download request message requesting the download of an application. The download request message may request an application selected by the user of user device 306. In some embodiments, the download request message may include a user device identifier.

[0084] In step 330, after generating the download request message, the user device 306 can provide the download request message to the application store 304.

[0085] In step 332, after receiving the download request message, the application store 304 can process the download request. For example, the application store 304 can determine whether the user device 306 is eligible to receive the security application. For example, the application store 304 can compare the user device identifier with a database that includes multiple user device identifiers. If the user device identifier matches a stored user device identifier, the application store 304 can provide the security application to the user device 306.

[0086] In step 334, after determining that the application will be provided to the user device 306, the application store 304 may provide the application to the user device 306 in response to the download request message.

[0087] Steps 336-366 may include the application initialization and security message provisioning phases.

[0088] In step 336, after receiving the application, user device 306 may install the application as application 310. Installing the application may include making the application ready to execute. The installation of the application may be performed by user device 306 in any suitable manner. In some embodiments, the installation may involve the application's code being copied / generated from the installation file (received from application store 304) to a new file on user device 306 for easier access by the operating system, thereby creating necessary directories, registering environment variables, providing a separate program for uninstallation, etc.

[0089] After installing application 310, user device 306 can register application 310 with backend server computer 302.

[0090] In step 338, the security element 308 on the user device 306 can generate a security element public key ( ) and security element secret key ( In some embodiments, user device 306 may prompt security element 308 to generate a security element public key (…). ) and security element secret key ( Secure Element 308 can generate a secure element public key ( ). ) and security element secret key ( This makes them unique for newly installed applications (e.g., application 310). Each different application can be associated with a different security element public / secret key pair.

[0091] In step 340, after generating the secure element public / secret key pair, secure element 308 (or, in some embodiments, user device 306) may generate a registration request message. The registration request message may include the secure element public key. In some embodiments, the registration request message may also include a user device identifier.

[0092] In step 342, the security element 308 may provide the registration request message to the processor of the user device 306 (e.g., Figure 2(e.g., element 204 in the original text). In some embodiments, security element 308 may provide the security element public key to a processor of user device 306 located outside of security element 301. User device 306, such as its processor, may then generate a registration request message including the security element public key.

[0093] In step 344, user device 306 may provide a registration request message containing the security element public key to backend server computer 302. The address of backend server 302 (e.g., IP address) may have already been provided in application 310.

[0094] Once the backend server computer 302 receives the registration request message, the backend server computer 302 can register the application 310 installed on the user device 306, which includes the security element 308.

[0095] In step 346, after receiving the registration request message, the backend server computer 302 can sign the secure element public key. The backend server computer 302 can sign the secure element public key using the server computer secret key (generated in step 320). Signing the secure element public key using the server computer secret key can be described as encoding the authenticated key. Specifically, the backend server computer 302 can perform... .

[0096] The backend server computer 302 can use the message recovery signing process to sign the secure element public key with the server computer's secret key. Further details regarding message recovery can be found in [7] and [8], which are incorporated herein by reference in their entirety for all purposes.

[0097] For example, a message reversible signing process can allow a signing device (e.g., a backend server computer 302, etc.) to sign data in such a way that a signature verification device (e.g., an application 310, etc.) can obtain the data and verify that the signing device is the one that actually signed the data.

[0098] In step 348, after obtaining the signed Secure Element public key (e.g., an authenticated key), the backend server computer 302 can provide the signed Secure Element public key to the user device 306. In some embodiments, the user device 306 can store the signed Secure Element public key in memory.

[0099] At any suitable point in time after step 348, the user of user device 306 may use application 310 installed on user device 306 to select content to receive from backend server computer 302. For example, application 310 may be a video streaming application. The user can use the video streaming application to select the video to watch. In step 350, application 310 can receive selections from the user.

[0100] In step 352, after receiving the selection from the user, the application 310 may provide a content request message including the selection from the user to the backend server computer 302.

[0101] In step 354, after receiving the content request message, the backend server computer 302 may obtain a message to be securely provided to the application 310. The message may include any data to be securely provisioned to the application 310. For example, the message may include content for the application 310. The content may be associated with a selection from the user. The content may include images, videos, animations, data, etc. In some embodiments, the backend server computer 302 may obtain the message from a database. In other embodiments, the backend server computer 302 may generate the message.

[0102] As an illustrative example, if application 310 is a video streaming application, then backend server computer 302 can obtain content associated with a video selected by the user in application 310 on user device 306, said content being a video. Backend server computer 302 can obtain the video from a video database.

[0103] In step 356, after receiving the message, the backend server computer 302 can encrypt the message. The backend server computer 302 can encrypt the message using the master secret key (MSK) generated in step 322. This message, including its content, can be referred to as... And it can be a bit string of any length, for example. This indicates that the message is encrypted. .

[0104] In step 358, after encrypting the message, the backend server computer 302 can provide the encrypted message and the signed Security Element public key to the user device 306.

[0105] In step 360, after receiving the encrypted message and the signed Secure Element public key from the backend server computer 302, the user device 306 may provide the encrypted message from its processor to the secure element 308. If the signed Secure Element public key has not yet been provided to the secure element 308, the user device 306 may also provide the signed Secure Element public key to the secure element 308 (e.g., from its processor).

[0106] In step 362, upon receiving the encrypted message ( Afterwards, secure element 308 can sign the encrypted message. Secure element 308 can sign the encrypted message using the secure element secret key (generated in step 338). Signing the encrypted message using the secure element secret key produces a signed encrypted message. For example, safety element 308 can perform... The secure element 308 can use a message recoverable signature process to sign encrypted messages using the secure element's secret key.

[0107] In step 364, after signing the encrypted message, the secure element 308 can transmit the signed encrypted message ( The signed secure element public key is provided to the white-box application 310.

[0108] In step 366, after receiving the signed encrypted message and the signed secure element public key, application 310 (e.g., by the white box of application 310, respectively, for example...) Figure 1 and 2 The white-box application 310 (performing a white-box 104B or white-box 208B) can recover (e.g., cryptographically) a secure element public key from a signed secure element public key. The white-box application 310 can recover a secure element public key from a signed secure element public key using a server computer public key corresponding to the server computer private key used to sign the secure element public key in step 346. For example, the white-box application 310 can perform pSE. RecBE(pBE, {pSE} sBE ).

[0109] In step 368, after obtaining the secure element public key, the white-box application 310 can recover (e.g., cryptographically recover) the encrypted message from the signed encrypted message. The white-box application 310 can recover the encrypted message from the signed encrypted message using the secure element public key, which corresponds to the secure element private key used to sign the encrypted message in step 356. For example, the white-box application 310 can perform... RecSE(pSE, ).

[0110] In step 370, after obtaining the encrypted message, the white-box of application 310 can decrypt the encrypted message. The white-box of application 310 can decrypt the encrypted message using the master secret key (MSK) compiled into the white-box of application 310 in step 324. The master secret key stored by the white-box of application 310 can be the same cryptographic key (e.g., a symmetric key) as the master secret key stored by the backend server computer 302. The white-box of application 310 can obtain the message by decrypting the encrypted message. For example, the white-box of application 310 can execute... .

[0111] In step 372, after obtaining the message from the encrypted message, application 310 can provide the message to the processor of user device 306. For example, if application 310 is a video streaming application, application 310 can provide the selected video to user device 306 (e.g., the processor of the user device) for video processing, so that the user can watch the video.

[0112] Figure 3 The method shown achieves the correctness and required security of the DRM application. For example, before the registration request message is provided to the backend server computer 302 in step 344, the user (here referred to as the malicious user) will not be able to run their secure application. Therefore, any copy of the program made by the malicious user is useless because the copy cannot run. If the malicious user has registered, and the malicious user has obtained the Security Element public key (e.g., {pSE}) signed by the backend server computer 302, then... sBE If a malicious user were to share a secure application with another user device, that user device would be able to run the secure application. However, the malicious user might not be able to share the secure application with other users who are not yet registered. For example, if a malicious user shares a signed Secure Element public key and the secure application with another user device, that user device will not be able to properly decrypt the messages. This is because the malicious user's signed Secure Element public key can only decrypt messages signed by the Secure Element of the malicious user's device. Any improperly shared copy of the secure application and the signed Secure Element public key will prevent another user from exploiting the secure application, thus preventing code elevation attacks.

[0113] In some embodiments, for further security, proof (e.g., using a proof public / private key pair) and authentication procedures may be included during registration.

[0114] Figure 4A flowchart of an alternative binding and secure message delivery process method according to an embodiment is shown. Figure 4 The methods illustrated are described in the context of device binding for interactive applications. However, it should be understood that the invention can be applied to other situations (e.g., other types of applications, other types of interactions, etc.). For example, the application may be an interactive application, a video streaming application, a data transfer application, a web access application, or a social media application.

[0115] refer to Figure 3 The described method may be suitable for DRM or applications, but for mobile interactive applications (e.g., mobile payment applications), greater confidentiality is required. For example, in Figure 3 In the embodiments described, each user with a valid security application can decrypt encrypted messages from any other user. This is because all messages are encrypted with the same master secret key, which is a symmetric key held by each security application and is independent of the user device. Figure 4-5 The method shown provides beyond Figure 3 The method shown provides additional security beyond that provided for interactive applications such as payment applications, building access applications, etc.

[0116] Figure 4-5 The alternative method shown can follow the same principles as... Figure 3 The method shown is similar, but can be adapted to achieve confidentiality of messages including limited-use keys for individual users. This can be achieved by encrypting the limited-use key (e.g., in the message...). m This is achieved by linking an identifier (in Chinese) to a secure element encoded on the user device. The identifier and the public key (pSE) generated by the secure element can then be authenticated together by a backend server computer. The identifier can then be combined with a master secret key to generate a user-specific encryption key for each message, including a limited-use key. (See reference) Figure 4-5 Further details are provided.

[0117] Steps 420-426 may include a setup phase performed by the backend server computer 402 prior to providing the security application to the app store 404. Steps 428-434 may include a download phase performed between the user device 406 attempting to download the security application and the app store 404. Figure 4 Steps 420-434 are similar Figure 3 Steps 320-334 are described herein and will not be repeated in detail here. Steps 436-466 may include the security application initialization and security message provisioning phases.

[0118] As an example Figure 4 The applications discussed herein can be interactive applications (e.g., transaction applications, such as payment applications, etc.). Interactive applications can facilitate interaction between two parties. For example, an interactive application can facilitate interaction between a user of user device 406 and a resource provider computer (not shown). Interactive applications can facilitate interaction by generating security information for the interaction. For example, in some embodiments, the interactive application can generate a password for the interaction.

[0119] In step 436, after receiving the application from the application store 404, the user device 406 can install the application as application 410. Application 410 may include a white box compiled using the server computer's public key and master secret key.

[0120] After installing the white-box application 410, the user device 406 can register the application 410 with the back-end server computer 402.

[0121] In step 438, the security element 408 on the user device 406 can generate a security element public key ( ) and security element secret key ( Secure Element 408 can generate secure element public / secret key pairs, as shown in the reference. Figure 3 As described in step 338.

[0122] In step 440, after generating the security element public / secret key pair, security element 408 may generate a user identifier. The user identifier may be an alphanumeric value identifying a user, user device 306, and / or security element 308. The user identifier may be a unique value generated by security element 308 and may be used to identify security element 308 to backend server computer 302 during registration. Security element 408 may use a random number generator to generate a random user identifier. In other embodiments, the user identifier may be a user-created value, such as a password or biometrics.

[0123] In step 442, after generating the user identifier, the secure element 408 may generate secure element identification data. In some embodiments, the secure element identification data may be at least a combination of the user identifier and the secure element public key. For example, the secure element 408 may generate secure element identification data by concatenating the secure element public key with the user identifier. For example, the secure element 408 may perform... The security element identification data can identify security element 408. The security element identification data can identify security element 408 because it includes the public key of security element 408 and a user identifier generated by security element 408.

[0124] In step 444, after generating the security element identification data, the security element 408 (or, in some embodiments, the user device 406) may generate a registration request message that includes the security element identification data. For example, the registration request message may include the security element public key and the user identifier.

[0125] In step 446, the security element 408 may provide the registration request message to a processor of the user device 406 located outside the security element 408 (e.g., Figure 2 (The processor 204 shown). In some embodiments, the security element 408 may provide security element identification data to the processor of the user device 406, wherein the user device 406 then generates a registration request message including the security element identification data.

[0126] In step 448, user device 406 may provide a registration request message to backend server computer 402.

[0127] In step 450, after receiving the registration request message, the backend server computer 402 can use the server computer secret key ( The secure element identification data is signed. The secure element identification data is signed using the server computer's secret key, thus encoding the authenticated key. Specifically, the backend server computer 402 can execute... The backend server computer 402 can use the message-recoverable signature process to sign the secure element identification data using the server computer's secret key.

[0128] In step 452, after signing the secure element identification data, the backend server computer 402 can derive the exported key. The exported key can be derived using the master secret key (MSK) and user identifier (ID) obtained from the secure element identification data. The backend server computer 402 can input the master secret key and user identifier into a key derivation function (KDF) to obtain the exported key (k). For example, the backend server computer 402 can execute... .

[0129] In step 454, after creating the exported key, the backend server computer 402 can provide the signed Security Element Identifier data to the user device 406. In some embodiments, the user device 406 can store the signed Security Element Identifier data in memory.

[0130] At any suitable point in time after step 454, a user of user device 406 may use application 410 to select content to receive from backend server computer 402. For example, application 410 may be an interactive application. Application 410 may request content from backend server computer 402 before or during the interaction. The content requested by the interactive application from backend server computer 402 may include a Limited Use Key (LUK). For example, a user may initiate an interaction with a resource provider to obtain resources. During the interaction, application 410 may request a Limited Use Key from backend server computer 402.

[0131] In step 456, application 410 generates a content (e.g., limited use key) request. In some embodiments, the content request may include a user device identifier or any other suitable data.

[0132] In step 458, application 410 may provide content requests to backend server computer 402.

[0133] In step 460, backend server computer 402 may generate a message including content to be provided to application 410. The message may include, for example, one or more Limited Use Keys (LUKs). Backend server computer 402 may generate one or more LUKs. In some embodiments, backend server computer 402 may obtain the LUK from a database. In other embodiments, backend server computer 402 may generate the LUK.

[0134] In step 462, after obtaining the message including the limited-use key, the backend server computer 402 can encrypt the message. The backend server computer 402 can encrypt the message using the derived key (k) (generated in step 452). This message (e.g., the limited-use key) can be referred to as... And it can be a bit string of any length, for example. This indicates that the encryption key has been used with limited access. .

[0135] In step 464, after generating the encrypted message, the backend server computer 402 can provide the encrypted message and the signed secure element identification data to the user device 406.

[0136] In some embodiments, after receiving the encrypted message and the signed secure element identification data in step 466, if the encrypted message was received before the interaction, the user device 406 may store the encrypted message and the signed secure element identification data for use in the interaction. In some embodiments, the signed secure element identification data may be stored in the memory of the user device 406. In other embodiments, the processor of the user device 406 may provide the signed secure element identification data to the secure element 408 for storage.

[0137] Figure 5 This demonstrates a method for using encrypted messages and signed secure element identification data for interaction.

[0138] In step 520, user device 506 may obtain interaction data related to interactions with a resource provider's computer (not shown). This interaction data may include data relating to one or more items purchased from a resource provider such as a merchant, or data relating to the user device's ability to access secure locations or secure data.

[0139] During the interaction, application 510 on user device 506 can generate a password. Steps 522-546 describe the use of... Figure 4 The encrypted message received and the signed security element identification data are used to securely create a password.

[0140] In step 522, the processor of user device 506 can provide an encrypted message to secure element 508, the encrypted message being provided by user device 506 in... Figure 4 Step 464 of the process is received.

[0141] In step 524, after receiving the encrypted message (e.g., an encrypted limited-use key), the secure element 508 can determine the authentication message ( y Secure element 508 can use an encrypted message and a user identifier to determine the authentication message. For example, secure element 508 can concatenate an encrypted limited-use key with a user identifier. For example, secure element 508 can perform... .

[0142] In step 526, an authentication message is generated ( y Afterwards, secure element 508 can sign the authentication message. Secure element 508 can sign the authentication message using its secure element secret key. For example, secure element 508 can execute... By signing the encrypted message, application 510 can later verify that it is communicating with the correct user device 506 and secure element 508, as discussed in further detail below.

[0143] In step 528, after signing the authentication message, the secure element 508 can provide the signed authentication message to the processor of the user device 506, which is external to the secure element 508.

[0144] In step 530, after obtaining the signed authentication message, the processor of user device 506 can provide the signed security element identification data (signed by the back-end server computer), the signed authentication message (signed by the security element 508), and the interaction data (obtained in step 520) to application 510.

[0145] In step 532, upon receiving the signed security element identification data ({ x} sBE ), signed authentication messages ({ y} sSE After processing the security element identification data and interacting with it, the white-box of application 510 can recover (e.g., cryptographically recover) the security element identification data from the signed security element identification data. For example, the white-box of application 510 can perform... .

[0146] In step 534, after obtaining the safety element identification data ( x Afterwards, the white-box application 510 can determine the secure element public key and user identifier from the secure element identification data. For example, the secure element identification data can be formed by cascading the secure element public key and user identifier. Therefore, the white-box application 510 can extract the secure element public key and user identifier from the secure element identification data. For example, the white-box application 510 can perform... The user identifier extracted from the security element identification data can be the registered user identifier. This is because the user identifier is provided to the backend server computer during registration.

[0147] In step 536, after obtaining the secure element public key and user identifier, the white-box application 510 can obtain the signed authentication message ({ y} sSE Recover (e.g., recover the authentication message y) using a password. For example, the white-box application 510 can perform this action. .

[0148] In step 538, the authentication message is restored ( yAfterwards, the white-box application 510 can determine the encrypted limited-use key and user identifier from the authentication message. For example, the authentication message can be formed by concatenating the encrypted limited-use key and user identifier. Therefore, the white-box application 510 can extract the encrypted limited-use key and user identifier from the authentication message. For example, the white-box application 510 can perform... The user identifier extracted from the authentication message can be the authenticated user identifier. This is because the user identifier is received from the security element during the interaction between the security element and the user for authentication.

[0149] In step 540, after obtaining the encrypted limited-use key and the user identifier, the white-box of application 510 can determine whether the two extracted user identifiers match. Specifically, the white-box of application 510 can register the user identifier. With authentication user identifier Comparison. For example, application 510 can perform a check. == If a user identifier is registered. With authentication user identifier If a match is found, the white-box testing of application 510 can proceed to step 542. If a user identifier is registered... With authentication user identifier If there is a mismatch, the white box of application 510 can terminate the process.

[0150] In step 542, if the user identifier is registered With authentication user identifier If a match is found, the white-box application 510 can export the exported key. k The exported key can be derived using the Master Secret Key (MSK) and User Identifier (ID) stored in the white box of application 510. The white box of application 510 can be used in conjunction with the backend server computer... Figure 4 The exported key is exported in the same way as step 452 in step 510. For example, the white-box application 510 can use a key export function to export the key. The white-box application 510 can input the master secret key and user identifier into the key export function. The key export function can be the same key export function used by the backend server computer. For example, the white-box application 510 can execute... .

[0151] In step 544, the exported key is determined. k Afterwards, the white-box application 510 can use the encrypted limited key. Decryption can be performed. The white-box application 510 can use the exported key. Limited use of the encrypted key Decrypt to obtain a limited-use key For example, the white-box application 510 can perform... .

[0152] In step 546, the encrypted limited-use key is used. After decryption, the white-box application 510 can generate a password for interaction. AC The white-box application 510 can use a limited-use key. and transaction data ( m Generate passwords. The white-box application 510 can generate passwords in any suitable manner. For example, the white-box application 510 can use the Message Authentication Code (MAC) function to generate passwords. For example, the white-box application 510 can execute... .

[0153] In step 548, the password is generated. AC Then, application 510 can provide (e.g., output) the password to the processor of user device 506.

[0154] In step 550, after receiving the password from application 510 AC User device 506 can then continue the interaction using the password. For example, user device 506 can utilize the password during the interaction. User device 506 can provide the password, along with interaction data and / or any other suitable data related to the interaction, to a resource provider computer (not shown). The resource provider computer can generate an authorization request message that includes the password and interaction data. For example, to authorize the interaction, the authorization request message can be provided to a transport (e.g., acquiring) computer. The authorization request message is then sent to a processing network computer. In some embodiments, the processing network computer can verify the password. If the password is valid, the processing network computer can forward the authorization request message to the corresponding authorizing entity computer associated with the authorizing entity associated with the user.

[0155] After receiving the authorization request message, the authorizing entity computer sends an authorization response message back to the processing network computer to indicate whether the current interaction is authorized (or not authorized). The processing network computer then forwards the authorization response message back to the transmitting computer. In some embodiments, the processing network computer may refuse the interaction even if the authorizing entity computer 150 has already authorized it. The transmitting computer then sends a response message back to the resource provider computer.

[0156] After receiving the authorization response message, the resource provider computer can then provide the authorization response message to the user device 506. The response message can be displayed by the user device 506, shown to the user by the resource provider computer, or printed on a physical receipt. Alternatively, if the interaction is online, the resource provider computer can provide a webpage or other indication of the authorization response message as a virtual receipt. The receipt may include interaction data from the interaction.

[0157] Figure 4-5 The method illustrated achieves confidentiality by using user identifiers stored in the secure element. When signing the secure element's public key, the backend server computer appends an ID value to the signed message. Similarly, when signing an encrypted limited-use key, the secure element appends an ID value to the limited-use key. The secure application checks if the user identifiers of the two signed messages are identical, and in this case, correct decryption can be performed. Only users with access to the secure element can generate such valid signed messages. Therefore, the signature algorithm achieves integrity.

[0158] The embodiments of this disclosure have numerous advantages. For example, the embodiments prevent malicious code execution escalation attacks. The embodiments improve upon previous methods and systems by introducing a scheme for device and authentication binding when distributing a single global whitebox suitable for all users. This is achieved, for example, by binding an application including the whitebox to a specific user device with a security element. The application is bound to the user device by enabling the application to verify a signature of the received data, where the signature is created by a backend server computer and the security element.

[0159] References

[0160] [1] Estuardo Alpirez Bock et al., On the security goals of white-box cryptography, Cryptology ePrintArchive, 2020 / 104, 2020.

[0161] [2] Estuardo Alpirez Bock et al., Security reductions for white-box key-storage in mobile payments, Cryptology ePrint Archive, 2019 / 1014, 2019.

[0162] [3] Dan Boneh and Brent Waters, Proceedings of the 13th ACM Conference on Computer and Communications Security, CCS Alexandria, Virginia, USA, October 30, 2006 From the date November 3, Pages 211-220, ACM, 2006.

[0163] [4] Stanley Chow et al., Selected Areas in Cryptography Pages 250-270, Berlin, Heidelberg, 2003, Springer Berlin-Heidelberg.

[0164] [5] Stanley Chow et al., Security and Privacy in Digital Rights Management in Digital Rights Management) ACM CCS-9 Workshop, DRM 2002, Washington, D.C., USA, November 18, 2002, Revised Paper. Lecture Notes in Computer Science Volume 2696, pp. 1-15, Springer Publishers, 2002.

[0165] [6] Ccile Delerablee et al., Cryptographic Region Selection - SAC 2013 - 20th International Conference, British Columbia Province, Canada, August 14-16, 2013, revised paper , Computer Science Lecture Notes Computer Science Volume 8282, pp. 247-264, Springer Publishers, 2013.

[0166] [7] International Organization for Standardization (2010), Information Technology - Security Technology - Providing Digital Signature Schemes for Message Recovery - Part 2: Machines Based on Integer Factors system (Information technology - Security techniques - Digital signature schemes giving message recovery - Part 2: Integer factorization based mechanisms) (ISO / IEC Standard No. 9796-2:2010).

[0167] [8] International Organization for Standardization (2013), Information Technology - Security Technology - Providing Digital Signature Schemes for Message Recovery - Part 3: Machine Based on Discrete Logarithms system(Information technology - Security techniques - Digital signature schemes giving message recovery - Part 3: Discrete logarithm based mechanisms) (ISO / IEC Standard No. 9796-3:2006).

[0168] Although the steps in the flowcharts and process flows above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and they may still be present in embodiments of the invention.

[0169] Any software component or function described in this application may be implemented as software code executed by a processor using any suitable computer language such as Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media (e.g., hard disk drive or floppy disk), or optical media (e.g., optical disc (CD) or digital versatile optical disc (DVD)), flash memory, and so on. The computer-readable medium may be any combination of such storage or transmission means.

[0170] Such programs can also be encoded and transmitted using carrier signals suitable for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, a computer-readable medium according to an embodiment of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with a compatible device or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0171] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art after reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the foregoing description, but rather by reference to the pending claims together with their full scope or equivalents.

[0172] Without departing from the scope of the invention, one or more features from any embodiment may be combined with one or more features from any other embodiment.

[0173] As used herein, unless explicitly indicated otherwise, the terms “a,” “an,” or “the” are intended to mean “at least one / a kind.”

Claims

1. A method comprising: The user device receives an encrypted message from the backend server computer. The encrypted message is a message generated by the backend server computer encrypting the original message using a master secret key or a key derived from the master secret key. The user device uses a security element and its private key to sign the encrypted message to obtain a signed encrypted message. The user device uses a white box to cryptographically recover the Secure Element public key from an authenticated key using the public key of a back-end server computer. The authenticated key is authenticated by the back-end server computer and at least based on the Secure Element public key. The white box also stores the master secret key or the key derived from the master secret key. The user device uses the white box and the public key of the security element to cryptographically recover the encrypted message from the signed encrypted message; as well as The user device uses the white box to decrypt the encrypted message using the master secret key in the white box or the key derived from the master secret key, in order to obtain the original message.

2. The method according to claim 1, further comprising: The user device installs an application, including the white box, onto the user device, wherein the white box securely includes the master secret key and the backend server computer public key; The user equipment uses the security element on the user equipment to generate the security element public key and the security element private key; The user device sends a registration message including the public key of the security element to the backend server computer associated with the application, wherein the backend server computer signs the public key of the security element with its private key to form the authenticated key, encrypts the original message with the master secret key or the key derived from the master secret key to obtain the encrypted message, and provides the encrypted message to the user device. as well as The user device receives the authenticated key from the backend server computer.

3. The method according to claim 2, further comprising: Before sending the registration message, the user device obtains a user identifier using the security element on the user device, and sending the registration message further includes: The user device sends the registration message to the backend server computer, wherein the registration message includes the security element public key and the user identifier, wherein the backend server computer uses its private key to sign the combination of the security element public key and the user identifier to form the authenticated key, uses the master secret key or the key derived from the master secret key to encrypt the original message to obtain the encrypted message, and provides the encrypted message to the user device.

4. The method of claim 3, wherein the user identifier is a registered user identifier, wherein the authenticated key is signed security element identification data, and wherein signing the encrypted message further comprises: The user device uses the security element to determine the authentication message using the encrypted message and the authentication user identifier; as well as The user equipment uses the security element and its private key to sign the authentication message, thereby forming a signed authentication message. The cryptographic recovery of the security element public key from the authenticated key includes: The user equipment uses the white box to cryptographically recover the security element identification data from the authenticated key. The user equipment obtains the public key of the security element and the registered user identifier using the white box; and The cryptographic recovery of the encrypted message from the signed encrypted message includes: The user device uses the white box to cryptographically recover the authentication message from the signed authentication message; and The user equipment uses the white box to obtain the encrypted message and the authenticated user identifier from the authentication message; and Decrypting the encrypted message includes: The user device uses the white box to compare the authenticated user identifier with the registered user identifier; If the authenticated user identifier and the registered user identifier match, the user device uses the white box to generate the key derived from the master secret key and the authenticated user identifier or the registered user identifier; and The user device uses the white box to decrypt the encrypted message using the key derived from the master secret key.

5. The method of claim 4, wherein the original message includes a limited-use key, wherein the limited-use key is encrypted by the back-end server computer using a key derived from the master secret key, the key being created by the back-end server computer using a key derivation function with the registered user identifier and the master secret key, wherein the limited-use key is used to form a cipher used in interactions between the user on the user device and the resource provider computer.

6. The method of claim 4, wherein the application is an interactive application, a video streaming application, a data transfer application, a web access application, or a social media application.

7. The method according to claim 5, further comprising: The user device obtains the interaction data of the interaction.

8. The method according to claim 7, further comprising: The user device uses the white box to generate the password for the interaction based on the limited-use key and the interaction data.

9. The method of claim 2, wherein before installing the application including the white box onto the user device, the method further comprises: The user device generates a download request message requesting the download of the application; The user device provides the download request message to the application store; as well as The user device receives the application from the application store in response to the download request message.

10. The method of claim 1, wherein the master secret key is a symmetric key generated by the backend server computer.

11. A user equipment, comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method comprising: Receive an encrypted message from a backend server computer. The encrypted message is generated by the backend server computer encrypting the original message using a master secret key or a key derived from the master secret key. The encrypted message is signed using the secure element's private key to obtain a signed encrypted message. The Secure Element public key is recovered cryptographically from an authenticated key using a backend server computer's public key, which is authenticated by the backend server computer; Using the white box and the public key of the secure element, the encrypted message is cryptographically recovered from the signed encrypted message; and The white box is used to decrypt the encrypted message using the master secret key or the key derived from the master secret key to obtain the original message.

12. The user device according to claim 11, wherein the method further comprises: An application including the white box is installed on the user device, wherein the white box securely includes the master secret key and the backend server computer public key; The security element public key and the security element private key are generated using the security element on the user device; A registration message including the public key of the security element is sent to the backend server computer associated with the application, wherein the backend server computer signs the public key of the security element with its private key to form the authenticated key, encrypts the original message with the master secret key or the key derived from the master secret key to obtain the encrypted message, and provides the encrypted message to the user device. as well as Receive the authenticated key from the backend server computer.

13. The user device according to claim 12, wherein the method further comprises: Before sending the registration message, the user device obtains a user identifier using the security element on the user device, and sending the registration message further includes: The user device sends the registration message to the backend server computer, wherein the registration message includes the security element public key and the user identifier, wherein the backend server computer uses its private key to sign the combination of the security element public key and the user identifier to form the authenticated key, uses the master secret key or the key derived from the master secret key to encrypt the original message to obtain the encrypted message, and provides the encrypted message to the user device.

14. The user equipment according to claim 13, The user identifier is a registered user identifier, the authenticated key is signed security element identification data, and signing the encrypted message further includes: The user device uses the security element to determine the authentication message using the encrypted message and the authentication user identifier; as well as The user equipment uses the security element and its private key to sign the authentication message, thereby forming a signed authentication message. The cryptographic recovery of the security element public key from the authenticated key includes: The user equipment uses the white box to cryptographically recover the security element identification data from the authenticated key. The user equipment obtains the public key of the security element and the registered user identifier using the white box; and Wherein e) recovering the encrypted message from the signed encrypted message in a cryptographic manner includes: The user device uses the white box to cryptographically recover the authentication message from the signed authentication message; and The user equipment uses the white box to obtain the encrypted message and the authenticated user identifier from the authentication message; and Decrypting the encrypted message includes: The user device uses the white box to compare the authenticated user identifier with the registered user identifier; If the authenticated user identifier and the registered user identifier match, the user device uses the white box to generate the key derived from the master secret key and the authenticated user identifier or the registered user identifier; and The user device uses the white box to decrypt the encrypted message using the key derived from the master secret key.

15. The user device of claim 12, wherein the back-end server computer uses a message recovery signature process to sign the public key of the security element using the private key of the back-end server computer.

16. The user device of claim 11, wherein the user device is a mobile phone.

17. The user equipment of claim 11, wherein the security element is on the user equipment and communicates with the processor.

18. The user device of claim 11, wherein the white box is on the computer-readable medium, and wherein the original message is encrypted using the master secret key.

19. A method comprising: The backend server computer receives the original message containing the content to be provided to the application installed on the user's device; The backend server computer encrypts the original message using the master secret key or a key derived from the master secret key to obtain an encrypted message; as well as The backend server computer provides the encrypted message to the user device, wherein the user device uses a secure element to sign the encrypted message with the secure element private key to obtain a signed encrypted message, uses a white box in the application to recover the secure element public key from the authenticated key in a cryptographic manner using the backend server computer public key, uses the white box to recover the encrypted message from the signed encrypted message in a cryptographic manner using the secure element public key, and uses the white box to decrypt the encrypted message using the master secret key or the key derived from the master secret key to obtain the original message.

20. The method of claim 19, further comprising: Before obtaining the original message, the backend server computer generates its public key and private key. The master secret key is generated by the backend server computer; The uncompiled application is obtained from the backend server computer for compilation. The backend server computer compiles the uncompiled application, the master secret key, and the backend server computer's public key into the application. The application is delivered to the app store by the backend server computer; The back-end server computer receives a registration message, including the public key of the security element, from the user device, wherein the user device has the application compiled by the back-end server computer installed; The back-end server computer uses its private key to sign the public key of the security element to form the authenticated key; as well as The authenticated key is provided to the user device by the backend server computer.

Images