Verify device and application integrity

Abstract

The present disclosure relates to using trust tokens to authenticate the integrity of devices and applications from which data is received. In one aspect, a method includes receiving a request for one or more trust tokens from a client device. The request includes at least one of one or more device-level fraud detection signals obtained from the client device or data representing the code of the application initiating the request. The request also includes a respective nonce for each of the one or more trust tokens. A determination to issue one or more trust tokens to the client device is made based on at least one of one or more device-level fraud detection signals or data representing the code of the application. Each trust token is generated using the nonce for the trust token. The one or more trust tokens are provided to the client device.

Description

Technical Field

[0001] This specification describes techniques related to using trust tokens to verify the integrity of devices and applications from which data is received. Background Art

[0002] Client devices transmit data over a public network such as the Internet. These communications can be intercepted and / or altered by entities other than the intended recipient. In addition, these entities can forge network identities and send data that appears to originate from these forged network identities. These entities can also alter application code to insert malicious code that sends fraudulent data. Summary of the Invention

[0003] Generally, one innovative aspect of the subject matter described in this specification can be embodied in a method that includes receiving, from a client device, a request for one or more trust tokens. The request includes at least one of (i) one or more device-level fraud detection signals obtained from the client device or (ii) data representing the code of the application that initiated the request; and a respective random number for each of the one or more trust tokens. A determination is made, based on at least one of (i) the one or more device-level fraud detection signals or (ii) the data representing the code of the application, to issue one or more trust tokens to the client device. In response to the determination to issue one or more trust tokens to the client device, each of the one or more trust tokens is generated using the random number for the trust token, and the one or more trust tokens are provided to the client device. Other implementations of this aspect include corresponding apparatuses, systems, and computer programs encoded on a computer storage device and configured to perform aspects of the method.

[0004] These and other implementations can each optionally include one or more of the following features. In some aspects, determining to issue one or more trust tokens to the client device based on at least one of (i) the one or more device-level fraud detection signals or (ii) the data representing the code of the application includes: determining that the client device is a trusted device based on the one or more device-level fraud detection signals, determining that the application is a trusted application based on the data representing the code of the application, and in response to determining that the client device is a trusted device and the application is a trusted application, determining to issue one or more trust tokens to the client device.

[0005] In some aspects, the data representing the code of the application includes an encrypted hash of the code of the application. Determining to issue one or more trust tokens to the client device can include determining that the application is a trusted application based on the code of the application, and in response to determining that the application is a trusted application, determining to issue one or more trust tokens to the client device.

[0006] In some aspects, determining that an application is a trusted application includes comparing a cryptographic hash of the code of the application with a cryptographic hash of the code of an official build of the application, and determining that the application is a trusted application in response to the cryptographic hash of the code of the application matching the cryptographic hash of the code of the official build of the application.

[0007] In some aspects, determining that an application is a trusted application includes determining that a certificate has been issued for the application indicating that the application does not include malicious application logic.

[0008] In some aspects, the nonce for each trust token is a blinded nonce blinded using a blind signature scheme. Generating each of the one or more trust tokens can include generating a blind signature for the blinded nonce of the trust token using a blind signature scheme. A trust token can include the blinded nonce and the blind signature of the blinded nonce.

[0009] Some aspects can include receiving, from a client device, a redemption request that includes a given trust token for redemption. The given trust token can include an unblinded nonce and a blind signature generated based on a blinded version of the nonce. The blind signature of the given trust token can be verified using the unblinded nonce and the blind signature scheme. In response to verifying the blind signature, a signed redemption record for the given trust token is sent to the client device.

[0010] In some aspects, the request includes a public key of the client device. Each of the one or more trust tokens can be encrypted using the public key of the client device. Providing the one or more trust tokens to the client device can include providing the client device with one or more encrypted trust tokens.

[0011] In some aspects, the request includes a device identifier of the client device. The device identifier can be used to maintain a history of the trustworthiness of the client device. Determining to issue the one or more trust tokens to the client device can include determining that the client device is a trusted device based on a combination of a device-level fraud detection signal and the history of the trustworthiness of the client device.

[0012] In some aspects, determining that the client device is a trusted device based on a combination of a device-level fraud detection signal and the history of the trustworthiness of the client device includes: determining that the client device is a trusted device based on a combination of the device-level fraud detection signal, the history of the trustworthiness of the client device, and the number of trust tokens requested by the client device during a given time period.

[0013] The subject matter described in this specification can be implemented in particular embodiments to achieve one or more of the following advantages. The recipient of a request (or other communication or data) received from a device can, for example, based on a signed redemption record provided to the device when redeeming a trust token, verify that the device and the application running on the device that sent the request are trusted devices, based on the trust token issued to the device. The token and / or the signed redemption record attest to the trustworthiness of the device and its application based on an assessment by the trust token system.

[0014] The trust token system can evaluate device-level fraud detection signals to determine whether a client device is trusted. The trust token system can also, for example, determine whether the application (e.g., a web browser) initiating the request is a trusted application based on whether the build of the application on the device before the trust token was issued is an official build. This ensures that the device is a genuine device (e.g., as opposed to a virtual machine in a data center or a device infected / compromised with malware), and that the application is not a custom build with potentially malicious code inserted. Using a trust token issued based on such a combination of assessments can protect the recipient from abuse (e.g., malicious bots attempting to create fake accounts or take over a user's real account) and fraud (e.g., malicious parties attempting to profit from forged requests / communications), and ensure trust in systems and protocols that rely on trusted communications received from devices and applications. Thus, the disclosed systems and methods provide a technical advantage of providing a secure means for communication between devices. Additionally, the disclosed systems and methods are capable of providing such a secure means of communication while maintaining user privacy, because the disclosed systems and methods are able to issue trust tokens based on device-level and application-level information, thereby obviating the need to evaluate user-level data (such as browsing history or other user profile information) to determine whether a client device is trusted. Thus, the disclosed systems and methods also provide a technical advantage of protecting user information and maintaining user privacy.

[0015] A trust token can be generated based on a blinded random number that is blinded at a client device and sent to a trust token system. The client device can unblind the random number of the trust token before redeeming the trust token with the trust token system. In this way, user privacy is protected because the trust token system cannot correlate the blinded random number of the issued trust token with the unblinded random number of the redeemed trust token. Thus, this provides a technical advantage of maintaining user privacy at the device level and application level. By issuing trust tokens based only on device and application signals independently of signals related to the user of the client device, user privacy can be further improved. Thus, such information related to the user of the client device, such as browsing history or other data personalized for the user of the client device, is not required for issuing trust tokens, and thus there is no need to transmit this information to the trust token issuer for evaluation. In this way, personal user information is protected, and thus this provides a technical advantage of maintaining user privacy.

[0016] Trust tokens can be requested and issued in batches. This reduces the burden on the trust token system (e.g., the number of CPU cycles used) because the trust token system issues multiple tokens based on a single evaluation of the client device and application, thus providing a technical advantage of reducing the resources required to issue multiple trust tokens. This also reduces the latency at the client device because the tokens can be issued to the client device before any request that requires trust token verification, rather than waiting for an evaluation of the client device for each request, thus also providing a technical advantage of a more responsive system with reduced latency for issuing trust tokens.

[0017] The various features and advantages of the foregoing subject matter are described below with reference to the accompanying drawings. Additional features and advantages are apparent from the subject matter described herein and the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 is a block diagram of an example environment in which a trust token system issues and redeems trust tokens.

[0019] Figure 2 is a flowchart illustrating an example process for issuing a trust token.

[0020] Figure 3 is a flowchart illustrating an example process for redeeming a trust token.

[0021] Figure 4 is a flowchart illustrating an example process for processing a request that includes a signed redemption record based on a redeemed trust token.

[0022] Figure 5 is a block diagram of an example computer system that can be used to perform the operations described above.

[0023] Like reference numerals and designations in the various figures indicate like elements. DETAILED DESCRIPTION

[0024] Generally, this document describes systems and techniques for using trust tokens to authenticate the integrity of devices and applications from which requests, communications, or other data are received. The recipients of certain types of requests received from client devices desire to ensure that the requests are valid and not received from compromised or fraudulent devices or applications. For example, a user privacy system may desire to ensure that requests to change a user's privacy settings are received from a genuine client device and from an official build of an application rather than from a fraudulent virtual machine running in a data center or a custom build of an application with malicious code, thereby enhancing user privacy when using the application. Although the following description is primarily in terms of requests sent by client devices, these techniques can be used to authenticate the integrity of other types of data or communications received from client devices.

[0025] An application that sends requests for which the send credibility is considered important (e.g., by the recipient of the request) can request a trust token from a trust token system. The trust token system can evaluate the credibility of the client device and the application, and if both are considered trusted, the trust token system can issue a trust token to the client device. When the application later submits a request to the recipient, the application can redeem the trust token for a signed redemption record (SRR), and the application can include the trust token in the request. As described in more detail below, the SRR can include a digital signature generated by the trust token system to ensure that the data in the request is not manipulated and to prove that the client device and the application were evaluated and / or considered trusted by the trust token system. This provides a secure means for determining that the client device is trusted because the digital signature generated by the trust token system verifies that the client device is trusted, and the digital signature also ensures that the verification has not been manipulated.

[0026] Figure 1 is a block diagram of an example environment 100 in which a trust token system 130 issues and redeems trust tokens. The example environment 100 includes a data communication network 105, such as a local area network (LAN), wide area network (WAN), the Internet, a mobile network, or a combination thereof. The network 105 connects client devices 110, a recipient's recipient device 120, and the trust token system 130. The example environment 100 can include many different client devices 110, trust token systems 130, and recipient devices 120.

[0027] The client device 110 is an electronic device capable of communicating via the network 105. Example client devices 110 include personal computers, mobile communication devices (e.g., smartphones), and other devices that can send and receive data via the network 105.

[0028] The client device 110 typically includes applications 112, such as web browsers and / or native applications, to facilitate sending and receiving data via the network 105. Native applications are applications developed for a specific platform or a specific device. In some embodiments, the client device 110 is a digital media device, e.g., a streaming device that plugs into a television or other display to stream video to the television. The digital media device may also include a web browser and / or other applications that stream video and / or render resources.

[0029] The client device 110 also includes a trusted program 114. The trusted program 114 may include trusted code from a reliable source that is difficult to forge. For example, the trusted program 114 may be an operating system, a part of an operating system, a web browser, etc. Generally, the trusted program 114 is difficult to penetrate, and the amount of time and effort required for a perpetrator to tamper with the trusted program 114 is prohibitively high. Additionally, since the trusted program 114 is provided and maintained by a reliable source, the source can address any vulnerabilities that arise. Using such a trusted program in this manner provides the technical advantage of increased security at the client device because the trusted program is difficult to penetrate. Additionally, the trusted program provides the advantage of mitigating vulnerabilities in the trusted program because the program is maintained by a reliable source.

[0030] The trusted program 114 may be local to the user device 110. For example, the trusted program 114 may be a device driver for the operating system of the user device 110. In some embodiments, the trusted program 114 operates entirely locally on the user device 110, which reduces the need to transmit user information. In some embodiments, the trusted program 114 may operate locally on the user device 110 and via a network, such as the network 105. For example, the trusted program 114 may be a web browser installed on the user device 110 that transmits and receives information via the network 105.

[0031] The application 112 may send a request to the recipient's recipient device 120. The recipient device 120 may be a computer (e.g., a server), a mobile communication device, and other devices that can send and receive data via the network 105. The request may include a request to update settings (e.g., user privacy settings), a request for content, a request to report data, a request to install an application, and / or other appropriate types of requests. An example recipient is a content provider that provides content in response to the request.

[0032] For some requests, application 112 may include a trust token or an SRR based on a redeemed trust token to verify that the request is being sent by a trusted application and a trusted device. Application 112 may request one or more trust tokens from trust token system 130, for example, via trusted program 114. For example, application 112 may call an application programming interface (API) of trusted program 114 to request the (one or more) trust tokens. Trusted program 114 may then request the (one or more) trust tokens from trust token system 130.

[0033] Trusted program 114 may collect a set of data and include it in the request for a trust token for the application. This set of data may include a nonce for each requested trust token. A nonce is an arbitrary (e.g., random or pseudorandom) number. In some embodiments, instead of including a plaintext nonce for each trust token, the request includes a blinded nonce for each requested trust token. Trusted program 114 (or application 112 itself) may generate the nonce and blind the nonce using a blind signature scheme. Blinding the nonce may include hiding or obscuring the value of the nonce, e.g., by combining the nonce with a blinding factor. The blind signature scheme may include an Internet Engineering Task Force (IETF) Verifiable Oblivious Pseudorandom Function (VOPRF) protocol, RSA (Rivest-Shamir-Adleman), or another suitable blind signature scheme. As described in more detail below, the nonce is used to generate the trust token, and using a blinded nonce provides a technical advantage of enhancing user privacy.

[0034] This set of data for the request for a trust token may include device-level fraud detection signals. Device-level fraud detection signals may include data representing operating characteristics or metrics of the client device that can be used to determine whether the client device has been compromised or whether the client device is operating as a legitimate client device or an emulated client device. Certain operating characteristics and metrics of a legitimate client device are typically different from those of an emulator. In some embodiments, the device-level fraud detection signals include application-level fraud detection signals, which include the operating characteristics and metrics of application 112 that is requesting the trust token. Trusted program 114 may collect these device-level fraud detection signals and include these signals in the request for the trust token.

[0035] This set of data in the request for a trust token can also include data related to the application 112 that initiates the request for the trust token and will ultimately use the trust token. This data can include an identification of the application, e.g., the package name of the application's package file and data that can be used to determine whether an instance of the application 112 on the client device 110 is an official build of the application. This data can include data representing the code of the application 112. For example, the trusted program 114 can use a cryptographic hash function to generate a cryptographic hash of the code of the application 112 and include the hash of the code in the request. The hash can be a hash of the (one or more) application binaries of the application 112, a hash of the executable file of the application 112, and / or a hash of all files of the build of the application 112 currently running at the client device 110. In some embodiments, this data can also include a hash of a certificate signed by the developer of the application 112 using the developer's private key. The trusted program 114 can generate the hash at the time of the request to ensure that the hash represents the current build of the application 112 running on the client device 110.

[0036] In some embodiments, this set of data in the request for a trust token can include a unique device identifier of the client device 110 submitting the request. The device identifier can be the public key of the client device. For example, the client device 110 can include an asymmetric cryptographic key pair that includes a public key and a private key corresponding (e.g., mathematically associated) with the public key. As described in more detail below, the device identifier can be used to limit the number of trust tokens issued to a given client device and / or maintain a history of the trustworthiness of the client device 110.

[0037] The trust token system 130 can receive trust token requests from the client device 110, issue trust tokens in response to at least some of the requests, and redeem trust tokens for the client device 110. The trust token system 130 includes a trust token issuer 132, a device evaluator 134, and an application evaluator 136, each of which can be implemented using one or more data processing devices (e.g., one or more server computers). In some embodiments, two or more of the trust token issuer 132, the device evaluator 134, and the application evaluator 136 are implemented on the same computer.

[0038] In some embodiments, the trust token system 130 is maintained and operated by the entity that develops the trusted program 114. For example, if the trusted program 114 is an operating system, the trust token system 130 can be operated by the operating system developer. In some embodiments, the trust token system 130 is operated by an entity different from the entity that develops the trusted program 114, e.g., by a third-party device and application fraud detection system.

[0039] The device evaluator 134 evaluates device-level fraud detection signals of the trust token request to determine whether the client device 110 from which the trust token request is received is a trusted device. The device evaluator 134 can determine the credibility level of the client device 110 based on the fraud detection signals. For example, the credibility level can be on a numerical scale, such as 1-3, 0-10, 0-100, or another suitable scale. If the credibility level meets the credibility threshold, such as reaching or exceeding the threshold, the device evaluator 134 can classify the client device 110 as a trusted device.

[0040] In some embodiments, the device evaluator 134 differentiates between genuine client devices, simulators, rooted devices, and / or other suitable categories of devices based on the device-level fraud detection signals. In this example, when the client device is classified in a particular category, such as the genuine client device category, the device evaluator 134 can classify the client device as a trusted device.

[0041] The device evaluator 134 can store the classification(s) of the client device 110 in the device trust database 146 or other suitable data structures. For each client device 110, the device trust database 146 can include the device identifier of the client device 110 and a history of the credibility of the client device 110. This history can include one or more historical classifications of the client device 110. For example, the history of the credibility of the client device 110 can include, for a given time period, the credibility level of the client device 110 and / or the classification of the client device 110 (e.g., trusted or untrusted and / or category). The given time period can include all requests received from the client device 110 with the same device identifier (since the device identifier can change in some embodiments) or within a limited time period (e.g., last week, last month, last year, etc.).

[0042] The history of the trustworthiness of client device 110 can be used to determine whether to issue a trust token to client device 110 in response to a trust token request. In some embodiments, the trust token issuer 132 can consider the trustworthiness pattern of client device 110 to determine whether to issue a trust token to client device 110. For example, a malicious party may operate client device 110 in a normal manner part of the time and in a fraudulent manner part of the time. The history of this client device 110 can indicate that client device 110 is trusted at certain points in time and not trusted at other points in time. In other words, there may be one or more previous instances where client device 110 was determined to be trustworthy, and one or more previous instances where client device 110 was determined to be untrustworthy. In this example, even if the evaluation results in client device 110 not being trusted, the trust token system 130 can issue a trust token to client device 110 to prevent the malicious party from learning how to game the system. This provides the technical advantage of preventing the malicious party from determining how the trust token issuer operates, thereby providing security for the trust token issuer. Specifically, if the malicious party were to learn how the trust token system operates, the party might be able to manipulate the system to obtain a trust token even though it is untrustworthy. Thus, by preventing the malicious party from learning how the system works in this way, improved security is provided. In another example, if the history indicates that client device 110 is not trusted most or all of the time, the trust token system 130 may not issue a trust token to client device 110 unless client device 110 is considered trusted for at least a threshold number of consecutive evaluations or within a threshold time period (e.g., one week, one month, etc.). Thus, the history can be used to determine whether a client device is trustworthy, thereby providing the technical advantage of providing a means for detecting whether a device is trustworthy.

[0043] The application evaluator 136 evaluates the data of the trust token request to determine whether an instance of application 112 on client device 110 is an official build of the application. The application evaluator 136 can access an application build database 148 (or other suitable data structure) that includes hashes of the code of the official builds of application 112. For example, when an application developer releases a new build of an application, the application developer can provide the code of the application to the trust token system 130. The trust token system 130 can generate a hash of the code using the same cryptographic function that the trusted program 114 on client device 110 uses to generate a hash of the code of application 112. The application build database 148 can include an identifier of the application for each application and a hash of the code of the application for each official build of the application. In some embodiments, the trust token system 130 can receive the code of each application from an app store that makes the application available for download to client device 110.

[0044] The application evaluator 136 can compare the hash of the code of the application included in the trust token request with the hashes of the code of each official build of the application stored in the application build database 148. The application evaluator can use the identifier of the application 112 included in the trust token request to identify the hash of the official build of the application 112 in the application build database. If there is a match between the hash of the code of the application 112 in the trust token request and the hash of the code of the official build of the application 112, the application evaluator 136 can determine that the instance of the application running on the client device 110 is an official build of the application and that the application is a trusted application. If there is no match, the application evaluator 136 can determine that the instance of the application running on the client device 110 is not an official build of the application.

[0045] In some embodiments, the trust token request need not include an identifier of the application 112. In this example, the application evaluator 136 can compare the hash of the code of the application with the hashes of the code of multiple applications to determine if there is a match.

[0046] In some embodiments, the application evaluator 136 can determine that an instance of an application running on the client device 110 is not a trusted application in response to the instance not being an official build. In some embodiments, the application evaluator 136 can consider additional information in response to determining that the instance is not an official build. For example, the application evaluator 136 can consider network traffic analysis data that indicates the percentage of network traffic from unofficial builds of applications classified as malicious or invalid. If at least a threshold percentage (e.g., 80%, 50%, 100% or another suitable threshold) of the network traffic from an unofficial build of an application is considered malicious or invalid, the application evaluator 136 can determine that any instance of the application that is not an official build is not trusted.

[0047] The trust token issuer 132 can determine whether to issue a trust token in response to the trust token request based on the data included in the trust token request and / or the determinations made by the device evaluator 134 and / or the application evaluator 136. For example, the trust token issuer 132 can determine whether to issue a trust token in response to the trust token request based on device-level fraud detection signals and / or data representing the code of the application.

[0048] In some embodiments, when the device evaluator 134 determines that the client device 110 is a trusted device and / or the application evaluator 136 determines that the application 112 is a trusted application, the trust token issuer 132 may issue a trust token to the client device 110 in response to a trust token request. In some embodiments, the trust token issuer 132 determines to issue a trust token to the client device 110 only when the client device 110 is considered a trusted device and the application 112 is considered a trusted application. In some embodiments, when at least one of the device evaluator 134 or the application evaluator 136 outputs a trusted verdict, the trust token issuer 132 determines to issue a trust token. Other embodiments may include only one of the device evaluator 134 or the application evaluator 132, such that when that one evaluator deems the client device 110 or the application 112 to be trusted, the trust token issuer 132 issues a token to the client device 110. An example process for issuing trust tokens is shown in Figure 2 and described below.

[0049] The trust token issuer 132 may maintain a count of the number of trust tokens issued to the client device 110 in a token issuance database 142 (or other suitable data structure). The token issuance database 142, for each device identifier, may include a count of the number of trust tokens issued to the client device 110 corresponding to that device identifier over one or more time periods, such as daily, weekly, monthly, and / or overall, since the first trust token request including that device identifier. The trust token issuer 132 may use this data to limit the number of trust tokens issued to the client device 110 or to completely prevent trust tokens from being issued to that device. For example, if, based on historical trends of the client device 110, for example, the number of requested trust tokens is unusually high for the client device, the trust token issuer 132 may stop issuing trust tokens to the client device 110 because the client device 110 may have been compromised recently. This provides the technical advantage of preventing potentially untrusted devices from being issued trust tokens even when device-level and application-level signals indicate that the device is trusted, thus providing an improved method for detecting untrusted devices. This also provides the technical advantage of maintaining security by preventing untrusted devices from being considered trusted.

[0050] The trust token issuer 132 may also redeem trust tokens for the client device 110. When the application 112 of the client device 110 is about to send a request suitable for an SRR, the application 112 may send a request to redeem a trust token to the trust token system 130. The request may include a trust token issued to the client device 110. The trust token issuer 132 may evaluate the trust token, and if valid, the trust token issuer may generate an SRR and send the SRR to the client device 110.

[0051] When the trust token issuer 132 exchanges a trust token, the trust token issuer 132 can update the token exchange database 144 (or other appropriate data structure). The trust token issuer 132 can use the token exchange database 144 to ensure that each trust token is exchanged only once. The token exchange database 144 can include the plaintext value of the random number of the trust token for each exchanged trust token. When the trust token issuer 132 receives a request to exchange a trust token, the trust token issuer 132 can compare the plaintext value of the random number with the plaintext value of the random number in the token exchange database 144. If there is a match, the trust token has been exchanged, and the trust token issuer can refrain from issuing an SRR. If there is no match, the trust token issuer 132 can issue an SRR and update the token exchange database 144 to include the plaintext value of the random number of the exchanged trust token, assuming the trust token is also valid. An example process for exchanging a trust token is shown in Figure 3 and described below.

[0052] After exchanging the trust token, the application 112 can send a request to the recipient's recipient device 120. The request can include the SRR issued to the client device 110 (or the application 112) in response to cashing in the trust token. The recipient device 120 can evaluate the SRR to determine whether and / or how to respond to the request. An example process for processing a request that includes an SRR is shown in Figure 4 and described below.

[0053] Figure 2 is a flowchart showing an example process for issuing a trust token. Process 200 can be implemented, for example, by a trust token system (e.g., Figure 1 the trust token system 130). The operations of process 200 can also be implemented as instructions stored on a non-transitory computer-readable medium, and execution of the instructions by one or more data processing devices can cause the one or more data processing devices to perform the operations of process 200. For simplicity, process 200 is described according to Figure 1 the trust token system 130.

[0054] The trust token system 130 receives a request (202) for one or more trust tokens from the client device 110. An application 112 installed on the client device 110 can initiate the request so that the application 112 can use the trust tokens to verify the integrity of the client device 110 when communicating with a recipient. For example, the application 112 can request trust tokens periodically (e.g., once a day, once a week, etc.) or when the number of trust tokens stored but not redeemed by the application 112 drops to or below a threshold. To request a trust token, the application 112 can call an API of a trusted program 114 (e.g., the operating system of the client device 110) of the client device 110.

[0055] The request received by the trust token system 130 can include a nonce for each requested trust token, a device-level fraud detection signal, and data related to the application 112 that initiated the request for the trust token. In some embodiments, the request can also include a unique device identifier of the client device 110. The application-related data can include an identifier of the application and a hash of the application's code.

[0056] The trust token system 130 evaluates the device-level fraud detection signal (204). For example, a device evaluator 134 of the trust token system 130 can compare the operational characteristics and metrics included in the fraud detection signal with the corresponding characteristics and metrics of a genuine client device, a simulator, a rooted device, etc. If the characteristics and metrics of the client device 110 are similar to one of multiple categories of devices, the device evaluator 134 can classify the client device 110 into that category. For example, for each operational characteristic or metric, the device evaluator 134 accesses a first value or first value range of the characteristics of a genuine client device, a second value or second value range of the characteristics of a simulator, and / or a third value or third value range of the characteristics of a rooted device. The device evaluator 134 can compare each operational characteristic or metric of the client device 110 with the corresponding values or value ranges of each category of devices. The device evaluator 134 can perform this comparison for multiple operational characteristics and metrics and determine whether more operational characteristics and metrics are within (or closer to) the corresponding ranges of a genuine device, a simulator, or a rooted device. The device evaluator 134 can then determine that the client device 110 is more similar to the category of devices for which more of its metrics are within the range of that category of devices. In other embodiments, other categories of devices can be used and other types of device parameters can be used. In other embodiments, an ML model can be trained to classify devices into multiple device categories by using the collected operational characteristics and metrics as input signals to a supervised or semi-supervised machine learning (ML) model and using the known categories of known devices as training labels.

[0057] In another example, the device evaluator 134 may assign a trust level to the client device 110 based on operating characteristics and metrics. For example, the device evaluator 134 may compare each operating characteristic or metric to a corresponding value or range of values indicative of a trusted device. The device evaluator 134 may assign a trust level based on the number of operating characteristics and metrics within and / or corresponding thresholds of the trusted range.

[0058] The device evaluator 134 determines whether the client device 110 is a trusted device (206) based on the evaluation. The device evaluator 134 may determine whether the client device 110 is a trusted device based on the trust level assigned to the client device 110. For example, the device evaluator 134 may access a trust threshold from a database, for example, and compare the trust level to the trust threshold. If the trust level meets (e.g., reaches or exceeds) the threshold, the device evaluator 134 may determine that the client device 110 is a trusted device. If the trust level does not meet the threshold, the device evaluator 134 may determine that the client device 110 is not a trusted device. In some embodiments, the threshold may be set by a user of the trust token that uses the trust token to detect fraud, e.g., the recipient of the issued trust token. The threshold may also be set by the trust token system 130, e.g., by the trust token issuer 132.

[0059] In another example, the device evaluator 134 may determine whether the client device 110 is a trusted device based on the category assigned to the client device 110. The device evaluator 134 may compare the category assigned to the client device 110 to one or more categories considered trusted and one or more categories considered untrusted. For example, if the device evaluator 134 classifies the client device 110 as a genuine client device, the device evaluator 134 may determine that the client device 110 is a trusted device. If the device evaluator 134 classifies the client device 110 as a simulator or a rooted device, the device evaluator 134 may determine that the client device 110 is not a trusted device. The categories of trusted and untrusted devices may be accessed from a database.

[0060] In another example, the device evaluator 134 can determine whether the client device 110 is a trusted device based on the number of trust tokens requested by the client device 110 within a given time period (e.g., in the most recent hour, day, week, or month, etc.). For example, the device evaluator 134 can access a token threshold from a database, for example, and compare the number of tokens requested by the client device 110 during the given time period with the threshold. If the number of tokens requested by the client device 110 during the given time period is less than the threshold, the device evaluator 134 can determine that the client device 110 is trusted. If the number of tokens requested by the client device 110 during the given time period reaches or exceeds the threshold, the device evaluator 134 can determine that the client device 110 is not trusted. This provides the technical advantage of preventing potentially untrusted devices from being issued trust tokens even if device-level and application-level signals indicate that the device is trusted, thus providing an improved method for detecting untrusted devices.

[0061] In some embodiments, the device evaluator 134 can determine whether the client device 110 is a trusted device based on a combination of an evaluation of device-level fraud detection signals and the number of trust tokens requested during a given time period. For example, the device evaluator 134 can determine that the client device 110 is a trusted device only when the credibility level meets its threshold (or the category assigned to the client device 110 is a trusted category) and the number of trust tokens requested by the client device 110 is less than its threshold.

[0062] If the device evaluator 134 determines that the client device 110 is not a trusted device, the trust token system 130 can refrain from issuing a trust token (208) to the client device 110. In some embodiments, as described above, even if the client device is determined to not be a trusted device, the trust token system 130 can issue a trust token to the client device. In these particular embodiments, this provides the technical advantage of preventing untrusted devices from inferring any information about how the trust token system operates, so that untrusted devices cannot manipulate the system. Thus, this increases the security and integrity of the trust token system.

[0063] If the device evaluator 134 determines that the client device is a trusted device, the trustworthiness of the evaluation application 112 is evaluated (210). The application evaluator 136 of the trust token system 130 can evaluate the trustworthiness of the application 112. The application evaluator 136 can compare the hash of the code of the application 112 received in the request with the hash of the code of the known official build of the application to determine whether the instance of the application 112 installed on the client device 110 is an official build of the application 112. If the hash of the code of the application 112 received in the request matches the hash of the code of the known official build of the application 112, the application evaluator 136 can determine that the instance of the application 112 installed on the client device 110 is an official build of the application 112. If there is no match, the application evaluator 136 can determine that the instance of the application 112 installed on the client device 110 is not an official build of the application 112.

[0064] In some embodiments, the application evaluator 136 determines whether the application 112 is a trusted application based on whether the code of the application 112 has been proven to be non-malicious. For example, a trusted party such as an operating system developer and / or an entity such as an app store from which the application 112 can be downloaded can evaluate the code of the official version of the application 112 to determine whether the official build of the application 112 includes a virus, malware, or other malicious application logic. If no such malicious application logic is found, the trusted party can issue a certificate indicating that the application 112 does not include malicious application logic. If the trusted party discovers malicious application logic, the trusted party can refuse to issue a certificate or issue a certificate indicating that the application 112 includes malicious application logic. The trusted party can evaluate each official build of the application and determine whether to issue a corresponding certificate based on the evaluation. In an example where the trusted party is an app store, instead of issuing a certificate indicating that the application 112 is an official build and does not include malicious application logic, the app store can publish the application in the app store so that the application can be widely distributed. In some examples, instead of issuing a certificate indicating that the application 112 is an official build and does not include malicious application logic, the trusted party can insert a record into a database listing all known trusted applications of the application 112.

[0065] The application evaluator 136 determines whether the application 112 installed on the client device 110 is trusted (212). In some embodiments, the application evaluator 136 determines that the application 112 is trusted in response to determining that the application 112 is an official build. If the application 112 is not an official build, the application evaluator may consider network traffic analysis data that indicates the percentage of network traffic from unofficial builds of applications classified as malicious or invalid. If at least a threshold percentage of the network traffic from the unofficial build of the application is considered malicious or invalid, the application evaluator 136 may determine that any instance of the application 112 that is not an official build is not trusted. If less than the threshold percentage of the network traffic is considered malicious or invalid, the application evaluator 136 may determine that the application 112 is trusted even though the application 112 is not an official build.

[0066] In some embodiments, the application evaluator 136 determines that the application 112 is a trusted application in response to determining that the application 112 is an official build and in response to determining that a certificate indicating that the application 112 does not include malicious application logic has been issued for the build of the application 112 on the client device 110. That is, in this embodiment, the application 112 must meet two criteria.

[0067] If the application evaluator 136 determines that the application 112 is not trusted, the trust token system 130 may not issue a trust token to the client device 110 (208). If the application evaluator 136 determines that the application 112 is trusted, the trust token system generates a trust token for the application 112.

[0068] In this example process, the trust token system 130 issues a trust token only when both the client device 110 and the application 112 are considered trusted. In other examples, the trust token system 130 may issue a trust token when the client device 110 or the application 112 is considered trusted, for example, by evaluating only the client device 110 or the application 112.

[0069] The trust token issuer 132 of the trust token system 130 may generate a trust token for each random number received in the request (214). The trust token issuer 132 may generate a trust token by generating a digital signature based on the value of the random number. The trust token may be a combination of the random number and the digital signature.

[0070] In some embodiments, the trust token issuer 132 generates a trust token by blindly signing the blinded random number using the same blind signature scheme as that used for blinding the random number at the client device 110. In this way, the trust token issuer 132 cannot access the actual plaintext value of the random number, but can generate a digital signature that can later be verified based on the plaintext value of the random number. In this example, the trust token can be a combination of the blinded random number and the blind signature of the blinded random number. As discussed below, blinding the random number so that the trust token issuer cannot access the plaintext value of the random number provides the technical advantage of maintaining the privacy of user data. This is because the trust token system cannot correlate the blinded random number (seen by the trust token issuer when issuing the trust token) with the corresponding unblinded random number (seen when redeeming the issued token), and thus the trust token system cannot infer any user information from the client device by attempting to correlate the issued trust token with the redeemed trust token.

[0071] In some embodiments, the trust token may also include additional data, e.g., in the form of metadata encoded into the blind signature. The encoded metadata can help the trust token issuer 132 compare various token issuance logics and determine which one is most efficient in fraud detection. Additionally, the encoded metadata can indicate the trustworthiness levels assigned to the device 110 and the application 112. The trust token issuer 132 can encode a small amount of information in the form of (one or more) hidden bits and a signature verification key into the blind signature. For example, if the blind signature can be verified by one of four verification keys, the trust token issuer 132 can encode two bits of information into the signature.

[0072] In some embodiments, the trust token issuer 132 can encrypt each trust token using the public key of the client device 110. For example, a request for a trust token can include the public key of the client device 110 as the unique identifier of the client device 110. By encrypting each trust token using the public key of the client device 110, only the client device 110 with the private key can decrypt the trust token. This ensures that the client device 110 submitting the request for the trust token actually has the private key and thus no other client device can obtain the issued trust token. Thus, this provides additional security for the issued trust token by ensuring that only the client device that has submitted the request and actually owns the private key corresponding to the public key can redeem the issued trust token. Thus, by encrypting each trust token using the public key of the client device making the request, the technical advantage of providing additional security for the issued trust token is provided.

[0073] The trust token issuer 132 sends a trust token to the client device 110 (216). If the trust token is encrypted using the public key of the client device 110, the trusted program 114 can decrypt the trust token using the private key corresponding to the public key. If a blinding random number is used, the application 112 (or the trusted program 114) that generates the blinding random number can verify the blind signature of each trust token. The application 112 or the trusted program 114 can verify the blind signature based on the blinding value of the random number it created for the request for the trust token. If the signature is invalid, the application 112 or the trusted program 114 can reject the trust token.

[0074] If the signature is valid, the application 112 or the trusted program 114 can unblind the blinding random number using the blind signature scheme used to blind the random number and blind-sign the blinding random number. Unblinding the random number can include removing the blinding factor from the random number so that the random number is no longer obscured. According to the blind signature scheme, the application 112 or the trusted program 114 can also unblind the blind signature using the blind signature scheme, for example, by removing the blinding factor from the blind signature.

[0075] The application 112 can then store the unblinded version of the trust token for each trust token, which includes the unblinded random number (e.g., the plaintext random number) and the blind signature in blind or unblinded form. That is, the application 112 can update or generate a new version of the trust token that includes the unblinded random number and the blind signature. The application 112 can store the trust token in a secure storage location on the client device 110.

[0076] Figure 3 is a flowchart showing an example process 300 for redeeming a trust token. The process 300 can be implemented, for example, by a trust token system (e.g., Figure 1 the trust token system 130). The operations of the process 300 can also be implemented as instructions stored on a non-transitory computer-readable medium, and executing the instructions by one or more data processing devices can cause the one or more data processing devices to perform the operations of the process 300. For simplicity, the process 300 is described according to Figure 1 the trust token system 130.

[0077] The trust token system 130 receives a request to redeem a trust token from the client device 110 (302). The application 112 running on the client device 110 can issue a request to redeem a trust token in response to initiating a request to a recipient who requests an SRR. For example, when a web browser navigates to a specific website of a publisher, a module of the website or another domain embedded in the website can request the web browser to redeem a trust token to ensure that the client device 110 and the web browser are trusted.

[0078] Application 112 can obtain a trust token from the trust token issued to application 112 and send an exchange request including the trust token to the trust token system 130. The request can also include a public key (or an encrypted hash of the public key) generated by application 112. Continuing with the web browser example, the request can include the public key created by the web browser for the domain of the website presented by the browser and data identifying the domain. The web browser can generate a key pair for each domain accessed by the web browser. Each key pair can include a public key and a corresponding private key.

[0079] If a blinded random number is used to generate the trust token, the trust token sent for exchange can include the unblinded random number and the blind signature instead of the blinded random number. In this way, the trust token system 130 cannot correlate the trust token submitted for exchange with the trust token issued to application 112, which means that the trust token system cannot infer any information about the client device or the user of the client device from the issued and subsequently exchanged trust tokens. Thus, this provides the technical advantage of maintaining user privacy when exchanging trust tokens. Since the trust token system 130 can store data associating the trust token to be issued (and thus the blinded random number) with the confidence level evaluated at the time of issuing the trust token using the device identifier of the client device 110, the trust token system 130 will be able to correlate the recipient of the SRR from the client device 110 with the confidence level. However, using a trust token with an unblinded random number at the time of exchange prevents correlating the trust token with Figure 2 the device-level fraud detection signals and data related to application 112 in operations 204 and 210, because the trust token system 130 cannot correlate the unblinded random number with the blinded random number. Thus, this technique protects the privacy of the user.

[0080] The trust token system 130 attempts to verify the blind signature (304) of the received trust token. For example, the trust token issuer 132 of the trust token system 130 can attempt to verify the blind signature using the blind signature scheme used to blind sign the blinded random number of the issued trust token. The trust token issuer 132 can use the blind signature scheme and the plaintext value of the unblinded random number to verify the blind signature.

[0081] If the blind signature is not successfully verified (306), the trust token system 130 can refrain from exchanging the trust token (308). If the blind signature is successfully verified, the trust token issuer 132 determines whether the trust token has already been exchanged (310). This determination can be performed before, after, in parallel with, or otherwise asynchronously to the verification of the blind signature.

[0082] The trust token issuer 132 can compare the unblinded random number with the unblinded random numbers of previously redeemed trust tokens (e.g., stored in the token redemption database 144). The previously redeemed trust tokens can include redeemed tokens from the client device 110 or from multiple client devices 110. If there is a match between the unblinded random number of the trust token to be redeemed and the unblinded random numbers of the previously redeemed trust tokens, the trust token issuer 132 can determine that the trust token has been previously redeemed. If there is no match between the unblinded random number of the trust token to be redeemed and the unblinded random numbers of the previously redeemed trust tokens, the trust token issuer 132 can determine that the trust token has not been previously redeemed.

[0083] If the trust token has been previously redeemed, the trust token issuer 132 may not redeem the trust token again (308). If the trust token has not been redeemed yet, the trust token issuer 132 can redeem the trust token and issue an SRR to the application 112 (312).

[0084] The SRR can include a set of data that includes a redemption timestamp indicating the time and date the SRR was generated, data identifying the domain of the website identified in the redemption request, a public key created by the browser for that domain, and / or data identifying the trust token system 130 that issued and redeemed the trust token (since there may be multiple trust token systems). The SRR can also include a digital signature of the set of data generated using the private key of the trust token system 130. In this way, the recipient and any other entity can verify that the set of data has not been tampered with by verifying the digital signature using the public key corresponding to the private key of the trust token system 130. Including the public key created by the browser for the domain with the data signed using the private key of the trust token system 130 binds the SRR to that specific domain and browser. The trust token issuer 132 can generate the SRR and send the SRR to the application 112 that requested the redemption of the trust token.

[0085] The trust token issuer 132 can also update the token redemption database 144 to indicate that the trust token has been redeemed (314). For example, the trust token issuer 132 can add the plaintext value of the unblinded random number to the token redemption database 144 to prevent the trust token from being redeemed multiple times.

[0086] Figure 4 is a flowchart showing an example process 400 for processing a request for a redemption record including a signature of a redemption-based trust token. The process 400 can be performed, for example, by a recipient device (e.g., Figure 1implemented by the receiving device 120). The operations of process 400 can also be implemented as instructions stored on a non-transitory computer-readable medium, and execution of the instructions by one or more data processing devices can cause the one or more data processing devices to perform the operations of process 400. For the sake of brevity, process 400 is described according to Figure 1 the trust token system 130 of

[0087] The receiving device 120 receives a request (402) from the client device 110 that includes one or more SRRs. The request can include SRRs generated for a redeemed trust token generated based on the above device and application evaluations. In some embodiments, the request can include additional SRRs generated based on a trust token issued based on an evaluation of user interaction with one or more applications on the client device, e.g., based on an evaluation and determination that the user interaction is a genuine user interaction rather than a simulated user interaction. The (one or more) SRRs of the request can include the (one or more) SRRs generated by the trust token system 130 for the application 112 (or Figure 1 the trusted program 114 in

[0088] The request can also include a digital signature of other content of the request, e.g., including the SRR. The application 112 or the trusted program 114 can generate the digital signature using a private key created by the application 112 for the domain. The private key corresponds to a public key created by the application 112 for the domain. The public key or its cryptographic hash result is included in the SRR. In this way, the request and the SRR are bound to the domain.

[0089] The receiving device 120 attempts to validate each SRR (404). The validation can include attempting to verify the digital signature of the SRR using the public key of the trust token system 130 that generated the SRR. The receiving device 120 can also determine whether the redemption timestamp is within a threshold amount of time from the current time to ensure that the SRR is not obsolete.

[0090] The receiving device 120 determines whether each SRR is validated (406). The receiving device 120 can determine whether an SRR is validated based on whether the digital signature of the SRR is verified and / or whether the redemption timestamp is within a threshold amount of time from the current time. If the digital signature is successfully verified and the redemption timestamp is within a threshold amount of time from the current time, the receiving device 120 can determine that the SRR is validated. If the digital signature is not successfully verified or the redemption timestamp is not within a threshold amount of time from the current time, the receiving device 120 can determine that the SRR is not validated.

[0091] In some embodiments, the recipient device 120 may also use the public key created by the application for the domain to verify the digital signature of the request. For example, the public key (or its cryptographic hash result) may be included in the SRR and / or the request itself. If the digital signature cannot be confirmed, the recipient device 120 may determine that the request is invalid and may not respond to the request.

[0092] If each SRR is not confirmed, the recipient device 120 may not respond to the request (408). For example, the recipient device 120 may ignore the request.

[0093] If each SRR is confirmed, the recipient device 120 responds to the request (410). For example, the recipient device 120 may, based on the request, provide content in response to the request, update data or settings in response to the request, etc.

[0094] Figure 5 is a block diagram of an example computer system 500 that can be used to perform the above operations. System 500 includes a processor 510, a memory 520, a storage device 530, and an input / output device 540. Each of the components 510, 520, 530, and 540 may be interconnected, for example, using a system bus 550. The processor 510 is capable of processing instructions for execution within the system 500. In some embodiments, the processor 510 is a single-threaded processor. In another embodiment, the processor 510 is a multi-threaded processor. The processor 510 is capable of processing instructions stored in the memory 520 or on the storage device 530.

[0095] The memory 520 stores information within the system 500. In one embodiment, the memory 520 is a computer-readable medium. In some embodiments, the memory 520 is a volatile memory unit. In another embodiment, the memory 520 is a non-volatile memory unit.

[0096] The storage device 530 is capable of providing mass storage for the system 500. In some embodiments, the storage device 530 is a computer-readable medium. In various different embodiments, the storage device 530 may include, for example, a hard disk device, an optical disk device, a storage device shared by multiple computing devices over a network (e.g., a cloud storage device), or some other mass storage device.

[0097] The input / output device 540 provides input / output operations for the system 500. In some embodiments, the input / output device 540 may include a network interface device, e.g., an Ethernet card; a serial communication device, e.g., an RS-232 port; and / or a wireless interface device, e.g., one or more of 802.11 cards. In another embodiment, the input / output device may include a driver device configured to receive input data and send output data to an external device 560 (e.g., a keyboard, a printer, and a display device). However, other embodiments may also be used, such as mobile computing devices, mobile communication devices, set-top box TV client devices, etc.

[0098] Although Figure 5 example processing systems have been described herein, embodiments of the subject matter and functional operations described in this specification can be implemented in other types of digital electronic circuitry or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.

[0099] Embodiments and operations of the subject matter described in this specification can be implemented in digital electronic circuitry or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on one or more computer storage media (or on a single computer storage medium) for execution or to control the operation of a data processing apparatus. Alternatively or additionally, the program instructions can be encoded on an artificially generated propagated signal (e.g., a machine-generated electrical, optical, or electromagnetic signal) that is generated to encode information for transmission to a suitable receiver apparatus for execution by the data processing apparatus. A computer storage medium can be a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination or inclusion of one or more of them. Moreover, although a computer storage medium is not a propagated signal, a computer storage medium can be the source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium can also be one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices) or an inclusion of them.

[0100] The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0101] The term "data processing apparatus" encompasses all kinds of devices, equipment, and machines for processing data, including, for example, programmable processors, computers, system-on-chips, or multiple of the foregoing devices, equipment, and machines or combinations thereof. The apparatus may include dedicated logic circuitry, such as, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit). In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program being discussed, such as code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. The apparatus and the execution environment may implement various different computing model infrastructures, such as network services, distributed computing, and grid computing infrastructures.

[0102] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for a computing environment. A computer program may or may not correspond to a file in a file system. The program can be stored in a part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program being discussed, or in multiple coordinated files (e.g., files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to execute on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0103] The processes and logical flows described in this specification can be executed by one or more programmable processors that execute one or more computer programs to perform actions by operating on input data and generating output. The processes and logical flows can also be executed by dedicated logic circuitry, and the apparatus can also be implemented as dedicated logic circuitry, such as, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).

[0104] Processors suitable for executing computer programs include, for example, both general and special purpose microprocessors. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The basic elements of a computer are a processor for performing actions in accordance with the instructions and one or more memory devices for storing the instructions and data. Generally, a computer will also include one or more mass storage devices (such as, for example, magnetic disks, magneto-optical disks, or optical disks) for storing data or operatively coupled to receive data from one or more mass storage devices or to transfer data to one or more mass storage devices or to receive and transfer both. However, a computer need not have such devices. In addition, a computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (such as, for example, a universal serial bus (USB) flash drive), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as including semiconductor memory devices, such as, for example, EPROM, EEPROM, and flash memory devices; magnetic disks, such as, for example, internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0105] To provide for interaction with a user, embodiments of the subject matter described in this specification may be implemented on a computer having a display device (such as, for example, a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (such as, for example, a mouse or a trackball) by which the user may provide input to the computer. Other kinds of devices may also be used to provide for interaction with the user; for example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input received from the user may be in any form, including acoustic, speech, or tactile input. In addition, a computer may interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a web page to a web browser on a client device of the user in response to a request received from the web browser.

[0106] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a backend component (e.g., as a data server), or a middleware component (e.g., an application server), or a frontend component (e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described in this specification), or any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0107] A computing system can include clients and servers. Clients and servers are typically remote from each other and typically interact through a communication network. The relationship between a client and a server arises from computer programs that run on respective computers and have a client-server relationship with each other. In some embodiments, a server transmits data (e.g., an HTML page) to a client device (e.g., for the purpose of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., the result of a user interaction) can be received at the server from the client device.

[0108] Although this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented separately or in any suitable sub-combination in multiple embodiments. In addition, although features may be described above as acting in certain combinations and even initially claimed as such, in some cases, one or more features from a claimed combination can be excluded from the combination, and the claimed combination may cover a sub-combination or a variation of a sub-combination.

[0109] Similarly, although operations are depicted in the figures in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Also, the separation of various system components in the embodiments described above should not be understood as required in all embodiments; it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0110] Accordingly, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the acts recited in the claims can be performed in a different order and still achieve the desired result. Further, the processes depicted in the figures need not be in the particular order or sequential order shown to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

Claims

1. A computer-implemented method for verifying integrity, comprising: receiving, from a client device, a request for one or more trust tokens, the request including: (i) one or more device-level fraud detection signals obtained from the client device or (ii) data representing the code of the application initiating the request; and a respective random number for each of the one or more trust tokens, wherein the random number for each trust token is a blinded random number blinded using a blind signature scheme; determining to issue the one or more trust tokens to the client device based on at least one of (i) the one or more device-level fraud detection signals or (ii) data representing the code of the application; in response to determining to issue the one or more trust tokens to the client device: generating each of the one or more trust tokens using the random number for the trust token; and providing the one or more trust tokens to the client device.

2. The method according to claim 1, wherein, determining to issue the one or more trust tokens to the client device based on at least one of (i) the one or more device-level fraud detection signals or (ii) data representing the code of the application includes: determining that the client device is a trusted device based on the one or more device-level fraud detection signals; determining that the application is a trusted application based on data representing the code of the application; and determining to issue the one or more trust tokens to the client device in response to determining that the client device is a trusted device and the application is a trusted application.

3. The method according to claim 1 or 2, wherein, the data representing the code of the application includes an encrypted hash of the code of the application.

4. The method according to claim 1, wherein, determining to issue the one or more trust tokens to the client device includes: determining that the application is a trusted application based on the code of the application; and determining to issue the one or more trust tokens to the client device in response to determining that the application is a trusted application.

5. The method according to claim 2 or 4, wherein, determining that the application is a trusted application includes: comparing an encrypted hash of the code of the application with an encrypted hash of the code of an official build of the application; and determining that the application is a trusted application in response to the encrypted hash of the code of the application matching the encrypted hash of the code of the official build of the application.

6. The method according to claim 2 or 4, wherein, determining that the application is a trusted application includes determining that a certificate indicating that the application does not include malicious application logic has been issued for the application.

7. The method according to claim 1, wherein, generating each of the one or more trust tokens includes generating a blind signature of the blinded random number for the trust token using a blind signature scheme, wherein the trust token includes the blinded random number and the blind signature of the blinded random number.

8. The method according to claim 7, further comprising: Receive a redemption request from the client device that includes a given trust token for redemption, where the given trust token includes an unblinded random number and a blind signature generated based on a blinded version of the random number; Use the unblinded random number and a blind signature scheme to verify the blind signature of the given trust token; and In response to verifying the blind signature, send a signed redemption record for the given trust token to the client device.

9. The method according to claim 1, wherein, the request further includes the public key of the client device, and the method further includes encrypting each of the one or more trust tokens using the public key of the client device, and wherein providing the one or more trust tokens to the client device includes providing one or more encrypted trust tokens to the client device.

10. The method according to claim 1, wherein, the request includes the device identifier of the client device, and the method further includes maintaining a historical record of the trustworthiness of the client device using the device identifier, wherein determining to issue the one or more trust tokens to the client device includes determining that the client device is a trusted device based on a combination of a device-level fraud detection signal and the historical record of the trustworthiness of the client device.

11. The method according to claim 10, wherein, determining that the client device is a trusted device based on a combination of the device-level fraud detection signal and the historical record of the trustworthiness of the client device includes: determining that the client device is a trusted device based on a combination of a device-level fraud detection signal, the historical record of the trustworthiness of the client device, and the number of trust tokens requested by the client device during a given time period.

12. A system for verifying integrity, comprising: one or more processors; and one or more storage devices storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the method according to any of the preceding claims.

13. A computer-readable medium carrying instructions that, when executed by one or more processors, cause the one or more processors to perform the method according to any one of claims 1 to 11.

14. A system for verifying integrity, comprising: one or more processors; and one or more computer-readable media storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations that include: Receive a request for one or more trust tokens from a client device, the request including: (i) at least one of one or more device-level fraud detection signals obtained from the client device or (ii) data representing the code of the application initiating the request; and A corresponding random number for each of the one or more trust tokens, where the random number for each trust token is a blinded random number blinded using a blind signature scheme; Determine to issue the one or more trust tokens to the client device based on at least one of (i) the one or more device-level fraud detection signals or (ii) data representing the code of the application; In response to determining to issue the one or more trust tokens to the client device: Generate each of the one or more trust tokens using a random number for the trust token; and Provide the one or more trust tokens to the client device.

15. The system according to claim 14, wherein, Determining to issue the one or more trust tokens to the client device based on at least one of (i) the one or more device-level fraud detection signals or (ii) data representing the code of the application includes: Determine that the client device is a trusted device based on the one or more device-level fraud detection signals; Determine that the application is a trusted application based on data representing the code of the application; and In response to determining that the client device is a trusted device and the application is a trusted application, determine to issue the one or more trust tokens to the client device.

16. The system according to claim 14, wherein, The data representing the code of the application includes an encrypted hash of the code of the application.

17. The system according to claim 14, wherein, Determining to issue the one or more trust tokens to the client device includes: Determine that the application is a trusted application based on the code of the application; and In response to determining that the application is a trusted application, determine to issue the one or more trust tokens to the client device.

18. The system according to claim 17, wherein, Determining that the application is a trusted application includes: Compare the encrypted hash of the code of the application with the encrypted hash of the code of the official build of the application; and In response to the encrypted hash of the code of the application matching the encrypted hash of the code of the official build of the application, determine that the application is a trusted application.

19. The system according to claim 17, wherein, Determining that the application is a trusted application includes determining that a certificate indicating that the application does not include malicious application logic has been issued for the application.

20. The system according to claim 14, wherein, Generating each of the one or more trust tokens includes generating a blind signature of a blinded random number for the trust token using a blind signature scheme, wherein the trust token includes the blinded random number and the blind signature of the blinded random number.

21. The system according to claim 20, wherein, The operations include: Receive, from the client device, a redemption request including a given trust token for redemption, wherein the given trust token includes an unblinded random number and a blind signature generated based on a blinded version of the random number; Use the unblinded random number and the blind signature scheme to confirm the blind signature of the given trust token; and In response to confirming the blind signature, send a signed redemption record for the given trust token to the client device.

22. The system according to claim 14, wherein, The request further includes a public key of the client device, the operation further includes encrypting each of the one or more trust tokens using the public key of the client device, and wherein providing the one or more trust tokens to the client device includes providing the client device with one or more encrypted trust tokens.

23. The system according to claim 14, wherein, the request includes a device identifier of the client device, the operation further includes maintaining a history of the trustworthiness of the client device using the device identifier, and wherein determining to issue the one or more trust tokens to the client device includes determining that the client device is a trusted device based on a combination of a device-level fraud detection signal and the history of the trustworthiness of the client device.

24. The system according to claim 14, wherein, determining that the client device is a trusted device based on a combination of a device-level fraud detection signal and the history of the trustworthiness of the client device includes determining that the client device is a trusted device based on a combination of the device-level fraud detection signal, the history of the trustworthiness of the client device, and the number of trust tokens requested by the client device during a given time period.

25. One or more non-transitory computer-readable media storing instructions that, when executed by one or more computers, cause the one or more computers to perform operations, the operations including: receiving, from a client device, a request for one or more trust tokens, the request including: (i) at least one of one or more device-level fraud detection signals obtained from the client device or (ii) data representing the code of the application initiating the request; and a respective random number for each of the one or more trust tokens, wherein the random number for each trust token is a blinded random number blinded using a blind signature scheme; determining to issue the one or more trust tokens to the client device based on at least one of (i) the one or more device-level fraud detection signals or (ii) data representing the code of the application; in response to determining to issue the one or more trust tokens to the client device: generating each of the one or more trust tokens using the random number for the trust token; and providing the one or more trust tokens to the client device.

26. The one or more non-transitory computer-readable media according to claim 25, wherein, determining to issue the one or more trust tokens to the client device based on at least one of (i) the one or more device-level fraud detection signals or (ii) data representing the code of the application includes: determining that the client device is a trusted device based on the one or more device-level fraud detection signals; determining that the application is a trusted application based on data representing the code of the application; and in response to determining that the client device is a trusted device and the application is a trusted application, determining to issue the one or more trust tokens to the client device.

27. The one or more non-transitory computer-readable media according to claim 25, wherein, the data representing the code of the application includes an encrypted hash of the code of the application.

28. The one or more non-transitory computer-readable media according to claim 25, wherein, determining to issue the one or more trust tokens to the client device includes: determining that the application is a trusted application based on the code of the application; and responsive to determining that the application is a trusted application, determining to issue the one or more trust tokens to the client device.

29. The one or more non-transitory computer-readable media according to claim 28, wherein, determining that the application is a trusted application includes: comparing the encrypted hash of the code of the application with the encrypted hash of the code of the official build of the application; and responsive to the encrypted hash of the code of the application matching the encrypted hash of the code of the official build of the application, determining that the application is a trusted application.

30. The one or more non-transitory computer-readable media according to claim 28, wherein, determining that the application is a trusted application includes determining that a certificate indicating that the application does not include malicious application logic has been issued for the application.

31. The one or more non-transitory computer-readable media according to claim 25, wherein, generating each of the one or more trust tokens includes generating a blind signature of a blinded random number for the trust token using a blind signature scheme, wherein the trust token includes the blinded random number and the blind signature of the blinded random number.

32. The one or more non-transitory computer-readable media according to claim 31, wherein, the operations include: receiving, from the client device, a redemption request including a given trust token for redemption, wherein the given trust token includes an unblinded random number and a blind signature generated based on a blinded version of the random number; using the unblinded random number and the blind signature scheme to confirm the blind signature of the given trust token; and responsive to confirming the blind signature, sending a signed redemption record for the given trust token to the client device.

33. The one or more non-transitory computer-readable media according to claim 25, wherein, the request further includes the public key of the client device, the operations further include encrypting each of the one or more trust tokens using the public key of the client device, and wherein providing the one or more trust tokens to the client device includes providing the client device with one or more encrypted trust tokens.

34. The one or more non-transitory computer-readable media according to claim 25, wherein, the request includes the device identifier of the client device, the operations further include maintaining a historical record of the trustworthiness of the client device using the device identifier, wherein determining to issue the one or more trust tokens to the client device includes determining that the client device is a trusted device based on a combination of a device-level fraud detection signal and the historical record of the trustworthiness of the client device.

35. One or more non-transitory computer-readable media according to claim 25, wherein, determining that the client device is a trusted device based on a combination of a device-level fraud detection signal and a history of the credibility of the client device includes: determining that the client device is a trusted device based on a combination of the device-level fraud detection signal, the history of the credibility of the client device, and the number of trust tokens requested by the client device during a given time period.

Images