Cryptographically implemented device data restrictions

Abstract

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for cryptographically implemented data restrictions. One of the methods includes receiving a data access request prompted by user interaction on an application executing on the client device; transmitting an attestation nonce request to a secure processor of the client device; generating a cryptographic key pair and an attestation nonce; transmitting data comprising (i) the public key from the cryptographic key pair and (ii) the generated attestation nonce; validating an attestation packet received from the server in response to the transmission of the data; in response to validating the attestation packet, transmitting data restrictions specified by the user of the client device; generating a signed policy including the data restrictions; and transmitting the signed policy to the server specifying the data restrictions for the server to abide by.

Description

Attorney Docket No. 56113-0827WO1CRYPTOGRAPHICALLY IMPLEMENTED DEVICE DATA RESTRICTIONS TECHNICAL FIELD

[0001] This specification relates to systems and methods for cryptography -based management and processing of device-specified restrictions related to data provided to components of a network.BACKGROUND

[0002] User devices, such as smartphones, allow application clients to provide a part, or all, of device data for processing or storage in remote servers. For example, a user of an image processing application executing on a user device can agree to the remote server's request for data (e.g., providing images stored on the device) for processing by the server (e.g., to assist in training of one or more image processing models).

[0003] A user of a user device can indicate whether to provide data for processing or storage. This process can be a binary choice — either the user can indicate to provide the data or the user can indicate not to provide the data. Once the user agrees to provide the data, however, there are generally no “use” restrictions or term-limits on the data. As a result, once this data is provided, a receiving server may process or store the data without any constraints or limitations.SUMMARY

[0004] This specification describes technologies for cry ptographically implementing restrictions on device data that is provided to third party remote servers. For example, when confronted with a request for device data from a third party server, a user can provide a set of one or more restrictions for the use or storage of the provided data. A set of one or more restrictions can be cryptographically signed in a policy with the device data itself. To access the included device data, a receiving server cryptographically operates on the policy which can enforce the specific data restrictions therein, e.g., by specifying restrictions on data storage or use that are followed by the receiving server. The receiving server cryptographically operating on the policy can include the receiving server decr pting a cry ptographic feature of the policy and validating a signature of the policy. In some cases, a receiving server can access device data only after deriving a decryption key by parsing the policy. The basis for cryptographic enforcement of restrictions can be included within an attestation and validation process between a user device and a processing or storing server. In some cases, other processes are triggered toAttorney Docket No. 56113-0827WO1enforce one or more restrictions in response to a cryptographic process performed by a device or server, e.g., an attestation and validation process between a user device and a processing or storing server. Public or private keys generated for encrypting data between sender and receiver can be used to cryptographically sign a policy for data restrictions.

[0005] In general, one innovative aspect of the subject matter described in this specification can be embodied in methods that include the actions of receiving a data access request prompted by user interaction on an application executing on the client device, wherein the application corresponds to an application server and wherein the data access request includes a request by the application server for access to data stored on the client device; in response to receiving the data access request, transmitting an attestation nonce request to a secure processor of the client device; generating, by the secure processor, a cryptographic key pair and an attestation nonce, wherein the cryptographic key pair includes a private key and a public key. and the attestation nonce is generated using an identifier of the client device; transmitting, to a server, data comprising (i) the public key from the cryptographic key pair and (ii) the generated attestation nonce; validating an attestation packet received from the server in response to the transmission of the data; in response to validating the attestation packet, transmitting, by the application and to the secure processor, data restrictions specified by the user of the client device; generating, by the secure processor, a signed policy including the data restrictions; and transmitting the signed policy to the server specifying the data restrictions for the server to abide by. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0006] The foregoing and other embodiments can each optionally include one or more of the following features, alone or in combination. In particular, one embodiment includes all the following features in combination. Feature 1: Validating the attestation packet comprises: decrypting an encrypted server key; and deriving a shared secret based on the decrypted server key. Feature 2: Actions include generating a packet that includes (i) the signed policy specify ing the data restrictions and (ii) data to be processed or stored at the server. Feature 3: Generating the packet comprises: wrapping a first key with a shared secret, wherein the first key is used to encrypt the data to be processed or stored at the server; and generating the packet to include (i) the signed policy specifying the data restrictions, (ii) the wrapped first key, and (iii) the data to be processed or stored at theAttorney Docket No. 56113-0827WO1server, wherein the data to be processed or stored at the server is encrypted using the first key. Feature 4: Receiving the data access request prompted by the user interaction on the application executing on the client device comprises: receiving the data request prompted by a user selecting a graphical user interface element indicating a data processing or data storage request within the application. Feature 5: Transmitting the attestation nonce request to the secure processor of the client device comprises: transmitting the attestation nonce request to a trusted execution environment of the client device. Feature 6:Generating the cryptographic key pair and the attestation nonce comprises: generating a key pair and attestation nonce within a trusted execution environment of the client device. Feature 7: Transmitting the data to the server comprises: activating a modem of the client device to transmit the data comprising (i) the public key from the cryptographic key pair and (ii) the generated attestation nonce to the server.

[0007] In general, one innovative aspect of the subject matter described in this specification can be embodied in a system that includes a central processing unit (CPU) configured to generate an attestation nonce request; a trusted execution environment (TEE) configured to receive the attestation nonce request from the CPU, in response, generate a cryptographic key pair, receive an attestation packet from a modem, validate the attestation packet, generate a signed policy in response to validating the attestation packet, wherein the signed policy includes data restrictions provided by a user, and encrypt the signed policy using the cryptographic key pair; and the modem configured to receive the cryptographic key pair, transmit the cryptographic key pair to a server, receive the attestation packet from the server after transmitting the cryptographic key pair to the server, and transmit the encrypted signed policy to the server.

[0008] In general, one innovative aspect of the subject matter described in this specification can be embodied in methods that include the actions of receiving, from a user device, a request for an attestation packet, wherein the request includes an attestation nonce and a public encryption key; in response to receiving the request for the key and attestation nonce, generating an attestation packet; transmitting, to the user device, the generated attestation packet; receiving, from the user device, an encrypted signed policy, wherein the encrypted signed policy is encrypted using a private key that is the key pair of the public encry ption key, and wherein the encrypted signed policy includes data restrictions provided by a user of the user device; and processing device data received from the user device using the data restrictions provided by the user of the user device. Other embodiments of this aspect include corresponding computer systems, apparatus,Attorney Docket No. 56113-0827WO1and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0009] The foregoing and other embodiments can each optionally include one or more of the following features, alone or in combination. In particular, one embodiment includes all the following features in combination. Feature 1: Processing the device data received from the user device using the data restrictions provided by the user of the user device comprises: deriving a key for data decryption using the received request for an attestation packet. Feature 2: Actions include decrypting a data encryption key using the derived key. Feature 3: Actions include decrypting the device data received from the user device using the decrypted data encryption key.

[0010] The technology described in this specification can be implemented so as to realize one or more of the following advantages. For example, the specification describes improvements to data privacy and user-based restrictions. The specification includes a user-configurable restriction policy that can be implemented with a processing server using one or more generated and derived cryptographic keys. A processing server's decryption of a corresponding data restriction policy can indicate compliance with one or more data restrictions indicated in the policy, e.g., to limit one or more processes being performed on user provided data or limit a duration of data storage on the server.Cryptographic proofs of policy enforcement can be used to ensure data restrictions are implemented locally on a processing server.

[0011] In some cases, this specification describes techniques that enable two parties to a network communication that generally do not have any relationship with each other to leverage cry ptography-based communications to help enforce restrictions on data use before data is made available, e.g.. to a server or other processing element. The described techniques can provide more controls over device data or provide data security in an environment where a device may not have traditionally had control over data use by another element, such as a server. As such, the techniques described herein provide improved security and enable granular control over data provided over a network.

[0012] The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.Attorney Docket No. 56113-0827WO1BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1 shows an example electronic device that includes a system-on-chip (SoC) and a server processor.

[0014] FIG. 2 shows an example process for cryptographically implemented data restrictions.

[0015] FIG. 3 shows an example process for attestation packet generation.

[0016] FIG. 4 shows an example process for attestation packet validation.

[0017] FIG. 5 shows an example process for policy token processing.

[0018] Like reference numbers and designations in the various drawings indicate like elements.DETAILED DESCRIPTION

[0019] FIG. 1 shows an example electronic device 100 that includes a system-on-chip (SoC) 106 and a server processor 150. The server processor 150 can perform processing for one or more processes requested by the device 100, e.g.. cloud computing for machine learning-based operations, cloud storage, or a combination of these among others.Through a process that includes generating and receiving a key request 120 and attestation data 122, the device 100 and the server processor 150 can generate restricted data 124 that can include the requested data and further specify, e.g., (i) restriction of processes performed by the server processor 150 on data provided by the device 100 or (ii) restrictions on the duration within which data provided by the device 100 is stored by the server processor 150. The restricted data 124 can be encrypted with a cry ptographic key decryptable by the server processor 150 to, e.g.. help ensure implementation of data restrictions indicated in the restricted data 124.

[0020] The device 100 can be any device of the devices 102, such as a smartphone 102a, a tablet 102b, a laptop 102c, or a wearable device 102d. In general, the device 100 can be any device that processes data. The device 100 includes the SoC 106 and memory devices 104. The SoC 106 can transmit data to and from the memory device 104 to perform operations. The SoC 106 includes processing blocks 108, a memory unit 110, a trusted execution environment (TEE) 111, and a central processing unit (CPU) 112. In some cases, the SoC 106 includes a modem 113. In other cases, the device 100 can include the modem 113 as an element communicably connected to the SoC 106.

[0021] The processing blocks 108 can be configured to perform operations, such as speech detection, machine learning processing, telecommunication signal processing, or aAttorney Docket No. 56113-0827WO1combination of these, among others. The processing blocks 108 can read or write to the memory devices 104. The memory devices 104 can include various memory elements, such as dynamic random-access memory (DRAM). The processing blocks 108 can include ISP blocks for image signal processing.

[0022] The memory' unit 110 can be used as an interface for reading or writing data to the memory devices 104. The memory unit 110 can store data for processing or processing results generated by processing in the SoC 106. The CPU 112 can execute instructions, perform calculations, or help to control system functionality'. The CPU 112 can include a single processor or multiple cores. The CPU 112 can be configured for general-purpose computing. The processing blocks 108 can be used to perform one or more functions not performed by the CPU 112 — e.g., processes that are performed frequently enough, or are process intensive enough, to warrant dedicated circuitry. The CPU 112 can include a TEE 111, e.g., configured to perform one or more secure operations that can include generating encryption keys or encrypting data. The modem 113 can be used to transmit or receive data, e.g., data generated for transmission to the server processor 150 or received from the server processor 150.

[0023] The device 100 performs processing, in the example of FIG. 1, to generate a key request 120, receive attestation data 122, and provide restricted data 124. The device 100 can be communicably coupled with the server processor 150. The server processor 150 can perform operations corresponding to receiving the key request 120. generating the attestation data 122, and receiving the restricted data 124. The server processor 150 can include a server random access memory (RAM) 152, a server CPU, and server storage 156. The server CPU 154 can use one or more of the server RAM 152 and server storage 156 to perform operations, such as workloads for an application, training or managing machine learning models, or other processes running on the device 100.

[0024] The key request 120 and the attestation data 122 can be used to generate a data policy 124B for restricting use of device data 124A. For example, through a process of generating and receiving the key request 120 and the attestation data 122. the device 100 and the server processor 150 can generate cryptographic signatures that can be used in the restricted data 124, e.g., to implement data restrictions on the device data 124A.

[0025] FIG. 2 shows an example process 200 for cryptographically implemented data restrictions. The process 200 can be performed by the device 100, the server processor 150, or a combination of these. For example, a server 202 can perform operations corresponding to the server processor 150. An application C‘app’’) client 206, accessAttorney Docket No. 56113-0827WO1manager 208, and a secure processor 210 can perform operations corresponding to the device 100. Operations performed by the server 202 can be performed by the server CPU 154, e.g., using memory stored in the server RAM 152 or the server storage 156.Operations performed by the device 100 can be performed by one or more processing units of the SoC 106 (e.g., CPU, secure processor), either individually or using one or more memory devices 104, e.g., to store data after processing or other operations.

[0026] The process 200 shows operations performed by, and data exchanged between, the server 202, the app client 206, the access manager 208, and the secure processor 210. The app client 206 can transmit and receive messages to and from the server 202. The server 202 can perform operations based on actions performed in the app client 206, e.g., performing one or more machine learning workloads for data received from the app client 206. The server 202 can perform processing, storing, or other data operations. In some cases, the server 202 includes a tensor processing unit (TPU), e.g., that includes one or more hardware accelerators designed for machine learning tasks and workloads.

[0027] The access manager 208 can include a framework or service running on a device, such as the device 100 of FIG. 1, that facilitates policy creation or is used for data transfer. In some cases, the access manager 208 is a process running on the device. For example, the access manager 208 can include a framework or sendee running on the device 100. e.g., that facilitates one or more of policy creation or data transfer. The secure processor 210 can include a hardware or software secure processor that is used to create an on-device trusted execution environment (TEE), which is separate from the general execution environment of the device and secures data — e.g., that is to be provided outside the devices-and creates one or more data restriction policies. The secure processor 210 can be implemented as a module of an integrated circuit, such as a system on a chip (SoC), central processing unit, chipset, or trusted platform module. In some implementations, the secure processor 210 operates within a TEE. The secure processor 210 can be an example of a secure enclave within a user device, such as the device 100. In some cases, using the secure processor 210 reduces the likelihood of security vulnerabilities compared to a general purpose CPU. For example, using the secure processor 210 can be a defense mechanism, e.g., a defense in depth mechanism. Using the secure processor 210 can help mitigate against attacks that can be launched on the device 100. Attacks can include transient execution attacks such as spectre or meltdown.

[0028] In some cases, the process 200 includes an attestation process. The attestation process can include nonce generation, an attestation request, sending the attestationAttorney Docket No. 56113-0827WO1request, server verification, and attestation response. Nonce generation can include generating a random or pseudo-random number. The number can be generated to ensure that old communications cannot be reused in replay attacks. For example, even if an attacker captures authentication data used in communications for attestation or verification, the nonce, e.g., a number only used for a particular communication session, would indicate the reuse of the authentication data and would cause a receiving device to reject the attacker’s replay message, e.g., because the receiving device can cross reference the used nonce against a set of previously used nonces and detect a duplicate use as a likely invalid authentication. Nonce generation can be performed in response to one or more user or processing actions. In some cases, nonce generation can occur in response to a data access request 214 from the app client 206.

[0029] For example, the app client 206 sends a data access request 214 to the access manager 208. The data access request 214 can be generated by the app client 206 in response to, e.g., a user performing an action using a graphical user interface of the app client 206. For example, the data access request 214 can be generated in response to a user requesting to perform a specific action in the app client 206, such as an action that requires server processing or server data storage. One possible action is an action to edit a saved image using an artificial intelligence process. The artificial intelligence process can be performed by a server, such as the server 202. The data access request 214 can include a request by a server, such as the server 202, for access to data stored on a client device, such as the device 100. A data access request can be received by a device after the device prompts a user interaction within an application executing on the device. The application can use the server 202 to perform one or more processing workloads, such as data processing or data storage.

[0030] Nonce generation can be performed, at least in part, by the secure processor 210. For example, the access manager 208 can receive the data access request 214. The access manager 208 generates, in response to receiving the data access request 214, an attestation nonce request 216. In some cases, the attestation nonce request 216 is generated by a CPU of an operating device, such as the CPU 112 of the device 100.

[0031] In response to receiving the data access request 214, the access manager 208 can transmit the attestation nonce request 216 to the secure processor 210 operating on a device, such as the device 100 of FIG. 1. The attestation nonce request 216 can include a request to generate an attestation nonce. The attestation nonce request 216 can include an operation code that indicates the request is for a new nonce. The access manager 208Attorney Docket No. 56113-0827WO1sends the attestation nonce request 216 to the secure processor 210. The secure processor 210 can include a random number generator to generate a nonce. In some cases, a timestamp is included in the nonce generation, e.g., to ensure the nonce is unique over time.

[0032] The secure processor 210 generates a keypair 218. In some cases, the secure processor 210 generates the keypair 218 with a P-256 (secp256kl) curve. In some cases, operations described as performed by the secure processor 210 are performed within a TEE of a device, such as the TEE 111 of the device 100. The secure processor 210 can generate a public and private key corresponding to a user device, such as the device 100. The secure processor 210 can generate an elliptic curve pair or another type of key pair, such as Rivest-Shamir-Adleman (RSA) keys, digital signature algorithm (DSA) keys, or a combination of these among others. The secure processor 210 can generate a cryptographic key pair and an attestation nonce. The cryptographic key pair can include a private key and a public key. The attestation nonce can be generated using an identifier of the client device. The attestation nonce can include a random number. In some cases, a true random number generator (TRNG) can be used. Output from generating the keypair 218 can include a JSON file that includes an attestation nonce and a public key.

[0033] The process 200 can include preparing an attestation request 230 to send to the server 202. The attestation request 230 can include an attestation nonce and public cryptographic key generated by the secure processor 210. e.g., during a keypair generation process 218. The attestation request 230 can include information, such as device information. Device information can include, e.g.: device serial numbers; international mobile equipment identity; media access control (MAC) address; information indicating hardware components, such as processor type, memory, secure processor, or a combination of these among others; information indicating software, such as firmware version, installed software or applications, or a combination of these; information indicating security posture, such as presence of security patches, encryption, indication of rooting or jailbreaking, among others; digital certificates or signatures, such as a device attestation certificate (DAC); or boot state, which can include information of whether a device booted securely or has been tampered with. In some cases, the attestation request 230 is signed using a private key of a device operating the app client 206, e.g., generating a signature with the private key. The attestation request 230 can be verified using a corresponding public key. e.g., by verifying the generated signature.Attorney Docket No. 56113-0827WO1

[0034] The atestation request 230 can include a request for a key to be generated by the server 202. For example, the atestation request 230 can include a request for an ephemeral key, such as an elliptic curve Diffie-Hellman (ECDH) ephemeral key. The atestation request 230 can be sent to the server 202 by the app client 206, e.g., using one or more modems of a corresponding device (e g., device 100) communicating with one or more modems of the server 202. The atestation request 230 can be sent to the server 202 using a secure communication channel, such as a transport layer security (TLS) or other secure interparty communication framework. The app client 206 can transmit to the server 202 data that includes a public key and an atestation nonce, e.g., as generated at 218 by the secure processor 210. The app client 206 can be communicably connected to a modem, such as the modem 113 of the device 100. The app client 206 can use a modem, such as the modem 113, to perform reception or transmission from and to the server 202.

[0035] The server 202 can receive the atestation request 230 from an operating device, such as the app client 206 of the device 100. The atestation request 230 can include an atestation nonce and a public encryption key, e.g., generated at 218 as part of a private / public key pair. In response to receiving the atestation request 230, the server 202 can generate the attestation packet 234 and transmit this atestation packet 234 to the app client 206, as further explained below.

[0036] In particular, the process 200 can include the server 202 generating a key and an atestation packet. For example, the server 202 can generate an attestation packet 234 that includes a generated key, such as an ECDH ephemeral key pair (as requested in the atestation request). The server 202 can include a public key (El) of the server 202 in the atestation packet 234.

[0037] The server 202 can transmit the atestation packet 234 to the app client 206, e.g., using one or more of receiving or transmiting modems of the server or device used to receive or transmit the atestation request 230. Additional details of an example process to generate the atestation packet 234 are described with reference to FIG. 2.

[0038] In some implementations, the server 202 performs verification, such as verification of a nonce, signature, or device integrity. For example, the server 202 can perform Nonce validation, e.g., by verifying that the nonce included in the atestation request 230 has not been used before (e.g., by evaluating whether the nonce is same as or different from nonces received by the server 202 previously). The server 202 can perform signature verification, e.g., by using a public key of the device 100 to verify aAttorney Docket No. 56113-0827WO1cryptographic signature used in the attestation request 230. The server 202 can perform an integrity check, e.g., by verifying firmware versions or other security metrics. In some cases, a valid set of software, firmware, or other integrity measurements can be preprogrammed in the server 202. The server 202 can receive valid sets of measurements, e.g., for comparison in signature verification.

[0039] In some implementations, the attestation packet 234 is generated by the server 202 upon the server 202 verifying the attestation request 230. The attestation packet 234 can include a response nonce, e g., generated by the server 202 to help ensure mutual attestation. Ensuring mutual attestation can refer to preventing replay attacks or other invalid attestations from being accepted by a receiving device, such as the device 100. In some cases, a response nonce is generated similar to the attestation nonce, e.g.. using a secure processor of the server. The attestation packet 234 can include a cry ptographic signature, e.g., where the server 202 signs the attestation packet 234 with its private key. The attestation packet 234 can include a session key, e.g., encrypted with a public key of the server 202.

[0040] After the attestation packet 234 is transmitted by the server 202 to the device, it can subsequently be transferred internally on the device from the app client 206 to the access manager 208. The access manager 208 transmits data corresponding to the attestation packet 234 to the secure processor 210. The secure processor 210 can use the attestation packet 234 to perform validation 240. The secure processor 210 can perform validation on the attestation packet 234 received from the server 202 in response to the app client 206 transmitting the attestation request 230. Additional details of validation are discussed in reference to FIG. 4.

[0041] In response to receiving the attestation packet 234, a receiving device, such as the device 100, can verify aspects of the attestation packet 234. For example, the secure processor 210 can verify a nonce or signature included in the attestation packet 234, e.g., as part of the validation 240. Additional details of one example validation approach for verifying the nonce / signature is described with reference to FIG. 4.

[0042] In some cases, the validation 240 can generate a not okay (NOK) signal 241, e.g., representing failed validation. If the validation 240 generates a NOK signal 241, the secure processor 210 can provide the NOK signal 241 to the access manager 208. The NOK signal 241 can be configured to cause an operating device, such as the device 100, to halt further communications with the server 202 or perform another action, e.g., notifying one or more users or other systems. In some cases, the NOK signal 241 can beAttorney Docket No. 56113-0827WO1received by the access manager 208 and the device, upon receipt of the NOK signal 241, can be configured to perform one or more operations, such as to halt further communications with the server 202 or perform another action. Another action can include notifying one or more other devices that a server is compromised, e.g., to prevent one or more other devices from attempting to authenticate with the server 202.

[0043] In response to validating the attestation packet 234, the app client 206 can transmit data restrictions specified by a user of an operating device, such as the device 100. Data restrictions can be in any suitable format, e g., protocol buffers, JavaScript object notation (JSON). For example, if the validation 240 generates an OK signal 242, the secure processor 210 can provide the OK signal 242 to the access manager 208. The OK signal 242 can be configured to cause the access manager 208 to request access restrictions 244 from the app client 206. The app client 206 can use an interface, such as a graphical user interface (GUI) to obtain input from a user indicating access restrictions 246. In some cases, the request access restrictions 244 can include a public key, such as the key El generated by the server 202. In some cases, the receiving party knows the ephemeral pubkey of the other party to complete Diffie Hellman. For establishing a shared key, two parties can share their public keys and are able to derive a shared key, such as the key used for device data encryption or decry ption.

[0044] The access restrictions 246 can include purpose or use limitations or retention policies. For example, a user can grant photo access to an application for generative artificial intelligence (Al) edits only. Limitations can be inferred, e.g., do not use photos for facial recognition, do not use content in photos for content targeting. Limitations can be inferred, e.g., by a specific request by a user, such as only use photos for generative Al processes. A user can provide input indicating a desire to share location data with certain contacts of the user. In some cases, a user provides limitations using a text box or using speech input. A natural language processor operating on the device can parse one or more explicit or implied limitations based on the obtained data. For example, based on interpreting a user indicating a desire to share location data with friends only, a device can infer that location should not be used for ad targeting.

[0045] The access restrictions 246 can include restrictions on retention of data. For example, a user can indicate that data should be deleted after twenty-four hours, e.g., in response to the app client 206 providing an interface for obtaining input from the user in response to the request 244. A user can indicate that a photo should be deleted after one or more processes are complete, such as generative Al edits.Attorney Docket No. 56113-0827WO1

[0046] The access restrictions 246 can include a purpose use (Rl) and a retention period (R2). The purpose use Rl can indicate a purpose for which data will be used in processes by the server 202. The retention period R2 can indicate how long the data should be retained, e.g., in memory of the server 202, such as the server storage 156.

[0047] The access manager 208 generates a signing request 248 to the secure processor 210. The signing request 248 can include data, such as restrictions indicated by a user and an encryption key. The encryption key can be randomly generated on a device, such as by the secure processor 210 of the device 100. The signing request 248 can include Rl, R2, and KI, where KI represents an encryption key generated by the access manager 208.

[0048] The secure processor 210 generates a signed policy 252 that includes data restrictions. For example, in response to receiving the signing request 248, the secure processor 210 generates 250 a signed policy 252 that includes the access restrictions 246. The generation 250 can include generating an ephemeral key (E2). The ephemeral key E2 can be an ECDH ephemeral key pair. The generation 250 can include deriving a shared secrete key (WK) using El received by the app client 206 from the server 202 and E2. The secure processor 210 can encrypt the data encryption key KI using the wrapping key (WK) to generate K2. In some cases, a benefit of using ephemeral keys, deriving shared secrets, or encrypting using a wrapping key can include avoiding reusing keys or having one unique key per device. The generation 250 can generate the signed policy 252 that includes information indicating one or more data restrictions included in the access restrictions 246 and one or more cryptographic keys, e.g., at least one of Rl, R2, and encrypted key K2. The secure processor 210 sends the signed policy 252 to the access manager 208. The signed policy 252 can be signed with the private key of a device, such as the device 100.

[0049] The access manager 208 generates an encryption request 254 requesting the secure processor 210 to encrypt data, e.g., data obtained from the device 100 that is the subject of the access restrictions 246. The secure processor 210 encrypts the requested data 256. The encrypting 256 can include the secure processor 210 encrypting data of a user, such as one or more photos or other files, using encryption key KI. In some cases, the data from the device 100 can remain encry pted with a data encryption key. At the time of policy generation and signing, the device 100 can wrap the data encryption key. In some cases, wrapping can be performed in parallel with one or more other operations. In some cases, wrapping can include encryption of 32 bytes.Attorney Docket No. 56113-0827WO1

[0050] The secure processor 210 can send encrypted data 258, the signed policy 252, and one or more cryptographic keys to the access manager 208. For example, the secure processor 210 can send the encrypted data 258, the signed policy 252, and E2 — e.g., generated by the secure processor 210 at generation 250.

[0051] The app client 206 can send data received from the access manager 208 to the server 202. The app client 206 can transmit the signed policy 252 to the server 202 specifying one or more data restrictions for the server 202 to abide by. The app client 206 can receive the encrypted data and signed policy 260 from the access manager 208 and transmit the data 260 to the server 202. The data 260 can include encry pted device data 258, the signed policy 252, and E2.

[0052] The server 202 can process the policy received in the data 260. This process is described with reference to FIG. 5. The server 202 can receive, from the app client 206, an encrypted signed policy, e.g., included in the data 260. The encrypted signed policy¬ can be encrypted using a private key corresponding to the public key generated at 218 and included in the attestation request 230. The encrypted signed policy can include the signed policy 252. The signed policy 252 can include data restrictions provided by a user of a user device. The server 202 can process device data received from a user device, such as the app client 206 performing operations for the device 100, using data restrictions provided by a user of the transmitting user device.

[0053] The server 202 can decrypt and enforce one or more policies. The server 202 can derive a shared secret key WK using El and E2. The server 202 can decrypt K2 using WK to obtain KI. The server 202 can decry pt the encrypted data 258 included in the data 260 using the decry pted KI. The server 202 can decode the signed policy 252 and enforce the restrictions — e.g., R1 and R2 — locally on processes performed or memory stored at the server 202. In some cases, the process 200 can include generating an acknowledgment by the server 202 and receiving the generated acknowledgment by the device 100. The acknowledgment can indicate that a policy has been verified. The acknowledgment can provide one or more operations that will be performed by the server 202, e.g.. in keeping with one or more restrictions indicated by the policy. In some cases, the device 100 provides data in response to receiving a generated acknowledgment from the server 202 within a time window. In some cases, the device 100 does not provide data, such as device data, to the server 202 if the device 100 does not receive a generated acknowledgment from the server 202 within a given time window.Attorney Docket No. 56113-0827WO1

[0054] In some cases, actions of FIG. 2 can correspond to actions of ECDH. In some cases, other key exchange processes are performed. For example, instead of ECDH, the device 100 can perform Ri vest-Shamir- Adleman (RS A), El Gamal, digital signature algorithm (DSA), Edwards-curve digital signature algorithm (EdDSA), or a combination of these among others.

[0055] FIG. 3 shows an example process 300 for attestation packet generation. For example, the server 202 of FIG. 2 can perform the process 300 as part of generating 232 the attestation packet 234. An element of a device, such as the app client 206 can send the server 202 a challenge that includes an attestation nonce, e.g., the attestation request 230. The server 202 responds by provided the attestation packet 234. The server 202 can include a nonce as a challenge to verify freshness. The server 202 can validate a signature of the nonce using subsequent data received from the device.

[0056] The process 300 can include one or more steps to generate an attestation packet, such as the attestation packet 234. An attestation packet can be used to establish trust in a server, such as the server 202. An attestation packet can be used to establish a shared secret between a secure processor running on a device and a server.

[0057] The process 300 includes a process of generating an encryption key (302). For example, the server 202 can use a process, such as elliptic curve Diffie-Hellman (ECDH) to generate an ephemeral public key El. The process 300 can include encrypting El using a public key of a device, such as a public key generated by the secure processor 210 at 218. Encrypting El using the public key can generate El Enc. The encrypted El , ElEnc, can be bound to a secure processor, such as the secure processor 210, e.g., to mitigate against person-in-the-middle attacks.

[0058] The process 300 includes generating a token nonce (304). For example, the server 202 can generate a randomized number using one or more random number generators. The server CPU 154 can perform a random number generator process, e.g., in connection with the server RAM 152 or the server storage 156. A nonce generated by the server 202 can be unique, e.g., to help ensure freshness of a token.

[0059] The process 300 includes creating a serialized packet (306). For example, the server 202 can create a serialized packet that includes ElEnc, the generated token nonce, and an attestation nonce. In some cases, other data is included, such as server software measurements which can include a current software version used at the server among other information. The attestation nonce can be received from the attestation request 230. The generated token nonce can be generated using a random number generator (RNG)Attorney Docket No. 56113-0827WO1compliant with NIST recommendations, such as OpenSSL RNG. Other data, such as software measurements, can be included, e.g., for a receiving party to know that the sender is running the right software and has not been compromised or is running an old version of software that might have security issues.

[0060] The process 300 includes creating an attestation packet (308). For example, the server 202 can generate the attestation packet 234. The attestation packet can include a signed version of the created serialized packet. For example, the attestation packet can be signed by the server 202 using a private key of the server and / or server certificate. The signed packet can be the attestation packet 234.

[0061] FIG. 4 shows an example process 400 for attestation packet validation. For example, the secure processor 210 of FIG. 2 can perform the process 400 as part of 240. An attestation packet validation process can include verifying an authenticity of a packet and then establishing a secure shared secret (WK) between a server and the secure processor, such as the server 202 and the secure processor 210. The shared secret can be used for subsequent unwrapping of the encrypted data encryption key (K2), e.g., to obtain an original key (KI) for data decryption.

[0062] The process 400 includes determining whether a packet signature is valid (402). For example, the secure processor 210 can verify a digital signature included in the attestation packet 234 received from the server 202. Verification can include using a public key of the server 202 to verify at least a portion of the attestation packet 234. Validating the signature can help ensure a packet’s integrity' and authenticity, e.g., confirming the packet originated from the server 202 and hasn’t been tampered with.

[0063] The process 400 includes determining whether server measurements are valid (404). Determining whether the server measurements are valid can include comparing one or more received server measurements to threshold measurements. The process 400 can include ensuring integrity or security of hosts through measured boot or host attestation. By comparing one or more received measurements with one or more thresholds, a sender or receiver can determine whether or not another entity is likely compromised.

[0064] The process 400 includes decrypting an encrypted server key (406). For example, the secure processor 210 can decrypt ElEnc and derive El. ElEnc can include an encrypted ECDH public key. ElEnc can be included in the attestation packet 234. The secure processor 210 can decrypt ElEnc using a private key of the secure processor 210.Attorney Docket No. 56113-0827WO1Decrypting ElEnc generates El, e.g., the server key generated by the server 202 in response to the attestation request 230.

[0065] The process 400 includes creating an encryption key (408). For example, the secure processor 210 can create an ephemeral ECDH key E2. The secure processor 210 can generate an ephemeral ECDH key pair. The public key from the key pair can be referred to as E2.

[0066] The process 400 includes deriving a shared secret (410). For example, the secure processor 210 can derive a shared secret with the server 202, e.g., by using El and E2 to generate a wrapping key WK. The secure processor 210 can use a ECDH key exchange mechanism to derive a shared secret between the server 202 and the secure processor 210. The derived shared secret WK can be used for subsequent encryption.

[0067] The process 400 includes wrapping a first key with the shared secret (412). For example, the secure processor 210 can wrap KI with the derived shared secrete WK. Wrapping can include encryption. Wrapping the first key with the shared secret can generate K2, a wrapped data encryption key. K2 can be used, e.g., by the secure processor 210 to encrypt data sent to the server 202 subject to data restrictions. Data can be encrypted by the key KI. KI can be a generated key on device and saved on device, e.g., in a TEE. KI can be protected by encry ption using the wrapping key WK. The encrypted key can be referred to as K2. WK can be established using a secure protocol, such as ECDH. In some cases, K2 is the wrapped key that can be unwrapped (or decrypted), e g., by the server 202, to compute KI.

[0068] FIG. 5 shows an example process 500 for policy token processing. The server 202 can perform the process 500 at 262 in FIG. 2.

[0069] The process 500 includes checking a validity’ of a policy signature (502). For example, the server 202 can check a digital signature of a policy provided by the app client 206 within the data 260. If the signature is invalid, an error can be generated and the process 500 can stop. In some cases, a validity' check can include performing a cryptographic operation on the policy signature and comparing an output of the cryptographic operation to an expected output of the operation. Based on the expected output matching the actual output, the server 202 can determine that the policy signature is valid.

[0070] The process 500 includes checking if a nonce is valid (504). For example, the data 260 sent by the app client 206 can include a nonce that was included in the attestation packet 234 provided to the server 202, e.g., as part of generating the tokenAttorney Docket No. 56113-0827WO1nonce 304. An invalid nonce can be a nonce that was generated prior to a threshold time or not within a threshold time. An invalid nonce can be a nonce that does not match any nonce generated by the server 202. If a nonce is invalid, the server can stop the process 500 and indicate error in processing. In some cases, if a nonce is not valid, the server 202 does not use the data. If an adversarial entity tried an attack by creating a fake policy for a device then the signature would not pass. If an adversarial entity tried an attack by reusing an old policy then the nonce would be detected as invalid.

[0071] The process 500 includes deriving a key for data decryption (506). For example, the server 202 can derive WK using El and E2. The shared secret WK can be derived using public keys El and E2. El can have been generated and sent earlier by the server 202 in the attestation packet 234. E2 can have been received from the secure processor 210, e.g., within the data 260.

[0072] The process 500 includes decrypting using the derived key (508). For example, the server 202 can decrypt a K2 key included in the data 260 using the derived key WK. Decrypting the K2 key can generate the data encr ption key KI.

[0073] The process 500 includes decrypting data using the decrypted key (510). For example, the server 202 can receive the data 260 that is encrypted. The server 202 can use the decry pted key KI to decry pt data included in the data 260. In some cases, decryption can be validated as property by using specific text or values that a receiver can check for post-decryption. If the specific text or values is present in the decrypted data, then the decryption can be determined to be valid.

[0074] The process 500 includes decoding and enforcing data restriction policy (512). For example, the server 202 can receive the data 260 that includes the signed policy 252. The signed policy 252 can include a policy token or represent the policy token. The server 202 can use the KI key to decry pt the policy token. The server 202 can process data in the decrypted policy and enforce one or more data restrictions locally, e.g., controlling or halting one or more operations of the server CPU 154, the server RAM 152, or the server storage 156.

[0075] In some cases, the server provides an acknowledgement indicating a data restriction policy has been received and that it is processing or storing data according to the policy. For example, the server 202 can receive the data 260 that includes the signed policy 252. In response to receiving the data 260 that includes the signed policy 252, the server 202 can generate and transmit a signal to the device 100. e.g., that indicates the signed policy 252 was received successfully which can include successful decryption ofAttorney Docket No. 56113-0827WO1the signed policy 252. The acknowledgment signal can include an indication that the server will perform one or more operations on data received from a device, such as the device 100, according to the policy, e.g., without violating one or more stated restrictions on storage or use.

[0076] Techniques described in this specification can result in a server being provided with granular data restrictions. By performing various operations to get raw data from a device, a server can explicitly or implicitly acknowledge data restrictions. In a process with a server that does not provide explicit or implicit acknowledgment, operations of the device can be halted prior to providing any data. In some cases, servers not participating in restriction processes may not be used for validation or other processes described in this specification.

[0077] In some cases, receipt of data is conditional upon explicit acknowledgment of data restrictions, e.g., included in a signed policy. For example, a device can provide a signed policy, such as the policy included in the data 260 of FIG. 2. The device can wait for an explicit acknowledgment from the server prior to generating and transmitting data to be restricted by data restrictions of the signed policy. The device can either receive acknowledgment from the server and, in response, generate and transmit data for processing or other use by the server or can not receive acknowledgment and can halt further processing or mark the server as untrusted or malfunctioning. In some cases, a device can provide information to one or more communicably connected devices to indicate that a given server that does not provide an acknowledgment is not trusted or malfunctioning. In some cases, a device can receive communications from one or more devices indicating a server that does not provide one or more acknowledgments. In response to obtaining one or more signals indicating a specific server did not provide acknowledgment on one, or a threshold number, of occasions, a receiving device can prevent attestation of other communication with the specific server, e.g., until additional data indicates the server has changed state and is providing acknowledgments.

[0078] The subject matter and the actions and operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. The subject matter and the actions and operations described in this specification can be implemented as or in one or more computer programs, e.g., one or more modules of computer program instructions, encoded on a computer program carrier, for execution by.Attorney Docket No. 56113-0827WO1or to control the operation of, data processing apparatus. The carrier can be a tangible non-transitory computer storage medium. Alternatively or in addition, the carrier can be an artificially-generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer storage medium can be or be part of a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. A computer storage medium is not a propagated signal.

[0079] In general, use of “or” can refer to “and / or.” When providing a list of two or more items, the conjunction “or” can indicate any one of the items, any combination of a subset of the items, or all items in combination.

[0080] The term “data processing apparatus” encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. Data processing apparatus can include special-purpose logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application-specific integrated circuit) , or a GPU (graphics processing unit). The apparatus can also include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0081] A computer program can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; and it can be deployed in any form, including as a stand-alone program, e.g., as an app, or as a module, component, engine, subroutine, or other unit suitable for executing in a computing environment, which environment may include one or more computers interconnected by a data communication netw ork in one or more locations.

[0082] A computer program may, but need not, correspond to a file in a file system. A computer program can be stored in a portion 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 in question, or in multiple coordinated files, e.g., files that store one or more modules, sub-programs, or portions of code.

[0083] The processes and logic flows described in this specification can be performed by one or more computers executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows can alsoAttorney Docket No. 56113-0827WO1be performed by special-purpose logic circuitry, e.g., an FPGA, an ASIC, or a GPU, or by a combination of special-purpose logic circuitry and one or more programmed computers.

[0084] Computers suitable for the execution of a computer program can be based on general or special-purpose microprocessors or both, or any other kind of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory can be supplemented by, or incorporated in, special-purpose logic circuitry.

[0085] Generally, a computer will also include, or be operatively coupled to, one or more mass storage devices, and be configured to receive data from or transfer data to the mass storage devices. The mass storage devices can be, for example, magnetic, magnetooptical, or optical disks, or solid state drives. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, 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, e.g., a universal serial bus (USB) flash drive, to name just a few.

[0086] To provide for interaction with a user, the subject matter described in this specification can be implemented on one or more computers having, or configured to communicate with, a display device, e.g., a LCD (liquid crystal display) monitor, or a virtual-reality (VR) or augmented-reality (AR) display, for displaying information to the user, and an input device by which the user can provide input to the computer, e.g., a keyboard and a pointing device, e.g., a mouse, a trackball or touchpad. Other kinds of devices can be used to provide for interaction with a user as well: for example, feedback and responses provided to the user can be any form of sensory feedback, e.g., visual, auditory, speech, or tactile feedback or responses; and input from the user can be received in any form, including acoustic, speech, tactile, or eye tracking input, including touch motion or gestures, or kinetic motion or gestures or orientation motion or gestures. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user’s device in response to requests received from the web browser, or by interacting with an app running on a user device, e.g., a smartphone or electronic tablet. Also, a computer can interact with a user by sending text messages or other formsAttorney Docket No. 56113-0827WO1of message to a personal device, e.g., a smartphone that is running a messaging application, and receiving responsive messages from the user in return.

[0087] This specification uses the term ‘'configured to” in connection with systems, apparatus, and computer program components. That a system of one or more computers is configured to perform particular operations or actions means that the system has installed on it software, firmware, hardware, or a combination of them that in operation cause the system to perform the operations or actions. That one or more computer programs is configured to perform particular operations or actions means that the one or more programs include instructions that, when executed by data processing apparatus, cause the apparatus to perform the operations or actions. That special-purpose logic circuitry is configured to perform particular operations or actions means that the circuitry has electronic logic that performs the operations or actions.

[0088] The subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface, a web browser, or an app 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 back-end, middleware, or front-end 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 a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

[0089] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server anses by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some implementations, a server transmits data, e.g., an HTML page, to a user device, e.g., for purposes of displaying data to and receiving user input from a user interacting with the device, which acts as a client. Data generated at the user device, e.g., a result of the user interaction, can be received at the server from the device.

[0090] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of what is being claimed, which is defined by the claims themselves, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that areAttorney Docket No. 56113-0827WO1described 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 in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially be claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claim may be directed to a subcombination or variation of a subcombination.

[0091] Similarly, while operations are depicted in the drawings and recited in the claims in a particular order, this by itself should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and 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.

[0092] Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous.

[0093] What is claimed is:

Claims

Attorney Docket No. 56113-0827WO1CLAIMS1. A method implemented by a client device, comprising:receiving a data access request prompted by user interaction on an application executing on the client device, wherein the application corresponds to an application server and wherein the data access request includes a request by the application server for access to data stored on the client device;in response to receiving the data access request, transmitting an attestation nonce request to a secure processor of the client device;generating, by the secure processor, a cry ptographic key pair and an attestation nonce, wherein the cryptographic key pair includes a private key and a public key, and the attestation nonce is generated using an identifier of the client device:transmitting, to a server, data comprising (i) the public key from the cryptographic key pair and (ii) the generated attestation nonce;validating an attestation packet received from the server in response to the transmission of the data;in response to validating the attestation packet, transmitting, by the application and to the secure processor, data restrictions specified by the user of the client device; generating, by the secure processor, a signed policy including the data restrictions; andtransmitting the signed policy to the server specifying the data restrictions for the server to abide by.

2. The method of claim 1. wherein validating the attestation packet comprises:decrypting an encr pted server key; andderiving a shared secret based on the decrypted server key.

3. The method of claim 1. comprising:generating a packet that includes (i) the signed policy specifying the data restrictions and (ii) data to be processed or stored at the server.

4. The method of claim 3. wherein generating the packet comprises:Attorney Docket No. 56113-0827WO1wrapping a first key with a shared secret, wherein the first key is used to encrypt the data to be processed or stored at the server; andgenerating the packet to include (i) the signed policy specifying the data restrictions, (ii) the wrapped first key, and (iii) the data to be processed or stored at the server, wherein the data to be processed or stored at the server is encry pted using the first key.

5. The method of claim 1, wherein receiving the data access request prompted by the user interaction on the application executing on the client device comprises:receiving the data request prompted by a user selecting a graphical user interface element indicating a data processing or data storage request within the application.

6. The method of claim 1, wherein transmitting the attestation nonce request to the secure processor of the client device comprises:transmitting the attestation nonce request to a trusted execution environment of the client device.

7. The method of claim 1, wherein generating the cryptographic key pair and the attestation nonce comprises:generating a key pair and attestation nonce within a trusted execution environment of the client device.

8. The method of claim 1. wherein transmitting the data to the server comprises:activating a modem of the client device to transmit the data comprising (i) the public key from the cry ptographic key pair and (ii) the generated attestation nonce to the server.

9. A system comprising:a central processing unit (CPU) configured to generate an attestation nonce request;a trusted execution environment (TEE) configured to receive the attestation nonce request from the CPU, in response, generate a cryptographic key pair, receive anAttorney Docket No. 56113-0827WO1atestation packet from a modem, validate the atestation packet, generate a signed policy in response to validating the atestation packet, wherein the signed policy includes data restrictions provided by a user, and encrypt the signed policy using the cryptographic key pair; andthe modem configured to receive the cryptographic key pair, transmit the cryptographic key pair to a server, receive the atestation packet from the server after transmiting the cryptographic key pair to the server, and transmit the encrypted signed policy to the server.

10. A method comprising:receiving, from a user device, a request for an atestation packet, wherein the request includes an atestation nonce and a public encryption key;in response to receiving the request for the key and atestation nonce, generating an atestation packet;transmitting, to the user device, the generated atestation packet;receiving, from the user device, an encrypted signed policy, wherein the encrypted signed policy is encrypted using a private key that is the key pair of the public encryption key, and wherein the encry pted signed policy includes data restrictions provided by a user of the user device; andprocessing device data received from the user device using the data restrictions provided by the user of the user device.

11. The method of claim 10, wherein processing the device data received from the user device using the data restrictions provided by the user of the user device comprises:deriving a key for data decryption using the received request for an attestation packet.

12. The method of claim 11, comprising:decrypting a data encry ption key using the derived key.

13. The method of claim 12, comprising:decrypting the device data received from the user device using the decrypted data encryption key.Attorney Docket No. 56113-0827WO114. One or more computer storage media encoded with instructions that, when executed by one or more computers, cause the one or more computers to perform the method of any preceding claim.

15. A system comprising one or more computers and one or more storage devices on which are stored instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform the method of any preceding claim.

Images