Data aggregation

Abstract

A data consumer device comprises circuitry to identify a plurality of data producer devices from which to receive remotely generated data over a network, and processing circuitry to provide a data processing environment in which to process the remotely generated data. The data consumer device also has measurement circuitry to take a measurement of the data processing environment, and attestation circuitry to provide to the plurality of data producer devices an attestation report based on the measurement of the data processing environment. The attestation report is to provide the data producer devices with a guarantee that the data consumer device will process the remotely generated data in a predetermined manner.

Description

[0001] DATA AGGREGATION

[0002] The present technique relates to the field of data processing.

[0003] Environments may include a wide range of data producer devices, such as devices with sensors gathering information about the environment. Such devices are typically owned by a range of different device owners, but situations may arise in which an individual desires to access and gather together data produced by several different data producer devices, and use the gathered data for a processing task.

[0004] However, due to the potential for misuse of sensitive data, owners of such data producer devices may be unwilling to freely share their data with potentially untrustworthy data consumers. Similarly, data consumers may be unwilling to trust the data produced by potentially untrustworthy data producer devices.

[0005] At least some examples provide a data consumer device, comprising: data producer identification circuitry to identify a plurality of data producer devices from which to receive remotely generated data over a network; processing circuitry to provide a data processing environment in which to process the remotely generated data received from the plurality of data producer devices; measurement circuitry to take a measurement of the data processing environment in which the remotely generated data is to be processed; and attestation circuitry to provide to the plurality of data producer devices an attestation report based on the measurement of the data processing environment, wherein for each data producer device of the plurality of data producer devices the attestation report is provided to the data producer device in advance of receiving the remotely generated data from said data producer device; wherein the attestation report is to provide the plurality of data producer devices with a guarantee that the data consumer device will process the remotely generated data in a predetermined manner.

[0006] At least some examples provide a data processing system, comprising: the data consumer device as described above; and the plurality of data producer devices, wherein the plurality of data producer devices comprise data generating circuitry to generate the remotely generated data; wherein a given data producer device is configured to determine whether to send remotely generated data generated by the given data producer device to the data consumer device in dependence on whether the attestation report indicates that the data processing environment meets a set of consumer device criteria enforced by the given data producer device.

[0007] At least some examples provide a data producer device as described above.

[0008] At least some examples provide a method of data processing, comprising: identifying a plurality of data producer devices from which to receive remotely generated data over a network; providing a data processing environment in which to process the remotely generated data received from the plurality of data producer devices; measuring the data processing environment in which the remotely generated data is to be processed; and providing to the plurality of data producer devices an attestation report based on the measurement of the data processing environment, wherein for each data producer device of the plurality of data producer devices the attestation report is provided to the data producer device in advance of receiving the remotely generated data from said data producer device; wherein the attestation report is to provide the plurality of data producer devices with a guarantee that the data consumer device will process the remotely generated data in a predetermined manner.

[0009] At least some examples provide a computer program comprising program instructions which, when executed on a computer, are arranged to cause the computer to implement the above method.

[0010] The computer program may be provided in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc..

[0011] Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which:

[0012] Figure 1 illustrates a processing system comprising a data consumer device and a plurality of data producer devices;

[0013] Figure 2 illustrates an attestation process between a data consumer device and a data producer device;

[0014] Figure 3 illustrates two general attestation processes;

[0015] Figure 4 illustrates a number of domains in which processing circuitry can operate;

[0016] Figure 5 illustrates an example of a processing system supporting granule protection lookups;

[0017] Figure 6 schematically illustrates aliasing of a number of physical address spaces onto a system physical address space identifying locations in the memory system;

[0018] Figure 7 illustrates an example of partitioning the effective hardware physical address space so that different architectural physical address spaces have access to respective portions of the system physical address space;

[0019] Figure 8 is a flow diagram showing a method of selecting a physical address space to be accessed by a given memory access request;

[0020] Figure 9 illustrates a method of performing a granule protection check based on granule protection information; Figures 10 and 11 illustrate realms which may be provided by the data consumer device and data producer device respectively;

[0021] Figure 12 illustrates a computer general purpose computer which may be used to implement the presently described techniques.

[0022] As mentioned above, situations may arise where an individual data consumer wishes to consume remotely generated data from a plurality of data producer devices owned by one or more different owners.

[0023] In one example, a neighbourhood may be supplied with energy from renewable sources. Energy may be stored in batteries, and during periods of low energy generation, power may be supplied from those batteries. In some cases the batteries may be partially provided by batteries of electric cars owned by residents of the neighbourhood. A data consumer may be responsible for planning how power is to be stored and used in the neighbourhood, and for that purpose may wish to access data indicating the presence or absence of each of the cars (and therefore their battery energy storage) in the neighbourhood. The data producer devices accessed for this purpose may include GPS devices provided by the cars, a component of the electrical connection between the cars and the power network, a camera showing whether the car is present, and so on.

[0024] In another example, there may be a desire to identify a vehicle. For example, the vehicle may have been involved in an accident and it may be desired to identify the vehicle to the authorities. Existing techniques may rely on use of a dashcams to identify the vehicle, however a single angle of the vehicle may be insufficient for identification. Therefore, it may be desired to build up a model of the vehicle to enable future identification. To do so, data could be obtained from a plurality of cameras having different views of the vehicle. Therefore, a consumer may wish to query data producing devices including CCTV cameras installed on nearby buildings, mobile phones of passers-by, dashcams of surrounding vehicles, and any other devices having a camera which may have imaged the vehicle.

[0025] In a further example, a child may have gone missing. Authorities may wish to query data producer devices in the area where the child was last seen so that the child can be safely located. The data producer devices may include CCTV cameras, private doorbell cameras, cameras inside shops, mobile phone cameras and microphones (to detect the child’s voice), and so on.

[0026] In a yet further example, there may be an active shooter and authorities may wish to determine up-to-date information about the shooter. The combination of microphone and GPS data, for example from mobile phones, could be used to locate a shooter. For example, a Time Difference of Arrival (TDoA) technique may be used to locate a shooter based on the times at which gunshots are detected at various locations. Therefore, a data consumer may wish to receive microphone and GPS data from a plurality of data producer devices and correlate the data to locate the origin of the sounds. Due to the nature of sound waves, air pressure and humidity may play a role in sound propagation. Therefore, the consumer may also wish to receive pressure and humidity data from sensors provided by the data producer devices.

[0027] In each of the scenarios discussed above, significant advantages may be obtained by aggregating data from a plurality of data producer devices. However, it is clear that allowing free access to data produced by each data producing device would be associated with risks to privacy and security. For example, giving access to data indicating the presence of cars may signal when homes are vacant and thereby invite burglary, allowing any data consumer to query CCTV footage could allow individuals to spy on members of the public, allowing querying of mobile phone microphones could allow individuals or organisations to listen in on private conversations, and so on. Therefore data producer devices may typically be configured not to share their remotely generated data with data consumers.

[0028] However, owners of data producer devices may be more willing to allow their data to be used in cases where limits can be enforced on the ways a data consumer may use the data. For example, a data producer device may allow its data to be used to construct a 3D model of the vehicles involved in an accident if it can be guaranteed that this is the only way the data will be used, and that the remotely generated data could not be directly accessed by a user of the data consumer device. Similarly, a mobile phone owner may be willing to provide microphone data to a consumer which uses that data to locate a gunshot, if it can be guaranteed that the data will be used in no other way. The present technique seeks to provide guarantees on the ways data can be used, and therefore encourage the sharing of data to assist in scenarios such as those described above.

[0029] A data consumer device according to the present technique comprises data producer identification circuitry to identify a plurality of data producer devices from which to receive remotely generated data over a network. The data producer devices may be identified in several ways. For example, the data consumer device may store in advance, or receive from the internet, a database identifying candidate data producer devices. In other examples, candidate data producer devices may be identified using a peer-to-peer process or gossip protocol where devices share details of other devices with each other. Data producer devices may be selected from a list of candidates by applying selection criteria, such as selection based on geographical location (selecting nearby devices or devices located in a particular geographical region, for example), device type, sensor type, and so on.

[0030] The network over which remotely generated data is transmitted is not particularly limited. In some examples the network is a wireless network, for example a mobile network.

[0031] The data consumer device also comprises processing circuitry to provide a data processing environment in which to process the remotely generated data received from the plurality of data producer devices. The data processing environment may, for example, be responsible for collating data received from the data producer devices and producing some output, such as a geographical location of a suspected shooter (in an example where the received data comprises microphone and GPS data from a plurality of mobile devices). In some examples, the data received from the data producer devices is not permitted to be processed outside of the data processing environment.

[0032] The data consumer device also comprises measurement circuitry to take a measurement of the data processing environment in which the remotely generated data is to be processed, and attestation circuitry to provide to the plurality of data producer devices an attestation report based on the measurement of the data processing environment. The attestation report is provided to each of the data producer devices before receiving the remotely generated data from that data producer device.

[0033] The attestation report can provide each data producer device with information about how their remotely generated data will be processed by the data consumer device, because the attestation report is based on an actual measurement of the environment in which the data is to be processed. This contrasts to an alternative technique in which the data consumer device simply provides a certificate indicating that it can be trusted, because providing an attestation report based on a measurement allows the data producer device to make a decision about whether to transmit the remotely generated data based on the actual data processing environment, allowing each data producer device to make a decision about whether to transmit the remotely generated data.

[0034] As discussed below, the measurement could include a measurement of an address space accessible in the data processing environment, and / or a measurement of software which can operate on the remotely generated data. The attestation report could include a hash of the software which may operate on the remotely generated data, for example. In one example, a data producer may have previously identified a set of software which it is happy to operate on the remotely generated data, and stored a list of hashes of the acceptable software. The data producer device could compare a received hash included in the attestation report indicating the software which will operate on the remotely generated data against the list of hashes of predetermined acceptable software to determine whether to transmit the remotely generated data. However, it will be appreciated that the attestation report may reflect the measurement in many different ways, and this is merely an example.

[0035] Providing an attestation report to the plurality of data producer devices can therefore provide a guarantee to the data producer devices that the data consumer device will process the remotely generated data in some predetermined manner. Therefore, provision of the measurement circuitry and the attestation circuitry can enable a data consumer device to establish trust with a plurality of data producer devices, so that the plurality of data producer devices can determine when it is appropriate to transmit remotely generated data to the data consumer.

[0036] The inventors have recognised that there are potential challenges associated with providing an attestation report to a plurality of data producer devices based on certain types of measurement of a data processing environment. When one data producer device transmits data to the data consumer device and the data enters the data processing environment, then the data processing environment may change due to receipt of the remotely generated data. For example, after receipt of remotely generated data the address space accessible to the data processing environment now stores the remotely generated data, meaning that a hash of the address space is different compared to a hash calculated before the remotely generated data was received. Therefore, future measurements of the data processing environment received after some remotely generated data have been received may no longer reflect the data processing environment expected by data producer devices, and hence one might think that a measurement based attestation report would not be suitable for use with more than one data producer device.

[0037] However, the inventors have identified techniques which enable measurements to reflect an expected data processing environment even in cases where there are a plurality of data producer devices. In particular, the measurement circuitry may be configured to take the measurement in advance of data received from any of the plurality of data producer devices entering the data processing environment. By sending attestation reports to a plurality of data producer devices based on measurements taken before receipt of any remotely generated data, the attestation reports reflect the properties of the original data processing environment, and therefore can align with an expected measurement of the data processing environment, without being affected by the remotely generated data which could take unpredictable values.

[0038] Data producer devices may wish to transmit their remotely generated data to the data consumer device at different times. This presents a challenge in examples where measurements for the attestation report should be taken before any data enters the data processing environment, because the attestation report for a data producer device wishing to transmit its data at a later time may be required some time after a different data producer device is ready to transmit data to the data consumer device. Data consumer devices may wish to guarantee that the measurement taken of the data processing environment is recent, so that it can be trusted to accurately reflect the data processing environment.

[0039] In some examples, to ensure that the measurements taken for the attestation reports reflect the data processing environment before any remotely generated data is received even in cases where data producer devices transmit their data at different times, the data consumer device may prevent data received from the plurality of data producer devices from entering the data processing environment until an attestation process has been completed for a set of data producer devices. The set of data producer devices may include all of the data producer devices identified by the data producer identification circuitry, for example, or may include a subset of data producer devices (for example, in cases where certain data producer devices take longer than a threshold time to complete the attestation process).

[0040] The attestation process may include the attestation circuitry providing an attestation report to a given data producer device, and the data producer device deciding to transmit data to the consumer device, although as described below the attestation process may include further steps, such as attestation of the data producer environment and enforcement of policies. In the example described above, data is being prevented from entering the data processing environment at the time each attestation process is carried out for the set of data producer devices, meaning that new measurements can be taken for each attestation process. This means that there is freedom in deciding which process to use to guarantee that the measurement of the data processing environment is fresh. For example, the data producer devices may transmit some data to be combined with the measurement to prove that the measurement taken was fresh. As data has been prevented from entering the data processing environment, such new measurements can be taken freely whilst reflecting the expected original data processing environment. This compares to the case where data had already been allowed to enter the data processing environment before all of the attestation processes had been completed, as in such cases new measurements for later attestations may not be possible because at that point the data processing environment may have already received remotely generated data.

[0041] Data may be prevented from entering the data processing environment in several ways. For example, data delaying circuitry may be provided to buffer remotely generated data after receipt from data producer devices, only allowing the data to enter the data processing environment after the attestation process has been completed for the set of data producer devices. In other examples, sessions for receiving data from the set of data producer devices may not be established until the attestation process has completed for the set, meaning that data is not received by the data consumer device at all until the attestation process has completed for the set.

[0042] Whilst an example in which data is prevented from entering the data processing environment until all attestation processes had been completed for a set of data producer devices has been described above, this is not the only way to ensure that measurements of the data processing environment are taken before remotely generated data enters the data processing environment. In other examples, the attestation circuitry may provide attestation reports based on a previous measurement taken before data has entered the data processing environment, using the same measurement in attestation reports even after data has started to enter the data processing environment. This means that for later attestation processes, it may not be possible to take new measurements of the data processing environment (since at this point remotely generated data may already have entered the data processing environment). To provide a guarantee that the measurement is fresh, therefore, in such examples the attestation circuitry may be configured to include timestamp information in the attestation report indicating a time at which the attestation report was generated. Data producer devices may determine how old the measurement in the attestation report is based on the timestamp information, and based on the age of the attestation report and their own acceptable limits can determine whether to trust that the attestation report reflects the current data processing environment. Hence, including timestamp information in an attestation report means that older measurements can be used, allowing data to enter the data processing environment even before a set of data producer devices have completed an attestation process.

[0043] The measurement of the data processing environment is not particularly limited, and in general may include measurements which can indicate the ways that the remotely generated data may be processed in the data processing environment, such that a guarantee can be provided that the data will not be processed in ways which risk the privacy of that data.

[0044] For example, the measurement may comprise a measurement of which software can be executed in the data processing environment. This could include, for example, a hash of the software which may be executed in the data processing environment. By providing a measurement of the software which may operate on the remotely generated data, the data consumer device can provide data producer devices with a guarantee that their data will not be processed in other ways. For example, a data producer device may allow its remotely generated data to be used to identify the geographical location of a gunshot sound, and for that purpose may allow the data to be used by a device which executes software for calculating a geographical location of a gunshot using microphone and GPS data, and does not use the data for any other purpose.

[0045] As another example, the measurement may comprise a full measurement of an address space accessible to software executing in the data processing environment, including any code and data stored in the address space, for example. A hash of the address space could provide a guarantee that no malicious code is present which could use the remotely generated data incorrectly.

[0046] The above discussion has focussed on the data producer device receiving a guarantee of how its data will be processed by a potentially untrustworthy data consumer device. However, there is also a risk that the data producer device is untrustworthy and could, for example, provide inaccurate data leading to errors in the processing carried out by the data consumer device.

[0047] Therefore, in some examples, the processing circuitry of the data consumer device may be configured to receive a producer attestation report from a data producer device, the producer attestation report based on a measurement taken by said data producer device of a data generating environment provided by the data producer device for the generation of the remotely generated data. The data producer device may send a producer attestation report in response to a request by the data consumer device, for example. The measurement could include measurements of the software executable in the data generating environment, an address space available to such software, the sensors which may contribute to the remotely generated data, and so on. Generally, the measurements made of the data generating environment may be similar to the measurements taken by the measuring circuitry of the data processing environment, and may include sufficient information to allow the data consumer device to determine whether to trust the remotely generated data. The data generating environment may be measured before or after the remotely generated data has been generated (for example, the measurements may be made periodically and stored by the data producer device in anticipation that a data consumer device will request remotely generated data from the data producer device).

[0048] The processing circuitry of the data consumer device may be configured to determine whether to permit processing of the remotely generated data in the data processing environment in dependence on whether the producer attestation report indicates that the data producer device meets a set of producer device criteria enforced by the data consumer device. This could involve comparing a hash of the data generating software against a list of acceptable hashes, checking that the data generating environment is incapable of executing code to improperly modify the remotely generated data, and so on.

[0049] Hence, the data consumer device may be configured to both enforce a set of producer device criteria, and provide an attestation report based on measurements of the data processing environment, and therefore can be capable of establishing a two-way trust relationship between the data consumer device and a plurality of data producer devices.

[0050] In some examples, further restrictions on the use of remotely generated data may be provided by the use of policies. The processing circuitry of the data consumer device may be configured to receive policy code from one or more of the plurality of data producer devices, and initiate a policy enforcement processing environment to execute the policy code to enforce policies regarding use of the remotely generated data. Policies may relate to the sort of operations that may be performed on the remotely generated data, and as discussed below may restrict where the data can be used. Therefore, the data consumer device may provide a data processing environment to process the remotely generated data, and a policy enforcement processing environment to ensure that the remotely generated data is being used in an appropriate way. The use of policies can provide the data producer devices with a stronger guarantee that their data will not be misused than the attestation report alone, as it allows the data producer devices to not only trust that the remotely generated data will be used in an appropriate manner but provide code to ensure that the remotely generated data will be used in the appropriate manner. In some examples, the data consumer device may also be configured to provide an attestation report to a data producer device to attest that the policy enforcement processing environment was established correctly. For example, the measurement circuitry may be configured to take a measurement of the policy enforcement processing environment and the attestation report may be based on said measurement.

[0051] In some examples, the processing circuitry of the data consumer device may be configured to receive policy code from a plurality of the data producer devices and establish a policy enforcement processing environment to execute aggregate policy code to enforce a combination of policies of the two or more data producer devices. Enforcing policies from a plurality of data producer devices can establish trust with said plurality of data producer devices. However, the policies which different data producer devices wish to be enforced may not be compatible with each other. For example, data producer devices may wish the data consumer device to enforce policies limiting which software can operate on the remotely generated data, and two data producer devices may provide policy code directed to non-overlapping sets of software. Therefore, the processing circuitry may be configured to discard one or more incompatible policies received from data producer devices, and in some examples may determine not to receive remotely generated data from data producer devices from which policy code was received that has since been discarded (although in some examples the policies may be optional and therefore the data producers may still provide remotely generated data even when their transmitted policy code cannot be enforced).

[0052] In some examples, the policies enforced by the policy enforcement processing environment may control at least one of input of data into the data processing environment and output of data from the data processing environment. By controlling what data may enter and leave the data processing environment, the policies may ensure that the remotely generated data is not used in incorrect ways. For example, code which could operate on the remotely generated data in an undesirable way can be prevented from entering the data processing environment, data may be anonymised on entry in to the data processing environment, and certain data may be prevented from entering the data processing environment. In addition, the remotely generated data can be prevented from leaving the data processing environment for use elsewhere in the data consumer device. Hence, the data can be constrained to the data processing environment, and for example only data outputs based on approved processing of the remotely generated data (e.g., geographical locations of gunshots, 3D models of vehicles, a model of a power network) may be permitted to leave the data processing environment, to keep the remotely generated data itself secure.

[0053] The data processing environment may be provided in different ways. In general, the data processing environment may be an isolated environment having a dedicated address space, where access to the dedicated address space is controlled to prevent access by untrusted code.

[0054] In some examples, the processing circuitry may perform processing in one of a plurality of domains. The data consumer device may comprise address translation circuitry to translate a target virtual address of a memory access request, associated with one of a plurality of domains of processing, into a target physical address, where the target physical address is in one of a plurality of physical address spaces selected based on the current domain. The apparatus may also comprise checking circuitry to determine whether to reject a memory access request to a target physical address based on protection information corresponding to the target physical address, the protection information specifying which of the plurality of physical address spaces is allowed to provide access to the target physical address.

[0055] Hence, access to physical addresses can be controlled based on the domain of processing from which a memory access request was issued. For example, the domains may include a more secure domain associated with a more secure physical address space and a less secure domain associated with a less secure physical address space. The address translation circuitry may be prohibited from selecting the more secure physical address space for memory access requests issued in the less secure domain, so that the less secure domain is unable to access data in locations identified by a physical address in the more secure physical address space.

[0056] In some examples, the data processing environment may be provided within the more secure physical address space, meaning that the data processing environment is not accessible by software executing in the less secure domain, to keep the remotely generated data secure. Several isolated regions of the more secure physical address space may be provided by management software (e.g., a hypervisor), so that two or more data processing environments can be provided which are simultaneously isolated from each other via the management software and are isolated from the less secure domain due to the address translation and checking circuitry.

[0057] In some examples, the plurality of domains may further include a realm domain associated with a realm physical address space. The address translation circuitry may be prohibited from selecting the realm physical address space for memory access requests issued in the more secure domain or the less secure domain. Therefore, data stored in locations identified by addresses in the realm physical address space may be isolated from software executing in both the more secure and less secure domains. This can provide a strong guarantee of security for data stored in the realm physical address space, because it isolated from large amount of code executing on the system. This enables increased isolation from other processes running in the more secure domain, which could access the data processing environment in the case that the hypervisor was compromised. Additionally, being separate from the more secure and less secure domains means that a much smaller amount of memory may be assigned to the realm physical address space. This reduced size means that measuring and attesting regions of the realm physical address space becomes much more practical. Hence, in some examples, the data processing environment is provided within a region of the realm physical address space, said region also referred to as a realm. One or more realms may be defined in the realm physical address space, isolated from each other by a realm management monitor (RMM). In some examples, realms may be provided according to the Realm Management Extension (RME) System Architecture and Confidential Compute Architecture (CCA) provided by Arm® Ltd, Cambridge, United Kingdom.

[0058] In addition to the data processing environment being provided by a realm, the policy enforcement processing environment and the data generation environment may also be provided by a realm provided by the consumer and producer devices respectively. The pre-processing environment discussed below may also be provided by a realm.

[0059] In some examples, the attestation circuitry may be configured to include in the attestation report a public key of a key pair. The key pair comprises a private key and a public key, which can be used in a process for securing the remotely generated data so that said data can be transmitted over a potentially untrusted network. In some examples, a message encrypted with the public key can only be decrypted using the private key. The public key may be provided to the plurality of data producer devices to encrypt the remotely generated data, and the data processing environment of the consumer device may have access to (e.g., store in its associated address space) the private key corresponding to the public key, enabling the remotely generated data to be decrypted after receipt from the plurality of data producer devices. This asymmetrical cryptography process may be considered too slow in some examples, and therefore in other examples the public / private key pair may be used to exchange keys at the start of a communication session between the data producer and data consumer, and communication thereafter may use session keys established for that communication session (where the use of session keys is symmetrical cryptography, and faster than the asymmetrical cryptography discussed above). Hence, the remotely generated data may be encrypted with a session key established using the public / private key pair. The public key may, for example, be used to verify a digital signature using a digital signature algorithm. For example, a TLS handshake may be performed between the data producer device and data consumer device to establish session keys for encrypting the remotely generated data, and certain data required during the TLS handshake may be communicated in the attestation report. Hence, in some examples, the TLS handshake may be incorporated into the attestation process.

[0060] Whilst the public key may be used in different ways discussed above, in general the public key enables the remotely generated data to be encrypted for transmission over a network.

[0061] In some examples, a given data producer device may be configured to determine whether to send remotely generated data to the data consumer device in dependence on whether the attestation report indicates that the data processing environment meets a set of consumer device criteria enforced by the given data producer device. For example, the data producer device may compare a hash of the software executable by the data processing environment against a list of acceptable hashes. The data producer device may also enforce certain scenario specific criteria. For example, when a consumer device requests data to locate a gunshot, the data producer device may require the consumer to provide (e.g., via the attestation report) evidence that the consumer has posted the request to an appropriate transparency log.

[0062] In some examples, the plurality of data producer devices and optionally the data consumer device trust a trusted verifying entity. For example, the trusted verifying entity may be a separate device which can communicate via a network, and which may be operated by a trusted operator. In some examples, the trusted verifying entity is configured to provide an indication to the plurality of data producer devices of whether the attestation report generated by the attestation circuitry satisfies a set of verification criteria. The trusted verifying entity may sign the attestation report (e.g., by combining signature information with the attestation report) in response to determining that the attestation report satisfies the verification criteria, indicating that the attestation report can be trusted to be accurate. In some examples, the attestation report may be provided to the trusted verifying entity by the data consumer device and then a signed attestation report may be returned to the data consumer device to provide the signed attestation report to the plurality of data producer devices. In other examples, the data consumer device may provide an unsigned attestation report to the plurality of data producer devices and the data producer devices may send the attestation report to the trusted verifying entity for verification, receiving a signed attestation report back from the trusted verifying entity if the verification criteria are satisfied.

[0063] In either case, using a third party trusted verifying entity means that the data producer devices can trust that the attestation report was generated accurately and therefore the indicated measurements of the data processing environment can be trusted.

[0064] The trusted verifying entity may also be used to sign other attestation reports used in an attestation process between the data consumer device and a data producer device. For example, the producer attestation report may be signed by the verifying entity, an attestation of the policy enforcement environment may be verified, and an attestation of a pre-processing environment (discussed below) may be verified. Generally, the trusted verifying entity allows an establishment of trust in an attestation process.

[0065] In some examples, the attestation circuitry may be configured to include in the attestation report a hardware measurement indicating a hardware property of the processing circuitry of the data consumer device. For example, the hardware measurement may include a measurement of a unique identifying value (an endorsement) stored in the device on manufacture to provide an identity of the consumer device. The hardware measurement may also or alternatively include in the attestation report values measured during a measured boot process, which can indicate whether the consumer device has been compromised in any way which may cause it to be untrusted.

[0066] The trusted verifying entity may be configured to apply verification criteria indicating expected values of the hardware measurement, such that compromised consumer devices do not meet the verification criteria, and therefore attestation reports from compromised consumers are not signed.

[0067] In some examples, there may be a large volume of raw sensor data gathered by data producer devices, and the transmission and storage of such data may be inefficient and slow. Hence, it may be desired to perform certain pre-processing on the remotely generated data in advance of said data being transmitted to the data consumer device. In some examples, the plurality of data processing devices may already perform certain pre-processing on the data, such as applying generic compression algorithms.

[0068] However, in some examples, specific types of pre-processing may be desired or the data producer devices may not include any generic pre-processing code. Therefore, the data consumer device may be configured to send pre-processing code to at least one of the plurality of data producer devices. The data producer device receiving the pre-processing code may initiate a pre-processing environment to execute the pre-processing code to perform a preprocessing operation on the remotely generated data in advance of said data being sent to the data consumer device. The pre-processing environment may isolate the pre-processed data from the rest of the data producer device in situations where the pre-processing code, or the results of pre-processing, are sensitive.

[0069] The data producer device may be configured to attest to the data consumer device that the pre-processing environment has been established correctly.

[0070] The pre-processing operation may generally be an operation to reduce the size of data being transmitted over the network, and / or to reduce the amount of processing which needs to be carried out on the remotely generated data by the data consumer device. For example, the data processing environment may have limited resources so it may be desired to distribute some of the processing requirements to the data producer devices. Whilst pre-processing may involve generic compression, in other examples the pre-processing may be more specific to the scenario. For example, when a consumer is attempting to locate a gunshot, then instead of providing raw audio data from a microphone, a data producer device may pre-process the audio data to identify “pops” and provide information indicating the times that any pops were detected, significantly reducing the amount of data which may be transmitted to the data consumer device.

[0071] In some examples, the remotely generated data is generated in dependence on sensor data provided by at least one sensor of a data producer device. The sensor data may be indicative of a physical environment of the data producer device, so that receiving remotely generated data from the plurality of data producer devices enables the data consumer device to receive information about a remote physical environment.

[0072] The techniques described herein will now be described with reference to the Figures.

[0073] Figure 1 illustrates a processing system comprising a data consumer device 2 and a plurality of data producer devices 4.

[0074] As discussed with reference to various scenarios above, a data consumer device 2 may wish to aggregate remotely generated data from a plurality of data producer devices 4. However, the data producer devices 4 may be unwilling to transmit potentially sensitive data to the data consumer device 2. Therefore, the data consumer device 2 according to the present technique is configured to provide an attestation report to the plurality of data producer devices 4, which is based on a measurement of the data consumer device 2 and therefore provides a guarantee that any remotely generated data received from the plurality of data producer devices 4 will be processed in a predetermined manner. A data producer device 4 according to the present technique can therefore make an informed decision about whether to transmit data to the data consumer device 2, which may result in data being shared in ways which would have previously not been possible.

[0075] The data consumer device 2 comprises data producer identification circuitry 6. The data producer identification circuitry 6 may identify a plurality of data producer devices 4 from which the data consumer device would like to receive remotely generated data. For example, the data producer identification circuitry 6 may reference a database indicating properties of candidate data producer devices, and may identify a plurality of selected producer devices 4 based on various factors such as their geographical location, types of sensor, owner, network connectivity, and so on. Instead of or in addition to a database, candidate data producer devices may also be identified using a peer-to-peer protocol, for example data producer devices 4 may indicate their properties to nearby devices, who may share those details with devices nearby to themselves, and so on to create a network of devices sharing information about other devices. Of course, other techniques could be used to identify candidate data producer devices 4 to the data consumer device 2.

[0076] The data consumer device 2 comprises processing circuitry 8. The consumer processing circuitry 8 provides a data processing environment (as discussed later, this may be a realm) in which the remotely generated data received from the plurality of data producers can be processed to provide some output. The output may be a result based on the aggregation of data from the plurality of data producer devices 4, such as a geographical location or a 3D model, which may exclude the remotely generated data itself, thereby decoupling the output from the remotely generated data to maintain privacy of the remotely generated data.

[0077] The consumer processing circuitry 8 may comprise storage circuitry which may include one or more caches and main memory, or may have access to storage locations provided externally to the processing circuitry 8. The storage locations are addressed by physical addresses, to provide a physical address space accessible to the consumer processing circuitry 8.

[0078] The data processing environment provided by the processing circuitry 8 may have access to a region of the physical address space, and software may be stored in the accessible region to perform data processing on the remotely generated data.

[0079] The data consumer device 2 also comprises measurement circuitry 10 to take a measurement of the data processing environment. For example, the measurement circuitry 10 may calculate a hash or some other function of the data stored in the entire address space accessible to the data processing environment, and / or a function of the executable data (the software) stored in the address space, and / or a function of software responsible for managing the data processing environment, such as realm management software. It will be appreciated that other aspects of the data processing environment can also be measured by the measurement circuitry 10, and in general the measurements serve to indicate a manner in which the remotely generated data will be processed by the data consumer device 2, to provide a guarantee that remotely generated data will not be misused.

[0080] The data consumer 2 also comprises attestation circuitry 12. The attestation circuitry 12 generates an attestation report based on the measurements taken by the measurement circuitry 10. For example, the attestation report may include measurements taken by the measurement circuitry 10. The attestation report may also include further information, such as hardware information about the data consumer device 2 such as values set on manufacture, values recorded during a measured boot, and so on. The attestation report may also include a public key of a key pair, with the private key remaining in the data consumer device 2, to allow the plurality of data producer devices 4 to encrypt remotely generated data to be sent to the data consumer 2. It will be appreciated that the attestation report may include further information.

[0081] The data consumer device 2 is capable of receiving remotely generated data from a plurality of data producer devices 4. The data producer devices 4 and the data consumer 2 may communicate via a network, such as a wireless network, so that the attestation report can be transmitted from the data consumer device 2 to the plurality of data producer devices 4 and so that the remotely generated data can be provided to the data consumer device 2 from the plurality of data producer devices 4, along with any other information which may be transmitted according to various options discussed below.

[0082] Figure 1 shows only one data producer device in detail, but it will be appreciated that each data producer device may comprise similar components. Each data producer device 4 comprises data generation circuitry 16 to initiate a data generation processing environment in which remotely generated data is generated. For example, the data generating circuitry 16 may have access to one or more sensors 20 for gathering information, such as information about the local environment of the data producer, and the remotely generated data may be generated on the basis of information captured by the sensor(s) 20.

[0083] The data producers 4 may also comprise producer processing circuitry 18 which is capable of providing a producer processing environment, such as a pre-processing environment for the pre-processing of remotely generated data (discussed in further detail below). Although not shown, the data producer 4 may also comprise producer measurement circuitry capable of taking measurements of the data generating circuitry 16 and the producer processing circuitry 18, to enable attestation reports to be generated in respect of a data generating processing environment and a pre-processing environment.

[0084] At least one of the data consumer device 2 and the plurality of data producer devices 4 have access to a trusted verifying entity 14. The trusted verifier 14 is trusted by at least the plurality of data producer devices 4, for example due to being managed by a trusted entity. As described later, the trusted verifier 14 may assess attestation reports (e.g., analysing data included in the attestation report) and sign attestation reports which meet certain verification criteria, the signature indicating that the trusted verifier 14 believes the attestation report has been generated accurately. The trusted verifier 14 may be accessible via a network, such as the same network used to connect the data consumer 2 and the plurality of data producer devices.

[0085] Figure 2 illustrates an attestation process between a data consumer device 2 and a data producer device 4 which is one of the plurality of data producer devices from which the data consumer device 2 wishes to request remotely generated data. Dashed lines indicate optional steps and solid lines indicate steps that are not optional if remotely generated data is to be received. Figure 2 illustrates an order of events which may take place for remotely generated data to be received by the data consumer device 2, although the order of specific events, particularly events which are not dependent on another event, may vary in different implementations.

[0086] In Figure 2, the process starts when the data producer identification circuitry 6 of the data consumer device 2 identifies the data producer device 4 as satisfying certain requirements. For example, the data producer device 4 may have been identified from a set of candidate devices as a device located in an area of interest having a sensor of the right type, such as a camera located near to the location of a vehicle accident. The consumer device 2 at step 200 may first contact the producer device 4 indicating that it would like to start the attestation process (which can enable the seed of step 206 to be sent before the attestation report). In other examples, transmitting the attestation report at step 208 may be the first contact between consumer and producer. In yet another example, the producer 4 may offer its data to the consumer 2 and therefore initiate contact.

[0087] At some point before the attestation report is sent at step 208, at step 202 the processing circuitry 8 of the consumer device 2 establishes a data processing environment, such as a data processing realm as discussed later. The measurement circuitry 10 takes one or more measurements of the data processing realm, and the attestation circuitry 12 includes those measurements in an attestation report.

[0088] The attestation report may also include a seed provided to the data consumer 2 by the data producer 4 in step 206. By combining the seed into the attestation report, the attestation circuitry 12 can prove to the producer that the attestation report is fresh and reflects the current condition of the data processing environment. However, this may require that the data processing environment has not already received any remotely generated data from other producer devices, otherwise a new measurement would not reflect a freshly initiated data processing realm and may not satisfy the producer requirements. Therefore, in an alternative example the attestation circuitry 12 may generate an attestation report based on measurements taken before any data enters the data processing environment, timestamp the attestation report (e.g., by sending the attestation report to a separate timestamping server) and then use the timestamped attestation report for sending to data producer devices 4, allowing devices to complete the attestation process even after remotely generated data has entered the data processing environment.

[0089] In either case, at step 208 the consumer device sends an attestation report to the data producer device. The attestation report may be signed or unsigned by the trusted verifier 14, as in some examples the consumer device 2 may transmit the attestation report to the verifier 14 before sending it to the producer, and in other examples the producer 4 may send the attestation report to the verifier 14 for signing. If the verification fails, then the producer does not send data to the consumer 2. As previously mentioned, the attestation report may be either timestamped or include seed information from the producer to indicate freshness. At step 210, the data producer device compares the information transmitted in the attestation report to a list of criteria that said producer enforces for consumer devices wishing to use its data. For example, a hash of the address space accessible to the data processing environment may be compared against a list of allowed hashes, so the address space contains only software which is permitted to act on the remotely generated data and no other software. Further scenario-specific criteria may also be enforced, such as checking that the request has been publically recorded in a transparency log.

[0090] At step 212, the data producer 4 may also transmit an attestation report to the data consumer 2, including measurements of the data generation environment. The producer attestation report may be transmitted in response to a request by the consumer device 2. The attestation report transmitted by the data producer 4 may allow mutual trust to be established between the consumer 2 and producer 4, such that the producer can trust that the remotely generated data will be used in a safe way and the consumer can trust that the remotely generated data was generated accurately. Therefore, at step 214 the data consumer device 2 may compare measurements included in the producer attestation report against criteria enforced by the data consumer device 2.

[0091] At step 216, the data producer device 4 may transmit to the data consumer device 2 policy code. The policy code can enable a policy enforcement processing environment to be established in the data consumer device 2 at step 218 (which may be referred to herein as a policy realm when realms are used to implement the policy enforcement processing environment as discussed below), with the policy code executed in said environment enforcing various policies regarding the use of the remotely generated data. The policy enforcement processing environment may be a separate processing environment from the data processing environment, or may be provided by the data processing environment. The policy enforcement processing environment may control the way remotely generated data is allowed to enter and leave the data processing environment. Before processing by the data processing environment, the policy may anonymise data entering the data processing environment, may prohibit a piece of remotely generated data from being used if it contains certain information, and may retain local state to make determinations on how to handle the data. After processing by the data processing environment, the policy environment may operate on a block of output data to ensure that policies are met (e.g., by anonymising the output), allow or prevent the transfer of data to a following stage of a processing pipeline or on to a further participant, or retain local state. Hence, transmitting policy code at step 216 can allow a data producer device 4 to have greater control over the downstream use of that data, and can improve the trust a data producer 4 can have in a data consumer 2 beyond that provided by the attestation report alone.

[0092] At step 220 the data consumer device 2 may send an attestation report to the data producer device 4 to attest that the policy enforcement processing realm has been correctly established. At step 222, the data consumer device 2 may transmit pre-processing code to the data producer device 4. The pre-processing code may include scenario-specific or general code which can enable the data producer device to operate on the remotely generated data to reduce the amount of remotely generated data which needs to be transmitted to the data consumer device, and / or can reduce the amount of processing which needs to be carried out by the data consumer device. At step 224, the data producer device 4 may establish a processing environment using producer processing circuitry 18 in which to carry out pre-processing according to the preprocessing code. The pre-processing environment (referred to as a pre-processing realm in examples implementing the processing environment using realms) may in some examples be the same processing environment as the data generation environment provided for the generation of the remotely generated data. At step 226 the data producer may attest to the data consumer that the pre-processing environment has been initiated correctly. The data producer device 4 then optionally carries out pre-processing according to the pre-processing code at step 228.

[0093] The data producer device 4 may determine whether to send the remotely generated data to the data consumer device 2. The decision is based at least on whether the attestation report has been validly signed and indicates that the data consumer device meets certain criteria. The data producer device 4 may also require that a policy enforcement processing environment has been correctly established and attested. In response to determining that the criteria are satisfied, and optionally in response to completing pre-processing, at step 230 the data producer device 4 transmits the remotely generated data to the data consumer device. The remotely generated data may first be encrypted with a public key transmitted in the attestation report, such that the data is inaccessible to a receiver other than the data processing environment of the data consumer device which has exclusive access to the private key.

[0094] The data consumer device 2 may determine whether to allow the transmitted remotely generated data to enter the data processing environment, for example dependent on the data producer device 4 correctly attesting the data generation environment and the pre-processing environment. The data consumer device 2 may also delay allowing the remotely generated data from entering the data processing environment until the attestation process of Figure 2 has been carried out for a set of producer devices (particularly in the case where attestation requires use of a seed as in step 206 where attestation for a further device may no longer be possible after data enters the data processing environment).

[0095] When the remotely generated data is permitted to enter the data processing environment, the policy enforcement processing environment may control its use at step 232, and at step 234 the remotely generated data is processed by aggregating it with data from other data producer devices.

[0096] The process of Figure 2 includes several attestations. Figure 3 indicates the process of a general attestation. Each attestation involves an attester proving that they are trustworthy, a relying party to whom the attester is proving that they are trustworthy, and a verifier (a trusted verifying entity) for verifying that the attestation report is accurate. In the attestations of the data processing environment and the policy enforcement processing environment the data consumer is the attester and each data producer is a relying party, whereas in the attestations of the data generation environment and the pre-processing environment the data consumer device is the relying party and the data producer device is the attester. The verifier may be the same for each attestation or may differ.

[0097] Figure 3 shows two models of attestation, either or which may be used for any of the attestations shown in Figure 2. In general, the attester provides some evidence of the processing environment it is attesting (such as measurements of the processing environment) some evidence of the hardware of the attester such as values set at manufacture or measured during boot, which can indicate whether the attester has been modified. The attester transmits the evidence (e.g., in an attestation report) either directly to the verifier or to the relying party.

[0098] In the first example shown in Figure 3, the evidence is sent directly to the verifier which assesses based at least on the hardware measurements whether the attester / evidence can be trusted. The verifier then sends an attestation result (e.g., a signed attestation report) back to the attester. The attester can then send the attestation result to the relying party.

[0099] In the second example shown in Figure 3, the evidence is sent to the relying party who then sends the evidence to the verifier which sends the attestation result back to the relying party.

[0100] The various “environments” described herein can be implemented in a variety of ways, but in one example implementation one or more of them may be implemented as realms. Figure 4 shows an example of different operating states and domains in which the processing circuitry 8 and 18 can operate in one implementation, where the use of realms is supported.

[0101] The processing circuitry is operable at a number of different exception levels 80, in this example four exception levels labelled ELO, EL1 , EL2 and EL3, where in this example EL3 refers to the exception level with the greatest level of privilege while ELO refers to the exception level with the least privilege. It will be appreciated that other architectures could choose the opposite numbering so that the exception level with the highest number could be considered to have the lowest privilege. In this example the least privileged exception level ELO is for application-level code, the next most privileged exception level EL1 is used for operating system-level code, the next most privileged exception level EL2 is used for hypervisor-level code which manages switching between a number of virtualised operating systems, while the most privileged exception level EL3 is used for monitor code which manages switches between respective domains and allocation of physical addresses to physical address spaces, as described later.

[0102] When an exception occurs while processing software in a particular exception level, for some types of exceptions, the exception is taken to a higher (more privileged) exception level, with the particular exception level in which the exception is to be taken being selected based on attributes of the particular exception which occurred. However, it may be possible for other types of exceptions to be taken at the same exception level as the exception level associated with the code being processed at the time an exception was taken, in some situations. When an exception is taken, information characterising the state of the processor at the time the exception was taken may be saved, including for example the current exception level at the time the exception was taken, and so once an exception handler has been processed to deal with the exception, processing may then return to the previous processing and the saved information can be used to identify the exception level to which processing should return.

[0103] In addition to the different exception levels, the processing circuitry also supports a number of domains of operation (also known as “security states”), the domains including a root domain 82, a more secure (S) domain 84, a less secure domain 86 and a realm domain 88. For ease of reference, the less secure domain will be described below as the “non-secure” (NS) domain, but it will be appreciated that this is not intended to imply any particular level of (or lack of) security. Instead, “non-secure” merely indicates that the non-secure domain is intended for code which is less secure than code operating in the secure domain. The root domain 82 is selected when the processing circuitry 10 is in the highest exception level EL3. When the processing circuitry is in one of the other exception levels ELO to EL2, the current domain is selected based on the current domain indicator 14, which indicates which of the other domains 84, 86, 88 is active. For each of the other domains 84, 86, 88 the processing circuitry could be in any of the exception levels ELO, EL1 or EL2.

[0104] At boot time, a number of pieces of boot code (e.g. BL1 , BL2, OEM Boot) may be executed, e.g. within the more privileged exception levels EL3 or EL2. The boot code BL1 , BL2 may be associated with the root domain for example and the OEM boot code may operate in the Secure domain. However, once the system is booted, at runtime the processing circuitry 10 may be considered to operate in one of the domains 82, 84, 86 and 88 at a time. Each of the domains 82 to 88 is associated with its own associated physical address space (PAS) which enables isolation of data from the different domains within at least part of the memory system. This will be described in more detail below.

[0105] The non-secure domain 86 can be used for regular application-level processing, and for the operating system and hypervisor activity for managing such applications. Hence, within the non-secure domain 86, there may be application code 30 operating at ELO, operating system (OS) code 32 operating at EL1 and hypervisor code 34 operating at EL2.

[0106] The secure domain 84 enables certain system-on-chip security, media or system services to be isolated into a separate physical address space from the physical address space used for non-secure processing. The secure and non-secure domains are not equal, in the sense that the non-secure domain code cannot access resources associated with the secure domain 84, while the secure domain can access both secure and non-secure resources (at least for regions of memory for which the predetermined less-secure memory property described further below is not defined). An example of a system supporting such partitioning of secure and non-secure domains 84, 86 is a system based on the TrustZone® architecture provided by Arm® Limited. The secure domain can run trusted applications 36 at ELO, a trusted operating system 38 at EL1 , as well as optionally a secure partition manager 40 at EL2 which may, if secure partitioning is supported, use stage 2 page tables to support isolation between different trusted operating systems 38 executing in the secure domain 84 in a similar way to the way that the hypervisor 34 may manage isolation between virtual machines or guest operating systems 32 executing in the non-secure domain 86.

[0107] Extending the system to support a secure domain 84 has become popular in recent years because it enables a single hardware processor to support isolated secure processing, avoiding the need for the processing to be performed on a separate hardware processor. However, with the increasing popularity of use of the secure domain, many practical systems having such a secure domain now support, within the secure domain, a relatively sophisticated mixed environment of services which are provided by a wide range of different software providers. For example the code operating in the secure domain 84 may include different pieces of software provided by (among others): the silicon provider who manufactured the integrated circuit, an original equipment manufacturer (OEM) who assembles the integrated circuit provided by the silicon provider into an electronic device such as a mobile telephone, an operating system vendor (OSV) who provides the operating system 32 for the device; and / or a cloud platform provider who manages a cloud server supporting services for a number of different clients through the cloud.

[0108] However, increasingly there is a desire for parties providing user-level code (which might normally be expected to execute as applications 30 within the non-secure domain 86) to be provided with secure computing environments which can be trusted not to leak information to other parties operating code on the same physical platform. It may be desirable for such secure computing environments to be dynamically allocatable at runtime, and to be certified and attestable so that the user is able to verify whether sufficient security guarantee is provided on the physical platform, before trusting the device to process potentially sensitive code or data. A user of such software may not wish to trust the party providing a rich operating system 32 or hypervisor 34 which might normally operate in the non-secure domain 86 (or even if those providers themselves can be trusted, the user may wish to protect themselves against the operating system 32 or hypervisor 34 being compromised by an attacker). Also, while the secure domain 84 could be used for such user-provided applications needing secure processing, in practice this causes problems both for the user providing the code requiring the secure computing environment and for the providers of existing code operating within the secure domain 84. For the providers of existing code operating within the secure domain 84, the addition of arbitrary user- provided code within the secure domain would increase the attack surface for potential attacks against their code, which may be undesirable, and so allowing users to add code into the secure domain 84 may be strongly discouraged. On the other hand, the user providing the code requiring the secure computing environment may not be willing to trust all of the providers of the different pieces of code operating in the secure domain 84 to have access to its data or code, if certification or attestation of the code operating in a particular domain is needed as a prerequisite for the user- provided code to perform its processing, it may be difficult to audit and certify all of the distinct pieces of code operating in the secure domain 84 provided by the different software providers, which may limit the opportunities for third parties to provide more secure services.

[0109] Therefore, as shown in Figure 4, an additional more secure domain 88, called the realm domain, is provided which can be used by such user-introduced code to provide a secure computing environment orthogonal to any secure computing environment associated with components operating in the secure domain 24. In the realm domain, the software executed can include a number of realms, where each realm can be isolated from other realms by a realm management module (RMM) 46 operating at exception level EL2. The RMM 46 may control isolation between the respective realms 42, 44 executing the realm domain 88, for example by defining access permissions and address mappings in page table structures similar to the way in which hypervisor 34 manages isolation between different components operating in the nonsecure domain 86. In this example, the realms include an application-level realm 42 which executes at ELO and an encapsulated application / operating system realm 44 which executes across exception levels ELO and EL1. It will be appreciated that it is not essential to support both ELO and EL0 / EL1 types of realms, and that multiple realms of the same type could be established by the RMM 46.

[0110] The realm domain 88 has its own physical address space allocated to it, similar to the secure domain 84, but the realm domain is orthogonal to the secure domain 84 in the sense that while the realm and secure domains 88, 84 can each access the non-secure PAS associated with the non-secure domain 86, the realm and secure domains 88, 84 cannot access each other’s physical address spaces. This means that code executing in the realm domain 88 and secure domains 84 have no dependencies on each other. Code in the realm domain only needs to trust the hardware, the RMM 46 and the code operating in the root domain 82 which manages switching between domains, which means attestation and certification becomes more feasible. Attestation enables a given piece of software to request verification that code installed on the device matches certain anticipated properties. This could be implemented by checking whether a hash of the program code installed on the device matches an expected value that is signed by a trusted party using a cryptographic protocol. The RMM 46 and monitor code 29 could for example be attested by checking whether a hash of this software matches an expected value signed by a trusted party, such as the silicon provider who manufactured the integrated circuit comprising the processing system 2 or an architecture provider who designed the processor architecture which supports the domain-based memory access control. This can allow user-provided code 42, 44 to verify whether the integrity of the domain-based architecture can be trusted prior to executing any secure or sensitive functions.

[0111] Hence, it can be seen that the code associated with realms 42, 44, which would previously have executed in the non-secure domain 86 as shown by the dotted lines showing the gap in the non-secure domain where these processes would previously have executed, can be moved to the realm domain where they may have stronger security guarantees because their data and code is not accessible by other code operating in a non-secure domain 86. However, due to the fact that the realm domain 88 and secure domain 84 are orthogonal and so cannot see each other’s physical address spaces, this means that the providers of code in the realm domain do not need to trust the providers of code in the secure domain and vice versa. The code in the realm domain can simply trust the trusted firmware providing the monitor code 29 for the root domain 82 and the RMM 46, which may be provided by the silicon provider or the provider of the instruction set architecture supported by the processor, who may already inherently need to be trusted when the code is executing on their device, so that no further trust relationships with other operating system vendors, OEMs or cloud hosts are needed for the user to be able to be provided with a secure computing environment.

[0112] The data processing environment, the data generation environment, the policy enforcement processing environment, and the pre-processing environment may each be provided as a realm executing in the realm domain, and having access to an address space in the realm physical address space. By providing these processing environments as realms, isolation from software executing in the non-secure and secure domains can be provided by hardware, increasing the security offered to the remotely generated data. In addition, systems may already support mechanisms allowing for the attestation of realms, meaning that the overhead associated with providing attestation reports may be reduced.

[0113] Alternatively, the processing environments may be provided as applications executing within the secure domain, for example in implementations not supporting a separate realm domain.

[0114] As shown in Figure 4, a separate root domain 82 is provided which manages domain switching, and that root domain has its own isolated root physical address space. The creation of the root domain and the isolation of its resources from the secure domain allows for a more robust implementation even for systems which only have the non-secure and secure domains 86, 84 but do not have the realm domain 88, but can also be used for implementations which do support the realm domain 88. The root domain 82 can be implemented using monitor software 29 provided by (or certified by) the silicon provider or the architecture designer, and can be used to provide secure boot functionality, trusted boot measurements, system-on-chip configuration, debug control and management of firmware updates of firmware components provided by other parties such as the OEM. The root domain code can be developed, certified and deployed by the silicon provider or architecture designer without dependencies on the final device. In contrast the secure domain 84 can be managed by the OEM for implementing certain platform and security services. The management of the non-secure domain 86 may be controlled by an operating system 32 to provide operating system services, while the realm domain 88 allows the development of new forms of trusted execution environments which can be dedicated to user or third party applications while being mutually isolated from existing secure software environments in the secure domain 84.

[0115] Figure 5 illustrates an example of components which may be provided in a data consumer device or data producer device for supporting the provision of realms. Figure 5 shows address translation circuitry 17, which comprises stage 1 and stage 2 memory management units 50, 52. The stage 1 MMU 50 may be responsible for translating virtual addresses of memory access requests issued by processing circuitry within the device to either physical addresses (when the translation is triggered by EL2 or EL3 code) or to intermediate addresses (when the translation is triggered by ELO or EL1 code in an operating state where a further stage 2 translation by the stage 2 MMU 52 is required). The stage 2 MMU may translate intermediate addresses into physical addresses. The stage 1 MMU may be based on page tables controlled by an operating system for translations initiated from ELO or EL1 , page tables controlled by a hypervisor for translations from EL2, or page tables controlled by monitor code 29 for translations from EL3. On the other hand, the stage 2 MMU 52 may be based on page table structures defined by a hypervisor 34, RMM 46 or secure partition manager 14 depending on which domain is being used. Separating the translations into two stages in this way allows operating systems to manage address translation for themselves and applications under the assumption that they are the only operating system running on the system, while the RMM 46, hypervisor 34 or SPM40 may manage isolation between different operating systems running in the same domain.

[0116] As shown in Figure 5, the address translation process using the address translation circuitry 17 may return security attributes 54 which, in combination with the current exception level 15 and the current domain 13 (or security state), allow section of a particular physical address space (identified by a PAS identifier or “PAS TAG”) to be accessed in response to a given memory access request. The physical address and PAS identifier may be looked up in a granule protection table 56 which provides granule protection information. In this example the PAS filter 21 is shown as a granular memory protection unit (GMPU) which verifies whether the selected PAS is allowed to access the requested physical address and if so allows the transaction to be passed to any caches 24 or interconnect 8 which are part of the system fabric of the memory system.

[0117] The GMPU 21 allows assigning memory to separate address spaces while providing a strong, hardware-based, isolation guarantee and providing spatial and temporal flexibility in the assignment methods of physical memory into these address spaces, as well as efficient sharing schemes. As described earlier, the execution units in the system are logically partitioned to virtual execution states (domains or “Worlds”) where there is one execution state (Root world) located at the highest exception level (EL3), referred to as the “Root World” that manages physical memory assignment to these worlds.

[0118] A single System physical address space is virtualized into multiple “Logical” or “Architectural” Physical Address Spaces (PAS) where each such PAS is an orthogonal address space with independent coherency attributes. A System Physical Address is mapped to a single “Logical” Physical Address Space by extending it with a PAS tag.

[0119] A given World is allowed access to a subset of Logical Physical Address Spaces. This is enforced by a hardware filter 21 that can be attached to the output of the Memory Management Unit 17.

[0120] A World defines the security attributes (the PAS tag) of the access using fields in the Translation Table Descriptor of the page tables used for address translation. The hardware filter 21 has access to a table (Granule Protection Table 56, or GPT) that defines for each page in the system physical address space granule protection information (GPI) indicating the PAS TAG it is associated with and (optionally) other Granule Protection attributes.

[0121] The hardware filter 21 checks the World ID and the Security Attributes against the Granule’s GPI and decides if access can be granted or not, thus forming a Granular Memory Protection Unit (GMPU).

[0122] The GPT 56 can reside in on-chip SRAM or in off-chip DRAM, for example. If stored off- chip, the GPT 56 may be integrity-protected by an on-chip memory protection engine that may use encryption, integrity and freshness mechanisms to maintain security of the GPT 56.

[0123] Locating the GMPU 21 on the requester-side of the system (e.g. on the MMU output) rather than on the completer-side allows allocating access permissions in page granularity while permitting the interconnect 9 to continue hashing / striping the page across multiple DRAM ports.

[0124] Transactions remain tagged with the PAS TAG as they propagate throughout the system fabric 24, 9 until reaching a location defined as the Point of Physical Aliasing 60. This allows to locate the filter on the Master-side without diminishing the security guarantees comparing to Slave-side filtering. As the transaction propagates throughout the system, the PAS TAG can be used as an in-depth security mechanism for address isolation: e.g. caches can add the PAS TAG to the address tag in the cache, preventing accesses made to the same PA using the wrong PAS TAG from hitting in the cache and therefore improving side-channel resistance. The PAS TAG can also be used as context selector for a Protection Engine attached to the memory controller that encrypts data before it is written to external DRAM.

[0125] The Point of Physical Aliasing (PoPA) is a location in the system where the PAS TAG is stripped and the address changes back from a Logical Physical Address to a System Physical Address. The PoPA can be located below the caches, at the completer-side of the system where access to the physical DRAM is made (using encryption context resolved through the PAS TAG). Alternatively, it may be located above the caches to simplify system implementation at the cost of reduced security.

[0126] Figure 6 illustrates the concept of aliasing of the respective physical address spaces onto physical memory provided in hardware. As described earlier, each of the domains 82, 84, 86, 88 has its own respective physical address space 61. At the point when a physical address is generated by address translation circuitry 17, the physical address has a value within a certain numeric range 62 supported by the system, which is the same regardless of which physical address space is selected. However, in addition to the generation of the physical address, the address translation circuitry 17 may also select a particular physical address space (PAS) based on the current domain 13 and / or information in the page table entry used to derive the physical address. Alternatively, instead of the address translation circuitry 17 performing the selection of the PAS, the address translation circuitry (e.g. MMU) could output the physical address and the information derived from the page table entry (PTE) which is used for selection of the PAS, and then this information could be used by the PAS filter or GMPLI 20 to select the PAS.

[0127] The selection of PAS for a given memory access request may be restricted depending on the current domain in which the processing circuitry 10 is operating when issuing the memory access request, according to rules defined in the following table:

[0128] For those domains for which there are multiple physical address spaces available for selection, the information from the accessed page table entry used to provide the physical address is used to select between the available PAS options. For the entries in the table marked * regarding access to the Non-Secure PAS, whether the Secure and Realm domains are able to access the Non-Secure PAS also depends on whether the predetermined less-secure memory property defined earlier has been specified in the granule protection information (GPI) for the PA being accessed (at least in some modes of operation - it is possible to provide a mode where use of this property is disabled for backwards compatibility reasons).

[0129] Hence, at the point when the PAS filter 21 outputs a memory access request to the system fabric 24, 9 (assuming it passed any filtering checks), the memory access request is associated with a physical address (PA) and a selected physical address space (PAS).

[0130] From the point of view of memory system components (such as caches, interconnects, snoop filters etc.) which operate before the point of physical aliasing (PoPA) 60, the respective physical address spaces 61 are viewed as entirely separate ranges of addresses which correspond to different system locations within memory. This means that, from the point of view of the pre-PoPA memory system components, the range of addresses identified by the memory access request is actually four times the size of the range 62 which could be output in the address translation, as effectively the PAS identifier is treated as additional address bits alongside the physical address itself, so that depending on which PAS is selected the same physical address PAx can be mapped to a number of aliasing physical addresses 63 in the distinct physical address spaces 61. These aliasing physical addresses 63, all actually correspond to the same memory system location implemented in physical hardware, but the pre-PoPA memory system components treat aliasing addresses 63 as separate addresses. Hence, if there are any pre- PoPA caches or snoop filters allocating entries for such addresses, the aliasing addresses 63 would be mapped into different entries with separate cache hit / miss decisions and separate coherency management. This reduces likelihood or effectiveness of attackers using cache or coherency side channels as a mechanism to probe the operation of other domains.

[0131] The system may include more than one PoPA 60 (e.g. memory access requests specifying different physical addresses may be routed via different paths through the memory system and may be handled by different PoPAs 60). At each PoPA 60, the aliasing physical addresses are collapsed into a single de-aliased address 65 in the system physical address space 64. The dealiased address 65 is provided downstream to any post-PoPA components, so that the system physical address space 64 which actually identifies memory system locations is once more of the same size as the range of physical addresses that could be output in the address translation performed on the requester side. For example, at the PoPA 60 the PAS identifier may be stripped out from the addresses, and for the downstream components the addresses may simply be identified using the physical address value, without specifying the PAS. Alternatively, for some cases where some completer-side filtering of memory access request is desired, the PAS identifier could still be provided downstream of the PoPA 60, but may not be interpreted as part of the address so that the same physical addresses appearing in different physical address spaces 60 would be interpreted downstream of the PoPA as referring to the same memory system location, but the supplied PAS identifier can still be used for performing any completer-side security checks.

[0132] Figure 7 illustrates how the system physical address space 64 can be divided, using the granule protection table 56, into chunks allocated for access within a particular architectural physical address space 61. The granule protection table (GPT) 56 defines which portions of the system physical address space 65 are allowed to be accessed from each architectural physical address space 61. For example the GPT 56 may comprise a number of entries each defining granule protection information (GPI) corresponding to a granule of physical addresses of a certain size (e.g. a 4K page). The GPI may assign a particular PAS for that granule, or may indicate that more than one PAS can be used to access the granule. If a particular granule or set of granules of physical memory address space is defined in the GPT as being accessible from only one PAS, then it can only be accessed within that PAS and cannot be accessed within the PASs of the other domains. Hence, the sharing of data across domains (to the extent permitted by the accessibility / inaccessibility rules defined in the table described earlier) may be controlled at the point of selecting the PAS for a given memory access request. Figure 8 is a flow diagram showing a method of selecting the PAS based on the current domain and the information from the page table entry used in generating the physical address for a given memory access request. The PAS selection could be performed by the address translation circuitry 17, or if the address translation circuitry forwards the PAS selection information 126 to the PAS filter 21 , performed by a combination of address translation circuitry 17 and the PAS filter 21.

[0133] At step 130 in Figure 8, the processing circuitry issues a memory access request specifying a given virtual address (VA) as a target VA. At step 132 the address translation circuitry 17 looks up any page table entries (or cached information derived from such page table entries) in its TLB. If any required page table information is not available, address translation circuitry 17 initiates a page table walk to memory to fetch the required PTEs (potentially requiring a series of memory accesses to step through respective levels of the page table structure and / or multiple stages of address translation for obtaining mappings from a VA to an intermediate address (I PA) and then from an I PA to a PA). Once the relevant page table information has been identified, the virtual address is translated into a physical address (possibly in two stages via an IPA). At step 134 the address translation circuitry 17 or the PAS filter 21 determines which domain is the current domain.

[0134] If the current domain is the non-secure domain then at step 136 the output PAS selected for this memory access request is the non-secure PAS.

[0135] If the current domain is the secure domain, then at step 138 the output PAS is selected based on the PAS selection information 126 which was included in the block / page descriptor PTE which provided the physical address, where the output PAS will be selected as either secure PAS or non-secure PAS.

[0136] If the current domain is the realm domain, then at step 140 the output PAS is selected based on the PAS selection information 126 included in the block / page descriptor PTE from which the physical address was derived, and in this case the output PAS is selected as either the realm PAS or the non-secure PAS.

[0137] If at step 134 the current domain is determined to be the root domain, then at step 142 the output PAS is selected based on the PAS selection information 126 in the root block / page descriptor PTE 114 from which the physical address was derived. In this case the output PAS is selected as any of the physical address spaces associated with the root, realm, secure and non- secure domains.

[0138] Figure 9 is a flow diagram illustrating a method for the PAS filter 21 (checking circuitry) to perform a protection check. At step 400, the PAS filter 20 obtains protection information, GPT[PA], corresponding to the target physical address (PA) obtained for the memory access request by the address translation circuitry 17. For example, the PAS filter 21 looks up the target PA in the granule protection information cache 22, and if there is a hit for the target PA, determines the protection information associated with the target PA based on cached information specified in a hit entry of the granule protection information cache 22. If the target PA misses in the granule protection information cache 22, then at least one memory access request is sent to the memory system to request that the granule protection entry corresponding to the target PA is returned from memory.

[0139] For example, the PAS filter 21 may have a register storing a base address of the granule protection table used to define the granule protection information, and may generate the address(es) of the memory access request(s) issued to request the relevant granule protection entry as a function of the base address and the target PA. The right to update the register storing the GPT base address may be restricted to software executing in the root domain (at exception level EL3).

[0140] Although some implementations may use a linear table structure which can access the required granule protection entry in a single access, other approaches may use a hierarchical table structure similar to multi-level page tables used by the address translation circuitry 16 for accessing address translation mappings, so that it may be required to issue more than one memory access request to step through multiple levels of granule protection table, with each level of granule protection table being indexed based on a respective portion of the target PA, and a pointer provided in an entry in one level of granule protection table providing a base address which can be used to derive the address at which the next level granule protection table is to be accessed. Once the relevant granule protection entry corresponding to the target PA of the original memory access has been returned from memory, information derived from this granule protection entry may be cached in the granule protection information cache (it is not necessary for the cached information to be encoded in exactly the same way as the granule protection entry stored in memory - e.g. a compression scheme could be used to reduce the volume of cached data compared to the encoding stored in memory).

[0141] Hence, at step 400 information allowing the PAS filter 21 to determine the encoding of the granule protection information corresponding to the target PA is identified by the PAS filter 21. This could be identified either based on cached information in cache 22, or based on information stored in memory.

[0142] At step 402 the PAS filter 21 determines, based on the information identifying the granule protection information corresponding to the target PA, whether the memory access request is permitted. If the memory access request is not permitted, at step 404 the memory access request is rejected, and a fault is signalled. If the memory access request is determined to be permitted, then at step 406 the memory access request is permitted to proceed.

[0143] Therefore, by controlling which PAS an access request can be issued in based on a domain of processing, and by controlling which PASs can access a given physical address, then access to regions of physical addresses can be controlled by the hardware of the data processing system outside of the control of potentially compromised hypervisors and operating systems. The data producer device and data consumer device may provide regions of memory isolated from other software executing on the device by allocating realms. Figures 10 and 11 provide examples of the use of realms in a data processing system according to the present technique.

[0144] Figure 10 illustrates realms which may be initiated by a data consumer device 2. A data processing realm 1000 may be provided to process the remotely generated data received from a plurality of data producer devices 4. The data processing realm 1000 may have access to a region of memory assigned to the realm PAS in the GPT, so that it is isolated from secure and nonsecure processes. The data processing realm 1000 does not necessarily have access to the whole of the realm PAS, as the RMM may isolate the realm PAS into regions accessible by different realms, thereby protecting realms from each other.

[0145] The data consumer device 2 may also provide a policy enforcement realm 1002. Figure 10 illustrates the policy enforcement realm 1002 as surrounding the data processing realm 1000, because the policy enforcement realm may be responsible for controlling the entry of data into and the exit of data out of the data processing realm 1000, as discussed earlier. In some examples, the policy enforcement realm 1002 may be provided as part of the data processing realm 1000, and not as a separate realm.

[0146] Figure 11 illustrates a data generating realm 1004 and a pre-processing realm 1006 which may be provided by a data producer device 4. In the illustrated example, data output from the data generating realm 1004 is provided to the pre-processing realm, which can then carry out pre-processing before the remotely generated data is ready to be transmitted to the data consumer device 2. By performing the data generation and pre-processing in realms, the data consumer device can be guaranteed (via attestation) that the data has been generated and pre- processed in a trusted way, and that the remotely generated data has not been modified maliciously or otherwise.

[0147] Figure 12 schematically illustrates a general purpose computer 1200 of the type that may be used to implement the above described techniques. The general purpose computer 1200 includes a central processing unit 1202, a random access memory 1204, a read only memory 1206, a network interface card 1208, a hard disk drive 1210, a display driver 1212 and monitor 1214 and a user input / output circuit 1216 with a keyboard 1218 and mouse 1220 all connected via a common bus 1222. It will be appreciated that other input / output circuitry 1216 may be provided, such as a touchscreen (e.g., in implementations where the general purpose computer is a mobile device). In operation the central processing unit 1202 will execute computer program instructions that may be stored in one or more of the random access memory 1204, the read only memory 1206 and the hard disk drive 1210 or dynamically downloaded via the network interface card 1208. The results of the processing performed may be displayed to a user via the display driver 1212 and the monitor 1214. User inputs for controlling the operation of the general purpose computer 1200 may be received via the user input output circuit 1216. It will be appreciated that the computer program could be written in a variety of different computer languages. The computer program may be stored and distributed on a recording medium or dynamically downloaded to the general purpose computer 1200. When operating under control of an appropriate computer program, the general purpose computer 1200 can perform the above described techniques and can be considered to form an apparatus for performing the above described technique. The architecture of the general purpose computer 1200 could vary considerably and Figure 12 is only one example.

[0148] Alternatively, the above-described techniques may be implemented in a more distributed fashion, wherein the general purpose computer 1200 illustrated in Figure 12 may be expanded and / or replaced by an infrastructure comprising components implemented on separate physical devices, the separate physical devices sharing the processing required to carry out these techniques. Such separate physical devices may be physically proximate to one another, or may even be located at entirely different physical locations. In some configurations such an infrastructure is termed a 'cloud computing' arrangement.

[0149] In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

[0150] In the present application, lists of features preceded with the phrase “at least one of’ mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination.

[0151] Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

CLAIMS1 . A data consumer device, comprising: data producer identification circuitry to identify a plurality of data producer devices from which to receive remotely generated data over a network; processing circuitry to provide a data processing environment in which to process the remotely generated data received from the plurality of data producer devices; measurement circuitry to take a measurement of the data processing environment in which the remotely generated data is to be processed; and attestation circuitry to provide to the plurality of data producer devices an attestation report based on the measurement of the data processing environment, wherein for each data producer device of the plurality of data producer devices the attestation report is provided to the data producer device in advance of receiving the remotely generated data from said data producer device; wherein the attestation report is to provide the plurality of data producer devices with a guarantee that the data consumer device will process the remotely generated data in a predetermined manner.

2. The data consumer device according to claim 1 , wherein the measurement circuitry is configured to take the measurement in advance of data from any of the plurality of data producer devices entering the data processing environment.

3. The data consumer device according to claim 2, wherein the data consumer device is configured to prevent data received from the plurality of data producer devices from entering the data processing environment until an attestation process has been completed for a set of data producer devices.

4. The data consumer device according to any preceding claim, wherein the attestation circuitry is configured to include timestamp information in the attestation report indicating a time at which the attestation report was generated.

5. The data consumer device according to any preceding claim, wherein the measurement of the data processing environment comprises a measurement of which software can be executed in the data processing environment.

6. The data consumer device according to any preceding claim, wherein the measurement of the data processing environment comprises a measurement of an address space accessible to software executing in the data processing environment.

7. The data consumer device according to any preceding claim, wherein the processing circuitry is configured to receive a producer attestation report from a given data producer device of the plurality of data producer devices based on a measurement by the given data producer device of a data generating environment for the generation of the remotely generated data; and the processing circuitry is configured to determine whether to permit processing, in the data processing environment, of the remotely generated data generated by the given data producer device in dependence on whether the producer attestation report meets a set of producer device criteria enforced by the data consumer device.

8. The data consumer device according to any preceding claim, wherein the processing circuitry is configured to receive policy code from one or more of the plurality of data producer devices; and the processing circuitry is configured to initiate a policy enforcement processing environment to execute the policy code to enforce policies regarding use of the remotely generated data.

9. The data consumer device according to claim 8, wherein the processing circuitry is configured to receive policy code from two or more of the plurality of data producer devices, and the processing circuitry is configured to initiate the policy enforcement processing environment to execute aggregate policy code to enforce a combination of policies of the two or more data producer devices.

10. The data consumer device according to any of claims 8 and 9, wherein the processing circuitry is configured to control at least one of input of data into the data processing environment and output of data from the data processing environment based on the policies enforced by the policy enforcement processing environment.

11. The data consumer device according to any preceding claim, wherein the processing circuitry comprises realm management circuitry to enforce isolation between regions of memory accessible by a plurality of realms; wherein the data processing environment is a realm.

12. The data consumer device according to any preceding claim, wherein the attestation circuitry is configured to include in the attestation report a public key to enable the plurality of data producer devices to encrypt the remotely generated data; and the processing circuitry has access to a private key corresponding to the public key, for decrypting the remotely generated data received from the plurality of data producer devices.

13. A data processing system, comprising: the data consumer device according to any preceding claim; and the plurality of data producer devices, wherein the plurality of data producer devices comprise data generating circuitry to generate the remotely generated data; wherein a given data producer device is configured to determine whether to send remotely generated data generated by the given data producer device to the data consumer device in dependence on whether the attestation report indicates that the data processing environment meets a set of consumer device criteria enforced by the given data producer device.

14. The data processing system according to claim 13, comprising a trusted verifying entity trusted by the plurality of data producer devices; wherein the trusted verifying entity is configured to provide an indication to the plurality of data producer devices of whether the attestation report generated by the attestation circuitry satisfies a set of verification criteria.

15. The data processing system according to claim 14, wherein the attestation circuitry is configured to include in the attestation report a hardware measurement indicating a hardware property of the processing circuitry; and the verification criteria include a hardware measurement criterion indicating an expected value of the hardware measurement.

16. The data processing system according to any of claims 13 to 15, wherein the data consumer device is configured to send pre-processing code to a given data producer device; and the given data producer device is configured to initiate a pre-processing environment to execute the pre-processing code to perform a pre-processing operation on the remotely generated data in advance of said data being sent to the data consumer device.

17. The data processing system according to any of claims 13 to 16, wherein a given data producer device comprises at least one sensor to provide sensor data indicative of a physical environment of said given data producer device, and the data generating circuitry is configured to generate the remotely generated data in dependence on the sensor data.

18. A data producer device for use with the system of any of claims 13 to 17, comprising data generating circuitry to generate the remotely generated data; wherein the data producer device is configured to determine whether to send remotely generated data to the data consumer device in dependence on whether the attestation reportindicates that the data processing environment meets a set of consumer device criteria enforced by the data producer device.

19. A method of data processing, comprising: identifying a plurality of data producer devices from which to receive remotely generated data over a network; providing a data processing environment in which to process the remotely generated data received from the plurality of data producer devices; measuring the data processing environment in which the remotely generated data is to be processed; and providing to the plurality of data producer devices an attestation report based on the measurement of the data processing environment, wherein for each data producer device of the plurality of data producer devices the attestation report is provided to the data producer device in advance of receiving the remotely generated data from said data producer device; wherein the attestation report is to provide the plurality of data producer devices with a guarantee that the data consumer device will process the remotely generated data in a predetermined manner.

20. A computer program comprising program instructions which, when executed on a computer, are arranged to cause the computer to implement the method of claim 19.

Images