Patent Description:
Client devices transmit requests and other data over public networks, such as the Internet. These communications can be altered by other parties, such as parties that intercept the communications and/or intermediaries that receive the communications and forward them to other parties. Client devices are also subject to malicious attacks, such as viruses and malware that can send fraudulent requests without the user's knowledge or authorization. In addition, other parties can emulate a client device to send requests that appear to originate from the client device, but actually come from a device of the other parties. The document <CIT>), describes, a separate "identification credential" to be included with a digitally signed document.

Various features and advantages of the foregoing subject matter is described below with respect to the figures. The invention to which this European patent relates is defined by the independent claims. Further embodiments are described by the dependent claims.

In general, systems and techniques described in this document can provide a secure communication channel for electronic communications between a client device and multiple recipients. The client device can generate communications, e.g., electronic messages or requests, that include an attestation token that can be used by recipients of the communication to verify the authenticity and integrity of the communication. The attestation token can include a set of data and a digital signature that is generated based on the set of data. In this way, the recipient can verify that the set of data has not been modified, e.g., during transmission or by an intermediary, by verifying the digital signature using the received set of data and the sender's public key.

Some communications can be transmitted to multiple recipients and the data for each recipient can be different and/or sensitive. In such cases, including the recipient data in the attestation token can increase the data size of the communication that is sent to each recipient and subject the recipient data to other recipients. To reduce data size for each recipient and provide enhanced security of each recipient's data, recipient-specific data can be transmitted in the form of attachment elements that are in addition to the attestation token, but not part of the set of data of the attestation token used to generate the digital signature. In this way, the attachment elements that are not intended for a recipient can be removed from the communication without breaking the digital signature.

<FIG> is a block diagram of an environment <NUM> that provides a secure channel for communications between client devices and multiple recipients. The example environment <NUM> includes a data communication network <NUM>, such as a local area network (LAN), a wide area network (WAN), the Internet, a mobile network, or a combination thereof. The network <NUM> connects client devices <NUM>, a primary recipient device <NUM>, secondary recipient devices <NUM>, and an integrity system <NUM>. The environment <NUM> can include many client devices <NUM>, primary recipient devices <NUM>, secondary recipient devices <NUM>, and integrity systems <NUM>.

The recipient devices <NUM> and <NUM> are devices, e.g., computers, of recipients of communications <NUM> transmitted by client devices <NUM>. The types of recipients can vary depending on various use cases as the secure communication techniques described in this document can be applied to many different use cases. For example, the recipients can be entities that store and/or make use of user data of users of the client devices <NUM>. In this example, the client devices <NUM> can transmit secure communications <NUM> to the primary recipient devices <NUM> to instruct the recipients on what data can be stored and how the data can be used.

In another example, the recipients can be entities to which applications running on the client devices <NUM> report events. For example, the recipient devices <NUM> and/or <NUM> can be aggregation servers that aggregate event data, determine metrics, e.g., statistics, and report the metrics.

In another example, the recipients are entities that distribute content, e.g., digital components, to the client devices <NUM>. In this example, the primary recipient device <NUM> can be a supply-side platform (SSP) and the secondary recipients <NUM> can be demand-side platforms (DSPs). In general, an SSP is a technology platform implemented in hardware and/or software that automates the process of obtaining digital components for the resources and/or applications. A publisher of electronic resources (e.g., web pages) can use an SSP to manage the process of obtaining digital components for presentation with its electronic resources. In general, a DSP is a technology platform implemented in hardware and/or software that automates the process of distributing digital components for presentation with the resources and/or applications. A DSP can interact with multiple supply-side platforms SSPs on behalf of digital component providers to provide digital components for presentation with the resources and/or applications of multiple different publishers.

As used throughout this document, the phrase "digital component" refers to a discrete unit of digital content or digital information (e.g., a video clip, audio clip, multimedia clip, image, text, or another unit of content). A digital component can electronically be stored in a physical memory device as a single file or in a collection of files, and digital components can take the form of video files, audio files, multimedia files, image files, or text files and include advertising information, such that an advertisement is a type of digital component. For example, the digital component may be content that is intended to supplement content of a web page or other resource presented by the application <NUM>. More specifically, the digital component may include digital content that is relevant to the resource content (e.g., the digital component may relate to the same topic as the web page content, or to a related topic). The provision of digital components can thus supplement, and generally enhance, the web page or application content.

A client device <NUM> is an electronic device that is capable of communicating over the network <NUM>. Example client devices <NUM> include personal computers, mobile communication devices, e.g., smart phones, and other devices that can send and receive data over the network <NUM>. A client device can also include a digital assistant device that accepts audio input through a microphone and outputs audio output through speakers. The digital assistant can be placed into listen mode (e.g., ready to accept audio input) when the digital assistant detects a "hotword" or "hotphrase" that activates the microphone to accept audio input. The digital assistant device can also include a camera and/or display to capture images and visually present information. The digital assistant can be implemented in different forms of hardware devices including, a wearable device (e.g., watch or glasses), a smart phone, a speaker device, a tablet device, or another hardware device. A client device can also include a digital media device, e.g., a streaming device that plugs into a television or other display to stream videos to the television.

A client device <NUM> typically includes applications <NUM>, such as web browsers and/or native applications, to facilitate the sending and receiving of data over the network <NUM>. A native application is an application developed for a particular platform or a particular device (e.g., mobile devices having a particular operating system). Publishers can develop and provide, e.g., make available for download, native applications to the client devices <NUM>. A web browser can request a resource from a web server that hosts a website of a publisher, e.g., in response to the user of the client device <NUM> entering the resource address for the resource in an address bar of the web browser or selecting a link that references the resource address. Similarly, a native application can request application content from a remote server of a publisher.

An application <NUM> can generate and send communications <NUM> to recipients, e.g., the primary recipient device <NUM>. The application <NUM> can interact with a trusted program <NUM> to generate an attestation token <NUM> and attachment elements <NUM> for a communication <NUM>. The trusted program <NUM> can include trusted code from a reliable source that is difficult to falsify. For example, the trusted program <NUM> can be an operating system, a portion of an operating system, a web browser, etc. Generally, the trusted program <NUM> is difficult to infiltrate, and the amount of time and effort that a perpetrator would need to expend to tamper with the trusted program <NUM> is prohibitively high, e.g., not economically viable for the perpetrator. Additionally, because the trusted program <NUM> is provided and maintained by a reliable source, any vulnerabilities that arise can be addressed by the source.

The trusted program <NUM> can be local to client device <NUM>. For example, the trusted program <NUM> can be a device driver of the operating system of client device <NUM>. In some implementations, the trusted program <NUM> operates entirely locally to client device <NUM>, reducing the need to transmit user information. In some implementations, the trusted program <NUM> can operate locally to client device <NUM> and over a network, such as network <NUM>. For example, the trusted program <NUM> can be a web browser that is installed on client device <NUM> and transmits and receives information over the network <NUM>.

The application <NUM> can include software modules, tools, interfaces, or other components that manage the generation and transmission of communications. In this example, the application <NUM> includes software development kits (SDKs) <NUM> and <NUM>. Other software components, such as application programming interfaces (APIs) can also be used.

The application <NUM> includes a primary recipient SDK <NUM> that can be developed and distributed by the primary recipient corresponding to the primary recipient device <NUM>. For example, an SSP can provide SDKs for inclusion in applications (e.g., native applications, web applications, web browsers, etc.). In this example, the primary recipient SDK <NUM> can generate, as communications <NUM>, requests for digital components from the primary recipient device <NUM>.

The application <NUM> also includes a respective secondary recipient SDK <NUM> for each of one or more secondary recipients having a secondary recipient device <NUM>. The secondary recipient SDK <NUM> can obtain recipient data for inclusion in the communications sent by the primary recipient SDK <NUM> to the primary recipient device <NUM>. As described in more detail below, the primary recipient device <NUM> can send the recipient data for each recipient to its corresponding secondary recipient device <NUM>. An example process for generating and sending communications to the recipient devices <NUM> and <NUM> are illustrated as stages <NUM>-<NUM> in <FIG>.

At stage <NUM>, when the application <NUM> or its primary recipient SDK <NUM> is generating a communication <NUM> to send to the primary recipient device <NUM>, the primary recipient SDK <NUM> obtains recipient data from one or more secondary recipient SDKs <NUM> corresponding to one or more recipients. The recipient data for each recipient can be data that is specific to that recipient and can vary based on the implementation. In an SSP and DSP example, the recipient data for a recipient device can include digital component selection signals for use in selecting digital components and/or fraud detection signals that can be used by the recipient to determine whether the client device <NUM> is operating as normal or trusted device. The fraud detection signals can include data representing operating characteristics or metrics of the client device that can be used to determine whether a client device is compromised or whether the client device is operating as a normal client device or an emulated client device. Certain operating characteristics and metrics are often different for genuine client devices relative to emulators. In some implementations, the fraud detection signals include application-level fraud detection signals that include operating characteristics and metrics of the application <NUM>.

Each secondary recipient SDK <NUM> can collect its recipient data and provide the recipient data to the primary recipient SDK <NUM>. In some implementations, each secondary recipient SDK <NUM> encrypts its recipient data prior to providing the recipient data to the primary recipient SDK <NUM>. For example, each secondary recipient SDK <NUM> can encrypt its data using an encryption algorithm and public key such that other recipients, e.g., the primary recipient device <NUM> would not be able to access the plaintext value of the recipient data. Plaintext is text that is not computationally tagged, specially formatted, or written in code, or data, including binary files, in a form that can be viewed or used without requiring a key or other decryption device, or other decryption process. In other implementations, e.g., if the recipient data is not sensitive, the secondary recipient SDK <NUM> can send the plaintext recipient data to the primary recipient SDK <NUM>. In some implementations, the trusted program <NUM> or the primary recipient SDK <NUM> can encrypt the recipient data for each recipient. Encrypted or not, the recipient data can be in the form of a byte array.

At stage <NUM>, the primary recipient SDK <NUM> submits a request to the trusted program <NUM> to generate an attestation token <NUM> for the communication <NUM>. The primary recipient SDK <NUM> can send, with the request, the recipient data received from each secondary recipient SDK <NUM> and, for each recipient, a resource locator for the recipient. The resource locator can act as a key for the recipient data and be in the form of the eTLD+<NUM> of a domain of the recipient. The eTLD+<NUM> is the effective top-level domain (eTLD) plus one level more than the public suffix. An example eTLD+<NUM> is "example. com" where ". com" is the top-level domain.

This request can also include any payload data to be included in the attestation token <NUM>, e.g., data that is common to all recipients, instructions for the recipients, etc. The primary recipient SDK <NUM> can generate the request using one or more API calls to the trusted program <NUM>.

At stage <NUM>, the trusted program <NUM> generates the attestation token <NUM> and an attachment element <NUM> for each recipient for which recipient data was received and provides the attestation token <NUM> and attachment elements <NUM> to the primary recipient SDK <NUM>. The attestation token <NUM> can include a set of data <NUM> and a digital signature <NUM> of the set of data.

The set of data <NUM> can include a public key of the client device <NUM> (e.g., a public key of the application <NUM>) sending the request, a token creation time that indicates a time at which the attestation token <NUM> is created, the payload data, and/or one or more integrity tokens provided by one or more integrity systems <NUM>. This token creation time can be a high resolution timestamp (e.g., accurate to the second, to the millisecond, or to the microsecond).

The application <NUM> can generate and maintain one or more pairs of related encryption keys including a private key and a public key that corresponds to, and is mathematically linked to, the private key. In some implementations, the keys are provided to the application <NUM> from another application or device. Data that is digitally signed using the private key can only be verified using the corresponding public key. Similarly, data that is encrypted using the public key can only be decrypted using the private key. The encryption keys can be cycled periodically, per request, per application <NUM>, etc. to prevent the public key from being used to track particular client devices <NUM>, e.g., particular users of the client devices <NUM>.

The trusted program <NUM> generates a digital signature <NUM> of the set of data <NUM> using the private key so that recipients can verify that the set of data <NUM> was not changed after it was generated by the trusted program and for proving that the request originated at the client device <NUM>. In some implementations, the trusted program <NUM> uses an Elliptic Curve Digital Signature Algorithm (ECDSA) to generate the digital signature, but other signature techniques (e.g., RSA) can also be used. The corresponding public key is provided with the attestation token <NUM> so that the recipients of the attestation token <NUM> can use the public key to verify the digital signature <NUM> of the set of data <NUM>. The trusted program <NUM> can generate the digital signature by signing over the set of data <NUM> using the private key.

The integrity tokens can include an application integrity token and/or a device integrity token. The application integrity token indicates that the application <NUM> has been evaluated by an integrity system <NUM> and has been deemed trusted by the integrity system <NUM>. Similarly, the device integrity token indicates that the client device <NUM> has been evaluated by an integrity system <NUM> and has been deemed trusted by the integrity system <NUM>. The integrity system <NUM> can evaluate the application <NUM> and/or client device <NUM> based on fraud detection signals obtained from the client device <NUM> and/or application <NUM>, e.g., by an in-application component.

An integrity token can include a token creation time that indicates a time at which the integrity token was created, the public key included in the attestation token <NUM> (e.g., a device public key of the client device <NUM>), the verdict (e.g., whether the application <NUM> or client device <NUM> is trusted), and/or a digital signature of the rest of the integrity token (e.g., the token creation time, the device public key, and/or the device/application verdict). Using a digital signature of the data including the public key binds the integrity token to the public key and therefore to the client device <NUM> and/or the application <NUM>.

The digital signature of the integrity token can be generated by a private key owned and securely stored by the integrity system <NUM>. The digital signature is publicly verifiable by a public key corresponding to the private key owned and securely stored by the integrity system <NUM>. The use of the private and public keys of the integrity system <NUM> to digitally sign the integrity tokens and verify these digital signatures in combination with the private and public keys of the client device <NUM> to digitally sign the attestation token <NUM> and verify the signatures of the attestation tokens <NUM> provide a secure communication channel and establish a chain of trust between the entities of <FIG>.

The attachment element <NUM> for a recipient can include a binding, the recipient data for the recipient, the resource locator for the recipient (e.g., the eTLD+<NUM> for the recipient, as described above), and a digital signature generated based on the other data, e.g., based on the binding, the recipient data, and the resource locator. The binding cryptographically binds the attachment element <NUM> to the attestation token <NUM> so that the attachment element <NUM> cannot be sent with other attestation tokens <NUM> without being detected.

In some implementations, the binding is a cryptographic hash of the digital signature of the attestation token <NUM>. For example, after generating the digital signature for the attestation token <NUM>, the trusted program <NUM> can compute the cryptographic hash of the digital signature using a cryptographic function (e.g., SHA256). That is, the trusted program <NUM> can apply a cryptographic hash function to the digital signature of the attestation token <NUM>. The trusted program <NUM> can also truncate the cryptographic hash to further reduce data size of the communication <NUM>, e.g., by truncating the hash to <NUM> bytes. As described below, during verification of the attestation token <NUM> and the attachment elements <NUM>, the recipient can verify the digital signature of the attestation token <NUM>, calculate the hash of the digital signature included in a received attestation token and compare that hash to the binding. If the digital signature is verified successfully and the hash values do not match, then the attachment element <NUM> was not generated for that attestation token <NUM> and the verification of the attachment element <NUM> fails.

In some implementations, the binding can be a cryptographic hash of the attestation token <NUM> itself. However, this can require additional processing by the trusted program <NUM> relative to using the cryptographic hash of the digital signature, as the attestation token <NUM> will typically have a larger data size than the digital signature of the attestation token <NUM>.

The digital signature of the attachment element <NUM> for a recipient can be generated using the same private key used to generate the digital signature of the attestation token <NUM>. In this way, the recipient can use the public key to verify the digital signature of the attachment element <NUM>. In other implementations, a different private key can be used to generate the digital signature for the attachment elements <NUM> and the corresponding public key can be included in the attestation token <NUM> or otherwise provided to the recipients.

At stage <NUM>, the primary recipient SDK <NUM> generates and transmits the communication <NUM> to the primary recipient device <NUM> over the network <NUM>. As shown in <FIG>, the communication <NUM> can include one attestation token <NUM> for all recipients and, for each individual recipient, an attachment element <NUM>. A communication <NUM> can include any number of attachment elements, e.g., zero or more attachment elements.

At stage <NUM>, the primary recipient device <NUM> generates and transmits individual communications <NUM> to each secondary recipient device <NUM> to which the communication <NUM> is intended. Although not shown in <FIG>, the individual communications <NUM> can also be transmitted over the network <NUM> or another network. The primary recipient device <NUM> can access the attachment elements <NUM> of the received communication <NUM> and identify the resource locator of each attachment element <NUM>. This instructs the primary recipient device <NUM> where to send the attachment element <NUM>.

For each attachment element <NUM> of the communication <NUM>, the primary recipient device <NUM> can generate an individual communication <NUM> that includes the attestation token <NUM> and the attachment element <NUM>. For example, the communication <NUM> for secondary recipient device <NUM>-<NUM> includes the attestation token <NUM> and the attachment element <NUM>-<NUM> for the recipient corresponding to the attachment element <NUM>-<NUM>. The primary recipient device <NUM> can generate the individual communication <NUM> for a given recipient by removing the attachment elements for all of the other recipients.

As the digital signature of the attestation token <NUM> is not generated based on any of the attachment elements <NUM>, each recipient can still verify the digital signature of the attestation token <NUM> even without receiving the other attachment elements for the other recipients. By removing the attachment elements <NUM> that are not for a given recipient and including the attestation token <NUM> and only the attachment element <NUM> for the given recipient in the communication <NUM>, the data size of the communication <NUM> is substantially reduced. This reduces bandwidth consumption, reduces data storage at the secondary recipient devices <NUM>, and requires less processing to verify the attestation token <NUM> and attachment element <NUM>.

For example, if the communications <NUM> are related to user privacy settings or controls, the recipients can be required to store the attestation tokens <NUM> for a particular time period. If the attestation tokens <NUM> included the recipient data for multiple recipients rather than using attachment elements <NUM> for the individual recipients, the data storage requirements would be much greater. Verification of such attestation tokens that include the recipient data for multiple recipients would require substantially more processing to scan all of the recipient data to verify the digital signature. By using separate attachment elements for each recipient, the secondary recipient devices <NUM> can scan only the other data of the attestation token <NUM> and the individual attachment element <NUM> for that recipient, resulting in fewer CPU cycles per communication <NUM>. Aggregated over thousands or millions of communications, e.g., per day, the computational and data storage savings are substantial.

This also enables the secondary recipient devices <NUM> to respond much faster to the communications <NUM>, which is critical in implementations related to content, e.g., digital component, distribution. In such cases, a response is typically required within a few milliseconds. By reducing the processing needed for verification, the secondary recipient computing devices <NUM> can verify the integrity of the communications <NUM> and still provide responses within the time requirements.

<FIG> is a flow diagram that illustrates an example process <NUM> for generating and transmitting a communication that includes an attestation token and attachment elements. Operations of the process <NUM> can be implemented, for example, by the client device <NUM> of <FIG>. Operations of the process <NUM> can also be implemented as instructions stored on one or more computer readable media which may be non-transitory, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>.

Recipient data is obtained (<NUM>). An application <NUM> executing on a client device <NUM> can obtain recipient data for each one or more recipients of a communication being generated by the application <NUM>. For example, as described above, a primary recipient SDK <NUM> can obtain recipient data for a recipient from a secondary recipient SDK <NUM> of the recipient. The recipient data for each recipient can be different from the recipient data for each other recipient. Each recipient's SDK can collect its data and provide the data to the primary recipient SDK <NUM>.

An attestation token is generated (<NUM>). A trusted program <NUM> of the client device <NUM> can generate the attestation token in response to a request from the application <NUM>. The request can include payload data for the communication, the recipient data for each recipient, and a resource locator (e.g., eTLD+<NUM>) for each recipient. As described above, the attestation token can include a set of data that includes a public key of the client device <NUM> or application <NUM>, a token creation time, the payload data. The attestation token can also include a digital signature generated based on the set of data and using a private key that corresponds to the public key.

Attachment elements are generated (<NUM>). The trusted program <NUM> can generate an attachment element for each recipient using the recipient data for the recipient received in the request. As described above, the attachment element for a recipient can include a binding, the recipient data for the recipient, and the resource locator for the recipient. The attachment element for the recipient can also include a digital signature generated based on the binding, the recipient data for the recipient, and the resource locator for the recipient. The trusted program <NUM> can generate the digital signature for each attachment element using the private key used to sign the attestation token. For example, the trusted program <NUM> can generate the signature for an attachment element by signing over the binding, the recipient data, and the resource locator using the private key. As described above, the binding for each attachment element can be a cryptographic hash of the digital signature of the attestation token to bind all of the attachment elements to the attestation token.

The communication is transmitted (<NUM>). The application <NUM> can transmit a communication that includes the attestation token and the attachment elements to a recipient, e.g., over a network. As described above, a primary recipient, e.g., a first recipient or intermediary, can receive the communication and generate individual communications for each intended recipient of the communication. The individual communications can each include the attestation token and a single attachment element for the recipient of the individual communication. In another example, the application <NUM> can generate and send individual communications that each include the attestation token and an attachment element for a recipient of the individual communication.

<FIG> is a flow diagram that illustrates an example process <NUM> for verifying the integrity of a communication is valid and whether to respond to the communication. Operations of the process <NUM> can be implemented, for example, by a recipient device <NUM> or <NUM> of <FIG>. Operations of the process <NUM> can also be implemented as instructions stored on one or more computer readable media which may be non-transitory, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>.

A communication is received (<NUM>). The communication can include an attestation token and an attachment element. For example, a recipient device can receive the communication from a client device <NUM> or primary recipient device <NUM>.

The integrity of the communication is verified (<NUM>). For example, the recipient device can classify the integrity as being valid or invalid based on an attempt to verify the communication. This verification can include verifying the attestation token and the attachment element. The integrity of the request can be invalid if any data in the set of data changed between the time at which the attestation token was created, a duration of time between the token creation time and the time at which the request was received exceeds a threshold, the integrity token is invalid, or the attachment element is not bound to the attestation token. An example process for verifying the integrity of a communication is illustrated in <FIG> and described below.

If the integrity of the communication is classified as invalid, e.g., verification fails, the recipient device does not respond to the communication (<NUM>). For example, the recipient device can ignore the communication, delete the communication, or otherwise not take the requested action of the communication.

If the integrity of the communication is classified as valid, e.g., the verification succeeds, the recipient device responds to the communication (<NUM>). For example, if the communication is to update user privacy settings, the recipient device can update the user privacy settings in response to successfully verifying the communication. If the communication is a request for a digital component, the recipient device can select a digital component and provide data for the digital component in response to successfully verifying the communication. Thus, the response can vary based on the implementation and the data of the communication.

<FIG> is a flow diagram that illustrates another example process <NUM> for verifying the integrity of a communication using an attestation token and an attachment element. Operations of the process <NUM> can be implemented, for example, by a recipient device <NUM> or <NUM> of <FIG>. Operations of the process <NUM> can also be implemented as instructions stored on one or more computer readable media which may be non-transitory, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>.

An attestation token and an attachment element of a communication are accessed (<NUM>). A recipient device can receive the communication and identify the attestation token and the attachment element in the communication. The recipient device can extract the attestation token and the attachment element from the communication.

The attestation token is verified (<NUM>). The recipient device can verify the attestation token using the token creation time, the digital signature, and/or the integrity token(s) included in the attestation token. In this implementation, all three verifications are performed using constituent operations <NUM>-<NUM>, but fewer verifications can be performed in other implementations. In addition, the verifications can be performed in different orders or in parallel.

The token creation time of the attestation token is verified (<NUM>). As described above, the attestation tokens can include a token creation timestamp that indicates a time at which the attestation token was created. The token creation time can be used to determine whether a communication that includes the attestation token is a new or recent request. For example, the recipient device can compare the token creation time to a current time or a time at which the attestation token was received to determine whether the token creation time is within a threshold duration of the time at which the communication was received. If so, the token creation time is verified. If not, the attestation token is considered stale and, in response, the recipient device can classify the integrity of the communication as being invalid (<NUM>). The threshold duration can be, for example, one day, three days, one week, or another appropriate duration.

The token creation time can also be used to detect replay attacks. For example, if multiple requests having the same set of data, including the same token creation time, are received, the recipient can determine that the communications are duplicates and/or that the requests are part of a replay attack.

If the token creation time is verified successfully, the digital signature is verified (<NUM>). The digital signature can be verified to ensure that the set of data of the attestation token has not changed since the attestation token was created. For example, even a minor change to the set of data would result in verification of the digital signature failing. The recipient device can attempt to verify the digital signature using the set of data of the received attestation token and the public key included in the attestation token. If the digital signature cannot be verified using the public key, a determination can be made that the data in the set of data has been modified. For example, such data may have been modified by an entity that intercepted the request or an intermediary. If the digital signature is verified using the public key, a determination can be made that the data in the set of data of the attestation token has not been modified. If the digital signature is not verified successfully, the recipient device can classify the integrity of the communication as being invalid (<NUM>).

If the digital signature is verified successfully, the integrity token is verified (<NUM>). As described above, an integrity token can include a token creation time that indicates a time at which the integrity token was created, the public key of the client device <NUM> that requested the integrity token, the verdict (e.g., whether the application <NUM> or client device <NUM> is trusted), and/or a digital signature of the rest of the integrity token (e.g., the token creation time, the public key, and/or the verdict. The digital signature of the integrity token can be generated by a private key owned and securely stored by the integrity system <NUM>. The digital signature is publicly verifiable by a public key corresponding to the private key owned and securely stored by the integrity system <NUM>.

To verify integrity token, the recipient device can determine whether the verdict of the integrity token is valid, whether the public key of the integrity token matches the public key of the attestation token, and whether the token creation time of the integrity token is within a threshold duration of the time at which the communication was received. If the verdict indicates that the client device or application is not trusted, the public keys do not match, or the token creation time of the integrity token is not within the threshold duration of the time at which the communication was received, a determination is made that the integrity token is invalid and the integrity of the request is classified as invalid (<NUM>). If the verdict indicates that the client device or application is trusted and the public keys match, a determination can be made that the integrity token in valid.

This determination can also include verifying the digital signature of the integrity token. As described above, the integrity system <NUM> can digitally sign the data of the integrity token using a private key of the integrity system. The integrity system <NUM> can provide a public key that corresponds to this private key to recipients that may receive integrity tokens generated by the integrity system. Each recipient of the request can use this public key to verify the digital signature of the integrity token which, if successful, indicates that the data of the integrity token has not been modified since it was created. In this example, if the verdict is trusted, the public keys match, and the digital signature of the integrity token is verified successfully, a determination can be made that the integrity token in valid. If one or more verifications fail, the recipient device can classify the integrity of the integrity token as invalid.

If the token creation time, the digital signature of the attestation token, and the integrity token are all verified successfully, the recipient device can classify the integrity of the attestation token as valid and verify the attachment element (<NUM>). If any of the verifications fail, the recipient device can classify the integrity of the communication as invalid (<NUM>).

The recipient device can verify the attachment element by verifying the digital signature of the attachment element, verifying the binding, and verifying that the resource locator of the attachment element matches a resource locator of the recipient. An example process for verifying an attachment element is illustrated in <FIG> and described below.

The recipient device can verify the attestation token and the attachment element in any order, or in parallel. If both are verified successfully, the recipient device can classify the communication as valid (<NUM>). In turn, the recipient device can respond to the communication, as described above.

<FIG> is a flow diagram that illustrates an example process <NUM> for verifying the integrity of an attachment element. Operations of the process <NUM> can be implemented, for example, by a recipient device <NUM> or <NUM> of <FIG>. Operations of the process <NUM> can also be implemented as instructions stored on one or more computer readable media which may be non-transitory, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>.

An attachment element is accessed (<NUM>). For example, the recipient device can extract the attachment element from a received communication that includes an attestation token and the attachment element, as described above. The attachment element for a recipient can include a binding, the recipient data for the recipient, the resource locator for the recipient (e.g., the eTLD+<NUM> for the recipient), and a digital signature generated based on the other data, e.g., based on the binding, the recipient data, and the resource locator.

The recipient device verifies the digital signature (<NUM>). The digital signature can be verified to ensure that the data of the attachment element has not changed since the attachment element was created. For example, even a minor change to the data in the attachment element would result in verification of the digital signature failing. The recipient device can attempt to verify the digital signature of the attachment element using the set of data of the received attachment element and the public key included in the attestation token. If the digital signature cannot be verified using the public key, a determination can be made that the data in the set of data has been modified. For example, such data may have been modified by an entity that intercepted the request or an intermediary. If the digital signature is verified using the public key, a determination can be made that the data in the attachment element has not been modified. If the digital signature is not verified successfully, the recipient device can classify the attachment element as being invalid (<NUM>).

If the digital signature is verified successfully, the recipient device verifies the binding (<NUM>). The binding of an attachment element can be a hash value of the digital signature of the attestation token computed using a cryptographic hash function and the digital signature of the attestation token. In this way, the attachment element has to be received in a communication that includes the attestation token to which the attachment element is bound in order for this verification to succeed.

To verify the binding, the recipient device can compute a verification hash value using the same cryptographic hash function used to generate the binding and the digital signature included in the received attestation token. The recipient device can then compare this verification hash value to the hash value of the binding. If these two hash values do not match, then the recipient device can determine that the digital signature in the received attestation token is not the digital signature used to create the binding. In turn, the recipient device can determine that the attachment element is not bound to the attestation token and classify the attachment element as invalid (<NUM>).

For example, a malicious entity may attempt to include the attachment element in a different attestation token than the attestation token for which the attachment element was created. In this example, the digital signature of the malicious entity's attestation token would not match the digital signature of the valid attestation token and thus, the verification of the binding would fail. This ensures that the attachment element is only used with its correct attestation token.

In some implementations, the binding is a hash value of the attestation token computed using a cryptographic hash function and the received attestation token. In this example, verifying the attachment element can include computing a verification hash value using the cryptographic hash function and the attestation token and determining that the verification hash value matches the hash value of the binding.

In either example, if the hash value of the binding matches the verification hash value, the recipient device can verify the resource locator of the attachment element (<NUM>). The recipient device can determine whether the resource locator of the attachment element matches a resource locator of the recipient. That is, the recipient device can ensure that the attachment element was intended for the recipient based on the resource locator in the attachment element. If the resource locator in the attachment element does not match a resource locator of the recipient, the recipient device can classify the attachment element as being invalid (<NUM>).

If the digital signature of the attachment element, the binding of the attachment element, and the resource locator of the attachment element are all verified successfully, the recipient device can classify the integrity of the attachment element as valid (<NUM>). If any of the verifications fail, the recipient device can classify the integrity of the attachment element as invalid (<NUM>). The recipient device can perform the verifications in any order or in parallel.

<FIG> is a block diagram of an example computer system <NUM> that can be used to perform operations described above. The system <NUM> includes a processor <NUM>, a memory <NUM>, a storage device <NUM>, and an input/output device <NUM>. Each of the components <NUM>, <NUM>, <NUM>, and <NUM> can be interconnected, for example, using a system bus <NUM>. The processor <NUM> is capable of processing instructions for execution within the system <NUM>. In some implementations, the processor <NUM> is a single-threaded processor. In another implementation, the processor <NUM> is a multi-threaded processor. The processor <NUM> is capable of processing instructions stored in the memory <NUM> or on the storage device <NUM>.

Claim 1:
A computer-implemented method comprising:
obtaining (<NUM>), by a client device, respective recipient data for multiple recipients; generating (<NUM>), by the client device, an attestation token comprising a set of data and a digital signature of the set of data;
generating (<NUM>), by the client device, an attachment element for each recipient of the multiple recipients, each attachment element comprising the respective recipient data for the recipient and a binding that cryptographically binds the attachment element to the attestation token; and
sending (<NUM>), by the client device, a communication that includes the attestation token and the attachment elements to at least one recipient.