Verification of processing

Abstract

A data processing apparatus is provided, comprising an input policy filter that receives input data and an input origin regarding the input data. The filter forwards some or all of the input data and the input origin according to at least one input policy. A processing environment receives the input data forwarded by the input policy filter and processes the input data to generate output data. A management environment generates an authentication of the processing environment and generates an output origin based on the input origin and the authentication. An output policy filter receives output data and the output origin and forwards the output data and the output origin according to at least one output policy.

Description

Technical Field

[0001] This technology involves data processing. Background Art

[0002] In some systems, several pre-designed modules are interconnected to create a larger system. However, in such a system, it may be desirable to control the flow of data between the modules. For example, it may be desirable to control the nature and manner in which data is received and what happens to the data once it has been processed in order to provide security and privacy. Summary of the invention

[0003] From the first example configuration, a data processing device is provided, including: an input policy filter for receiving input data and input origin about the input data, and forwarding some or all of the input data and the input origin according to at least one input policy; a processing environment for receiving the input data forwarded by the input policy filter and processing the input data to generate output data; a management environment for generating an authentication of the processing environment and generating an output origin based on the input origin and the authentication; and an output policy filter for receiving output data and the output origin and forwarding the output data and the output origin according to at least one output policy.

[0004] From the second example configuration, a method of data processing is provided, including: receiving input data and input origin regarding the input data; forwarding some or all of the input data and the input origin according to at least one input policy at an input policy filter; receiving input data forwarded by the input policy filter; processing the input data to generate output data; generating an authentication of a processing environment; generating an output origin based on the input origin and the authentication; and receiving output data and the output origin and forwarding the output data and the output origin according to at least one output policy.

[0005] From the third example configuration, a data processing device is provided, including: a device for receiving input data and an input origin regarding the input data; a device for forwarding some or all of the input data and the input origin according to at least one input policy; a device for receiving input data forwarded by the device for forwarding; a device for processing the input data to generate output data; a device for generating an authentication of a processing environment; a device for generating an output origin based on the input origin and the authentication; and a device for receiving output data and the output origin and forwarding the output data and the output origin according to at least one output policy. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The present technology will be further described, by way of example only, with reference to embodiments of the present technology illustrated in the accompanying drawings, in which:

[0007] Before discussing the embodiments with reference to the accompanying drawings, the following description of the embodiments and associated advantages is provided.

[0008] Figure 1 illustrates an apparatus according to some embodiments;

[0009] Figure 2 illustrates examples of how data flows and origin flows propagate according to several embodiments;

[0010] Figure 3A illustrates how output origins can be generated via concatenation;

[0011] Figure 3B illustrates how output provenance can be generated via merging;

[0012] Figure 3C illustrates how output origins can be generated via removal;

[0013] Figure 4 A flow chart showing an example of processing operations performed at an input filter is illustrated;

[0014] Figure 5 illustrates a flow chart showing an example of processing operations performed at an output filter;

[0015] Figure 6 illustrates an example of how data access may be "unlocked" by a particular target party in accordance with some embodiments;

[0016] Figure 7 The "unlocking" process is illustrated in the form of a flow chart;

[0017] Figure 8 A flow chart showing an example of applying a processing strategy is illustrated;

[0018] Fig. 9 The arrangement of strategies grouped together is schematically illustrated;

[0019] Fig.10 An embodiment is shown in which a policy has an origin; and

[0020] Fig.11 A flow chart showing an example of data processing is illustrated in accordance with some embodiments. DETAILED DESCRIPTION

[0021] According to an example configuration, a data processing device is provided, comprising: an input policy filter for receiving input data and an input origin associated with the input data, and forwarding some or all of the input data and the input origin according to at least one input policy; a processing environment for receiving the input data forwarded by the input policy filter and processing the input data to generate output data; a management environment for generating an authentication of the processing environment and generating an output origin based on the input origin and the authentication; and an output policy filter for receiving output data and the output origin and forwarding the output data and the output origin according to at least one output policy.

[0022] Data is received by an input policy filter together with origin data about the input data. The input data (and associated input origin data) may be received from another data processing device or may be received from another module (software or hardware) within the same data processing device. In either case, the input policy filter of the data processing device consults the input policy to determine how the input data and / or input origin information should be forwarded. Note that the input policy may specify the situation where all, some or none of the data and / or origin information are forwarded and under what circumstances any such forwarding occurs. The processing environment receives any input data that has been forwarded to it by the input policy filter. The processing environment operates under the supervision of the management environment to generate output data. The processing environment may, for example, take the form of a virtual machine under the supervision of a hypervisor (or even the form of an application running under the supervision of an operating system on a hypervisor). In any case, the processing environment cannot affect the management environment and cannot leak information-it is supervised by the management environment and communicates via the input policy filter and the output policy filter. The management environment generates an authentication about the processing environment. Authentication is a verification or assertion of the following matters: the processing is performed by the processing environment and the processing performed is expected to be performed. This authentication can then be used together with the input provenance to generate the output provenance. Thus, the output data is verified by the output provenance. Both the output data and the output provenance are provided to the output policy filter, which forwards them based on the output policy. As with the input policy, the output provenance can specify that some, none, or all of the data and / or provenance information is forwarded and under what circumstances. In this way, control can be maintained over the data, especially the way it is processed and used.

[0023] According to some embodiments, at least one input policy includes at least one input origin condition; and the input data and the input origin are forwarded according to the at least one input origin condition. By including the origin condition, the input data can be controlled so that only input data that has been processed in a specific way can continue to be processed by the processing environment.

[0024] In some embodiments, the input origin condition is applied to a subset of the inputs of the input policy filter; and in response to the lack of the input origin condition, an error is triggered. There are several ways to select a subset of inputs (each including input data and input origin). In some embodiments, the subset is randomly selected because each input has a 1 in N chance of being selected to test. In other embodiments, every M inputs are checked for the existence of the condition. In any case, when the condition is missing, an error can be triggered. In this way, each input can be effectively "spot checked". This can be suitable for systems where checking the origin of the input is time-consuming or computationally expensive. Instead of checking each single input for whether the input origin is appropriate, this embodiment makes it possible to perform checks on only a small part of the input. There are several different examples about appropriate conditions. One example may be that the input origin does not have the necessary processing chain that may be expected. For example, if the processing environment expects data representing the user's heart rate, then if no evidence of processing by a heart rate monitor is found in the input origin, the input origin may be considered invalid. Similarly, in a safety system where reliability is essential, a condition may be missing if the origin of the input indicates that the heart rate is not from one of a plurality of selected reliable heart rate monitors whose output is deemed sufficiently reliable to perform processing. This allows the processing module to refuse to operate on data deemed potentially unreliable and / or be responsible for such data.

[0025] In some embodiments, the input policy filter is adapted to prohibit the input origin from being passed to the processing environment and to forward the input origin to the management environment. In such embodiments, it is considered undesirable to forward the input origin to the processing environment. This prevents the processing environment from having any relationship with the input origin and in particular prevents the input origin from being detected, which may occur as a precursor to modifying or falsifying the origin. This action may also be used to provide more robust security and privacy. If it is desired to access specific information about the origin by a processing environment further down the chain in the overall system, this information may be provided as part of the input data itself. By providing the data as part of the input origin, it may be assumed that such data is considered privileged and is therefore not intended for consumption by the processing environment itself, but is to be restricted by, for example, the management environment.

[0026] In some embodiments, at least one input policy restricts the forwarding of input data based on the identity of the source of the input data, and at least one output policy restricts the forwarding of output data based on the identity of the target of the output data. In these embodiments, the input policy and / or the output policy prohibits data from flowing from or to an unknown or untrusted environment. In this way, data can be restricted to being provided by a specific other processing environment and can be restricted to being provided to a specific further processing environment. For example, in the case of heart rate data, the output policy can restrict the forwarding of heart rate data to anyone other than a medical professional. Similarly, the input policy can restrict the provision of data from anything other than a heart rate monitor approved by the health service.

[0027] In some embodiments, at least one input policy includes multiple input policies, and the input policy filter applies one of the multiple input policies; and one of the multiple input policies is selected based on the data source of the input data or the type of the input data. In these embodiments, several different input policies are provided. The input policy applied by the input policy filter depends on the data source of the input data. In this way, different restrictions can be provided depending on the input provider. This can be used to allow different processes to be performed on the input depending on the source of the input data. For example, a heart rate monitor registered with a health service can be used to determine whether the user has an abnormal or unhealthy heart rate, while a heart rate monitor that is not registered with the health service can be considered inappropriate (easy to miss danger signals or easy to see danger where there is no danger). However, heart rate monitors registered with and not registered by the health service can be used to provide data to the process for fitness monitoring, where reliability or accuracy may have a lower degree of concern.

[0028] In some embodiments, at least one output policy includes a plurality of output policies; an output policy filter applies one of the plurality of output policies; and one of the plurality of output policies is selected based on a target of the output data or a type of the output data. The output policy may include a plurality of output policies and one of the output policies may be applied based on a target of the output data. Thus, depending on the target of the output data, the data may be limited in different ways. For example, if the target is a medical professional, heart rate data for the last 24 hours may be provided in raw form. In contrast, if the target is a bodybuilding application, it may only be appropriate to provide the latest average heart rate value every 60 seconds.

[0029] In some embodiments, the input data includes data received via multiple data sources; and the input origin includes origin information about each of the multiple data sources. By providing origin information about each of the multiple data sources through which the input data is calculated, a "chain" can be generated from the source of the initial data to the origin of the current processing environment, wherein each point in the chain represents the processing performed on the received data by a different processing environment. This can be used to provide an "audit trail" of the processing that has been performed. This can allow the processing environment to operate only on data that is considered to be credible, reliable, and any necessary processing steps have been performed. One way this can be used is to ensure that anomalies or background noise are removed from the data before the data is processed. In this case, it may not necessarily be required that this is a step immediately before a particular processing environment operates on the data, but it may be necessary that such a step has been performed somewhere in the chain so that such unreliable data has been filtered out.

[0030] In some embodiments, the authentication of the processing environment includes a hash of at least a portion of the processing environment. A hash can be considered as a mathematical operation that converts an input in an input domain into an output in an output domain, wherein the output domain is smaller than the input domain. In this way, an input can be represented by its hash value. The hash value can be secure, so that it is mathematically intractable to find two inputs that produce the same hash value or to provide an input given its corresponding output. Therefore, by providing a hash of the processing environment that produces output data from input data, it may not be possible to immediately determine from the hash what processing has been performed, but it may be possible to verify that the expected processing environment is used in order to produce the output data. If even a small modification is made to the processing environment, this will result in a change in the hash value, which can be detected. In fact, hash functions often have the property that a small change in the input value causes a large change in the hash value. This can therefore provide protection against subtle or slight modifications (possibly due to being hacked) to the processing environment.

[0031] In some embodiments, the authentication of the processing environment includes a hash of the output data. By providing the hash of the output data itself as the authentication of the processing environment, it is possible to verify or confirm that the output data is the result of the processing performed by the processing environment on the input data. In some of these embodiments, the authentication may also include the output data so that the hash can be confirmed, or may include the input data so that the processing performed by the processing environment can be performed again in order to obtain the output data and thereby confirm that the hash value is correct.

[0032] In some embodiments, the input origin is cryptographically signed; and the management environment causes the authentication of the processing environment to be cryptographically signed. Cryptographic signatures make it possible to authenticate the source of some data that can be cryptographically signed. As a result of the input origin being signed, the declared source of the data can be trusted to be accurate. Similarly, as a result of the management environment causing the authentication of the processing environment to be cryptographically signed, other environments may be able to trust the processing environment by virtue of its source. Note that the authentication itself may not be signed directly. In particular, the authentication of the processing environment may be cryptographically signed by virtue of the output origin (generated using the authentication) being signed. The cryptographic signing process may involve one or more certification authorities. Such an authority may be a third-party entity that is not responsible for the processing environment itself, but serves to verify the authenticity of the entity that signed the processing environment. For example, instead of explicitly keeping track of each heart rate monitor that has been registered by the health service, it may be acceptable to trust any heart rate monitor that has been cryptographically signed by an entity authenticated by the health service. In this way, the health service may authenticate one or more third parties to sign the processing environment that generates the heart rate data. These third parties can be trusted by the health service to generate trusted data. In this way, a chain of authentication can be provided. In addition, we can consider a government agency signing the certificate of the National Health Service in order to verify that the National Health Service is recognized by the government. This chain can continue almost without limit. If it is later discovered that the trust provided by the certification body is misplaced, the certification body may also have the ability to revoke the certificate. For example, if a hardware manufacturer certified by the National Health Service is found to produce a heart rate monitor of poor quality, the National Health Service can revoke its certification of the hardware manufacturer by publicly revoking the government-issued certificate that certifies the manufacturer's products. These technologies will be known to those skilled in the art.

[0033] In some embodiments, the processing environment is signed with a cryptographic signature; and the management environment is adapted to check the validity of the cryptographic signature. By signing the processing environment (e.g., software running within or constituting the environment), a certain degree of reliability can be provided that the processing environment is authenticated and / or manufactured by a particular entity. In some cases, the cryptographic signature may utilize a chain of certificates to identify the provider of the processing node. The validity of the cryptographic signature may be checked by confirming that the provider (e.g., the signer of the processing environment) is authenticated to provide the processing environment that performs the specified function.

[0034] In some embodiments, at least one input policy includes at least one of the required input data type, the maximum number of input data, the maximum input data rate, and the maximum input data delay. The policy can therefore limit the output data in several different ways, including the type of data (e.g., floating point, integer, double precision, character, Boolean), the maximum number of input data (e.g., 40 bytes), and the maximum input data rate (3 times per day). This can be used to help ensure that the input data has the expected format, as well as the quality. Other quality of service metrics that can be the subject of filtering will be known to those skilled in the art. Note that type checking can be implemented using regular expressions or language parsers. Types do not need to be limited to conventional types, but can be custom defined types recognized throughout the system. For example, we can define a type "HeartRate" that represents the number of heartbeats per minute and is an unsigned 8-bit integer (thereby representing an integer value of 0-255). The policy can therefore reject the type "unsigned integer", but allow the custom type "HeartRate" generated by the heart rate monitor. The delay can be determined by providing a timestamp during the authentication process performed by the management node.

[0035] In some embodiments, at least one output policy includes at least one of the required output data type, the maximum output data quantity, the maximum output data rate and the maximum output data delay. In a similar manner to the input policy, the output policy may also limit the output data based on the required output data type, the maximum output data quantity and the maximum output data rate. For example, it may be limited to not allow data to be output more than 12 times a day, with at least 55 minutes between each output. By limiting the output in this way, bandwidth may be saved. Similarly, other quality of service metrics that may be the subject of filtering will be known to those skilled in the art. Note that type checking may be implemented using regular expressions or language parsers. Similar to the above, types do not need to be limited to conventional types, but may be custom defined types that are recognized in the entire system. Delay may be determined by providing a timestamp during the authentication process performed by the management node.

[0036] In some embodiments, at least one output policy includes a requirement that a type of output data matches a type of input data.

[0037] In some embodiments, the output filter is suitable for performing a conversion from the type of the output data to the type of the input data in response to the type of the output data being different from the type of the input data. For example, this may involve the conversion of integer 16 to floating point number 16.0. In addition, this may occur via the aggregation or separation of data. For example, if only an array of 16 integers can be output according to the output strategy, the output filter may include a buffer to store the other 15 nearest integers that have been presented. When the 16th integer is presented, this may be packaged with the other 15 nearest integers to form an array of 16 integers that can be output by the output filter. Similarly, if an array of 16 integers is received, but only a single scalar integer is permitted, the output filter may buffer the array of 16 integers received and output these as scalar integers over a period of time. Those skilled in the art will appreciate that in some embodiments, similar conversions may occur at the input filter.

[0038] There are several different ways in which an output provenance can be generated. However, in some embodiments, the management environment is adapted to generate an output provenance by concatenating an authentication with an input provenance. The concatenation of an authentication with an input provenance enables the output provenance to be reviewed and the authentication of any particular processing environment in the chain to be accessed. This can then be used to verify the authentication at one or more different stages. For example, if the authentication takes the form of a hash of the executable code and its local data and configuration, the authentication can be compared to a known value. Similarly, if the authentication takes the form of a hash of the result of executing the code, then if the input value for a given authentication is known (for example, if this also forms part of the authentication), this can be hashed in order to verify whether the hash matches (thereby indicating that the authentication is valid).

[0039] In other embodiments, the management environment is adapted to generate the output provenance by merging the authentication with the input provenance. The merging of the authentication with the input provenance means that it may not be possible to separate the authentication and the input provenance. Therefore, while the result may be considered fixed, such that all previous steps of the chain may be trusted, it may not be possible to access information about a particular part of the chain at a later time. However, by merging the authentication with the input provenance, the entire chain does not need to be stored and therefore the size of the output provenance can be reduced without sacrificing the integrity of the chain itself.

[0040] In some other embodiments, in response to the input provenance satisfying the condition, the management environment is adapted to generate the output provenance through output authentication.

[0041] There are several examples of what such a condition may be. However, in some embodiments, the condition includes a requirement for the input provenance to be verified. In particular, if the input provenance is verified, then it may be considered acceptable to lose the input provenance, but only provide authentication, especially if the data processing device is trustworthy. In such an embodiment, the lost input provenance may be stored locally at the data processing device for later retrieval if necessary. By not including the input provenance in the output provenance, the size of the output provenance may be reduced compared to the case where the input provenance is included.

[0042] In some embodiments, the processing environment is adapted to process input data or output data to generate further output data; and the output policy is adapted to permit the forwarding of further output data in dependence on the output data. In some cases, the input data itself may be processed in a variety of ways. Thus, the input data may be processed in a first way to generate output data and in a second way to generate further output data. Where this occurs, there may be some embodiments in which the output policy permits the output data to be forwarded, and the further output data to be forwarded, depending on the output data itself.

[0043] For example, in some embodiments, the output policy is adapted to permit the forwarding of further output data contingent upon the output data having a given characteristic. Thus, when the data itself has a particular given characteristic, further output data may be "unlocked" so that it may be forwarded (subject to the conditions of the output policy). For example, in the case of a heart rate sensor, if the output data indicates that the user is at risk of a heart attack, further output data providing more specific information that would otherwise not be desired to be output gratuitously may be provided gratuitously so that the user can have the opportunity to be provided assistance.

[0044] In some embodiments, the management environment is provided by a hypervisor; and the processing environment is a virtual machine managed by the hypervisor. There are several different ways to implement the management environment and the processing environment. However, in some cases, the management environment is provided by the hypervisor. The hypervisor can manage several different virtual machines, one of which can be a processing environment. It will be understood that in such embodiments, several different processing environments can be provided, each of which is isolated by being a different machine under the supervision of the same hypervisor. In this way, the same management environment can manage several different processing environments, each of which is linked to each other by input policies and output policies. The management environment itself can also be a virtual machine operating under the hypervisor. In either case, each processing environment is isolated by being a virtual machine and is also isolated from the management environment by being a virtual machine operating under the hypervisor.

[0045] In some embodiments, the management environment is adapted to control the behavior of the processing environment to operate in accordance with at least one processing policy.

[0046] In some embodiments, at least one processing policy includes a state reset condition; and in response to satisfying the state reset condition, the management environment causes a processing state of the processing environment to be reset. By resetting the state of the processing environment, it becomes difficult for the processing environment to move data from one input to another. This thereby reduces the chance of the processing environment leaking data.

[0047] In some embodiments, at least one processing strategy includes a recording condition; and in response to the recording condition being met, the management environment causes the processing state to perform recording. The recording condition may, for example, be that X out of every Y data inputs are recorded, or may indicate a random probability that a given input is recorded. The condition may also indicate the extent to which recording occurs (e.g., a recording level). In some embodiments, the recorded data is locally encrypted and, in response to further conditions, transmitted to a data repository.

[0048] In some embodiments, at least one processing strategy includes one or more error response rules; and in response to an error condition occurring in the processing environment, the management environment causes the error condition to be handled according to the one or more error response rules. An error may, for example, be an attempted policy violation (e.g., an input origin is invalid, or an input filter rejects input data due to its type). One or more data response rules may indicate on an error-by-error basis how error response occurs. For example, certain errors may be notified in one manner, while other errors may be notified in another manner. In some embodiments, an error response routine is provided so that when any error occurs, it is passed to the error response routine that determines how notification should occur based on the error type and other circumstances.

[0049] In some embodiments, certification is provided for at least one of at least one input policy and at least one output policy. Thus, a set of policies may be enforced, for example, by a national health service, which may provide a set of policies regarding the type of data that should be used for a heart rate monitor. These may, for example, require a particular resolution and / or quality of the data.

[0050] In some embodiments, at least one of the at least one input policy and the at least one output policy includes a base policy and other policies; and the other policies are at least as restrictive as the base policy. This can be used to form, for example, a "graph" (e.g., a "tree") of policies. By providing other policies that are more restrictive than the base policy, the obligations of a given policy may not simply be met (e.g., as may be required by a national health service), but may also exceed those obligations - for example by requiring even higher resolution heart rate data than is required according to the standards of the national health service.

[0051] Certain embodiments will now be described with reference to the accompanying drawings.

[0052] Figure 1 The apparatus 100 according to some embodiments is illustrated. The apparatus 100 includes an input filter 110 (an example of an input policy filter) that receives input data and input origin from one or more input sources 120A, 120B. The input filter 110 forwards the input data and input origin according to one or more input policy actions and based on these input policies. In this example, the input data is forwarded to the processing node VM 130 (which is an example of a processing environment) and the input origin is passed to the security framework hypervisor 160 (which is an example of a management environment). Note that this forwarding can occur based on satisfying one or more requirements as specified by one or more input policies. The processing node VM 130 performs one or more processing operations on the input data to generate output data provided to the output filter 140. The security framework hypervisor performs authentication on the processing node VM 130. This is used in conjunction with the input origin to generate the output origin provided to the output filter 140. The output filter 140 then provides the output data and the output origin to one or more targets 150A, 150B. As with the input filter, the forwarding generated by the output filter 140 is based on one or more output policies. Therefore, the forwarding and the direction of forwarding can be influenced by the output policy.

[0053] Figure 2 200 and an example of how a data stream 200 and a source stream 210 propagate according to several embodiments. In this example, a sensor 240 is the ultimate source of data (e.g., heart rate data). This data is provided to a first node 220a, which may be connected to a reference Figure 1 The device 100 shown in the figure operates in a similar manner. This node 220a includes a first function F A Processing environment 230a. A The result is then passed to perform the second processing operation F B The result of this operation is then passed to a third processing environment 230c, which is part of the third node 220c. This third processing environment 230c performs a third processing operation F C Finally, the result of this operation is passed to the fourth processing environment 230d, which is part of the fourth node 220d and performs the fourth processing operation F D Thus, data flow 200 is illustrated by data passing through four processing environments 230a, 230b, 230c, 230d, each of which is provided in a separate node 220a, 220b, 220c, 220d. The input and output of each node 220a are filtered according to input filters 270 that implement the input policy and output filters 280 that implement the output policy, as previously described in Figure 1. In this way, the data received by each node 220 can be limited according to the policy and forwarded when necessary. Note that there is no output filter on the final node 220d. In this example, no data is output by the final node 220d and therefore no output filter is required. Similarly, no input filter is associated with the first node 220a because the first node 220a does not necessarily receive any input (the sensor can be considered as part of the first node 220a).

[0054] In addition to the data flow 200 described above, the origin flow 210 also occurs. Each node 220 includes a management environment 160, which is responsible for generating authentication and origin. In particular, the management environment 150 of the first node 220a performs authentication 260a to the first processing environment 230a. In the absence of any input origin, this authentication 260a becomes an output origin, which is passed to the second node 220b via the output filter 280a of the first node 220a and the input filter 270b of the second node 220b. Authentication is generated by performing hashing on the first processing environment 230a. The result of this hash is then cryptographically signed. In this example, hashing 260a is generated by performing hashing on the executable code executed by the first processing environment 230a. This becomes a part of the origin and can be checked at other nodes 220b, 220c, 220d to ensure that hashing corresponds to the predetermined hash of the first processing environment 230a. This will help determine whether the processing environment itself 230a has been modified to perform a different function and also confirm the processing operation F A The cryptographic signature can be used to determine that node 220a performed the hash itself. This helps prevent a situation where a different node can perform a different hash by surreptitiously executing the same A Different processing operations and hash (F A ) in the form of an attempt to impersonate the first processing node 220a. Since such a node will not be able to access the relevant certificates / keys in order to perform cryptographic signatures, the hash will remain unsigned. Therefore, other nodes will be able to determine that the hash value is not generated by the first processing node 220a. This technology can also be used to determine whether a particular node has been authorized or authenticated by an external agency. For example, the first processing node 220a can be authorized by a central organization such as the National Health Service. In any case, once the output origin 250a has been generated, it is provided to the second node 220b as part of the output. This origin is then extracted at the input filter 270b.

[0055] When received by the input filter 270b of the second node 220b, the output origin of the first node 220a (now the input origin of the second node 220b) is forwarded to the management environment 160 of the second node 220. Here, the input origin is combined with the authentication of the second processing environment 230b. In this example, the combination is realized via serial connection. Therefore, the output origin of the second node 220b includes the cryptographically signed hash of the first processing environment 230a, followed by the cryptographically signed hash of the second processing environment 230b. This is then output to the output filter 280b of the second node 220b. This output origin is then output and received by the input filter 270c of the third node 220c. This is extracted again and combined with the authentication of the third processing environment 230c. The output origin 250c of the third node 220c is therefore composed of three serially connected cryptographic signature hashes. Again, this is output by the output filter 280c of the third node 220c and received by the input filter 270d of the fourth node 220d. Here, the authentication of the fourth processing environment 230d (again generated as a hash of the fourth processing environment 230d) is concatenated with the output provenance from the third node 220c and thus the output provenance generated by the fourth node 220d is composed of the four concatenated cryptographically signed hashes of each of the four processing environments 230a, 230b, 230c, 230d. Each of the hashes has been generated by the management environment 160 of the corresponding node 220a, 220b, 220c, 220d. Therefore, by analyzing the output provenance generated at the fourth node 220d, the four processing operations F can be verified. A 、F B 、F C 、F D Each of has been executed. In addition, in the case where each authentication has been cryptographically signed, it can be verified that each processing operation has been performed by an authorized device.

[0056] exist Figure 2 In the examples, the output provenance is in each case produced by concatenating the input provenance with the authentication produced by the node. Figure 3A As shown in , the input provenance plus the local node's authentication are concatenated to produce an output provenance, where the input provenance is followed by the authentication. However, there are other ways in which the input provenance and authentication can each be used to produce an output provenance.

[0057] In addition, Figure 2 In FIG. 2 , it will be noted that the third processing environment 230 c has been cryptographically signed. This enables the management environment to confirm that, for example, an externally provided processing environment (e.g., software provided by a third party) is legitimate and enables the management environment to have confidence in the quality of the processing performed by the processing environment 230 c.

[0058] Alternatively, or in addition to creating the certificate by hashing the processing environment itself, the certificate may include a hash of the output data (and possibly the input data and / or the output data) produced by the processing environment. Figure 2 In the example of FIG. 1 , authentication of the first processing environment 230a may include performing F A The hash of the result - that is, hash(F A This may also include the input data itself, or the generated output data itself. A (input). Any of these can also be combined with a hash of the processing environment itself (e.g. hash(F A )) (or a hash of the processing environment itself is provided instead). In any case, authentication is performed on the processing environment. A instructions.

[0059] exist Figure 3B In the example, the input provenance and the authentication are merged together to produce the output provenance. For example, the input provenance may be XORed with the authentication to produce a combined data segment. As a result of the two inputs being merged together, it is expected that the output provenance will not be greater than the largest of the input provenance and the authentication. Therefore, the output provenance does not need to grow at each stage. In addition, although such merging may lose the ability to individually verify the authentication of a single processing environment, it may be possible to verify a chain of processes if the same merge operation is used. For example, take Figure 2 , although it may not be possible to determine the processing environment F solely from the origin of the output generated at the fourth node 220d c is correct, but it is still generally possible to verify that operation F A 、F B 、F C 、F D The entire chain of is correct and has been executed. In other words, it may not be possible to determine from this output origin which of the four processing operations was not executed correctly, but it can still be determined that one or more of them were not executed correctly. In this example, an XOR operation is used. This is both because XOR is simple to implement in hardware and because the XOR operation maintains entropy, unlike many other Boolean operations. Other suitable forms of merging will be known to those skilled in the art. Note that in some embodiments, certificates can still be concatenated. This makes it possible to confirm authenticity at any stage.

[0060] Figure 3C A third example is illustrated where the input origin and authentication are combined with a condition for the input origin to be considered valid. Here, after having been verified, the input origin is discarded so that the output origin is the authentication itself. Figure 3BAs in the example shown in , this can result in an output provenance that does not necessarily grow at each stage. This is because the size of the output provenance is roughly the same as the attestation itself (the difference may be due to, for example, overhead or headers). However, this again removes the ability of later nodes to confirm the attestation of some earlier node. In particular, in this example, while a node can confirm the provenance of its predecessor, the node cannot check the provenance of any earlier node. In fact, each node relies on its predecessor in order to confirm that the provenance is valid. This requires that the provenance be checked at each stage. However, since it does not involve any concatenation or merging, the generation of the output provenance is comparable to the reference Figure 3B and 3A The example shown is faster. In addition, Figure 3A Compared to the example shown in , less data must be transmitted between nodes. Likewise, in some embodiments, the certificate itself can be kept instead of being discarded. In some embodiments, another condition (rather than the input origin being verified) can be used.

[0061] It will be appreciated that the choice of which of these examples is most appropriate will depend on the underlying application and also on the implementation of the system. In a system where each node is tightly controlled and tightly interconnected (e.g., as different virtual machines executing on the same circuit), and especially where each node is produced by the same manufacturer, there may be little need for a particular node to verify processing operations performed by a distant node. Therefore, reference Figure 3C The example shown may be appropriate. In other examples, such as where an audit trail is required (e.g., in a healthcare context where verifiable data is necessary to avoid any problems), reference Figure 3A The example shown may be more appropriate.

[0062] Figure 4A flowchart 400 showing an example of a processing operation performed at the input filter 110 of the node 100 is illustrated. In step 405, an input is received. In step 410, it is determined whether the input origin should be checked. In some embodiments, only the input origin of a subset of the input is checked. For example, the input may be checked randomly or X of every N inputs may be checked. By performing such a "spot check", elements of security and reliability may be maintained without making the expense of processing power necessary by checking the input origin of each single input. Obviously, in the case where reliability or security is considered to be of utmost importance, such a spot check may not be used or a large proportion of the input may be spot checked. Similarly, in the case where such a large degree of security or reliability is not required, or in the case where the manufacturing environment is a situation where security or reliability concerns can be alleviated, spot checks may become more sparse. If in step 410, it is determined that the input origin is to be checked, then in step 415 it is determined whether the input origin is correct. If not, then in step 420, an error is raised. This may take the form of an exception, a warning to the operator, or may result in the system being terminated completely. However, if it is determined at step 415 that the input origin is valid, or if the input origin does not need to be checked at step 410, it is determined at step 425 whether there is an input policy that matches the source or data type of the input. If so, at step 445, the policy that matches the source is selected and the process proceeds to step 450. If not, the default input policy is used at step 430, and it is determined at step 435 whether this source is permitted to provide data. If not, at step 440, the input data is ignored. The process can then return to step 405. If the source is allowed at step 435, the process proceeds to step 450. Here, it is determined according to the selected input policy whether the input requirements (e.g., quality of service metrics) are met according to the selected input policy. Such requirements may involve input data type, quantity, quality, frequency, latency, and other quality of service metrics. If such requirements are met, the input data is processed at step 455. Otherwise, the process proceeds to step 460, where the input data is ignored. In any of these cases, the process can then return to step 405.

[0063] Note that in this embodiment, a validation failure results in the input data being ignored. However, in some embodiments, particularly where one management environment manages several processing environments and input data provided to a previous processing environment is available (e.g., if this was provided as part of the input origin), it may be possible to "rewind." For example, if the data provided to a given input filter is invalid, the data may be returned to the previous processing environment to be reprocessed. If the data originally provided to the previous processing environment is still available, this may be reprocessed by the processing environment. Alternatively, if it is determined that the data provided to the previous processing environment is invalid and a more previous version of the data is available, the more previous version of the data may be provided back to the more previous processing environment for processing, and so on.

[0064] Figure 5 A flowchart 500 is illustrated that gives an example of an output filtering process that may be performed by the output filter 140 of the node 100. The process begins at step 510, where data to be output is received by the output filter. At step 520, it is determined whether there is an output policy that matches the target or output data type. If so, then at step 560, the policy is selected to be used and the process proceeds to step 570. If not, then at step 530, the default output policy is used and the process proceeds to step 540. Here, it is determined whether the target is allowed. In other words, it is determined whether the output target is a target that is permitted to receive output data. If not, then at step 550, the target is ignored and no data is sent. The process may then return to step 510. If the target is allowed, the process moves to step 570, where it is determined whether the output requirements are met. With reference to Figure 4 As with the input filtering process shown, this is determined with reference to the quality of service metric (e.g., whether the data type / size / frequency / latency, etc. is permissible according to the selected policy). If the requirements are met, then at step 580, the output data is sent. Otherwise, at step 590, the target is ignored - or a warning message is issued to a log file or log service. In either case, the process can then return to step 510. It will be appreciated that this process can be repeated for each target for which data is to be sent.

[0065] Figure 6An example of data access that can be "unlocked" by a specific target party according to some embodiments is illustrated. In this example, the device 100 is configured to output data to two different target parties 610a, 610b via the output filter 140. Party 1 610a (e.g., a healthcare professional) is permitted to receive an array of floating point numbers at any time. This information may correspond to raw data that has been received by a sensor such as a heart rate monitor. Party 2 610b (e.g., an insurance company) is typically permitted to receive integers only once a day. This may correspond to the result of performing some processing on the data - such as providing an average heart rate for a day. However, as an exception, the second party 610b is also able to receive an array of floating point numbers when certain conditions are met. For example, if the integer indicates that the user has an average heart rate that is dangerously high, such that a heart attack is imminent or in development, the full range of raw data may be provided to the second party 610b. In some embodiments, the condition may depend on circumstances, such as time or date. However, in other embodiments, the condition depends on data that would otherwise be output to the second party 610b. Thus, in these special or exceptional circumstances (conditions), it is possible for more sensitive or privileged data to be unlocked or accessed by parties who would not normally be able to access it. This may be, for example, to provide assistance or help to the user where appropriate.

[0066] Figure 7This "unlocking" process is illustrated in more detail in the form of a flowchart 700. In step 710, the output data is analyzed to determine its type and to determine other factors that may be required according to the output policy. In step 720, it is determined whether any special conditions are met. If so, then in step 730, any policies that are "locked" for these special conditions are unlocked, thereby allowing these policies to be used. In any case, in step 740, after selecting the most appropriate policy to use, it is determined whether the data type of the output data is allowed. In some embodiments, this can occur by determining whether the type of the input data matches the type of the output data. If not, in step 745, it is determined whether the conversion from the current type of the output data to the allowed type of the output data is permitted according to the output policy, and it is also determined whether such conversion is possible. The rules for reformatting the input or output can be classic type conversions, such as those used in JavaScript, for example, applied to the JSON data exchange format. If such conversion is possible, then in step 747, the conversion occurs and the process proceeds to step 760. Otherwise, in step 750, the target is ignored. If in step 740, the data type is allowed, then in step 760, it is determined whether the amount of data is allowed. If not, then again, the process proceeds to step 750 where the target is ignored. Otherwise, at step 770, it is determined whether the data rate is allowed. If not, then at step 750, the target is ignored. However, if the data rate is allowed, then at step 770 the data is forwarded. At step 780, it is determined whether the data latency is permitted. There are several ways to measure and compare this. For example, the management environment may (as part of the authentication) indicate the time it takes to provide output data after receiving the input data and if there is too large a gap (e.g., if processing takes too long) the output filter may ignore the data. If multiple authentications are accessible in the origin information, this can also be achieved by comparing the processing times from multiple authentications. In some embodiments, the latency may be measured from the time it was originally generated, if such data is maintained in the origin data. In any case, if the data latency requirement is not met, then at step 750 the target is ignored. Otherwise, the process proceeds to step 790 where the data is forwarded. Note that steps 740, 760, 770, and 780 involve quality of service requirements, which may be respectively Figure 4 and Figure 5In step 450, the most appropriate strategy may be checked as part of the input strategy or as part of the output strategy in step 570. In general, the selection of the most appropriate strategy may involve selecting the most permissive strategy applicable to the target (including any that have been unlocked in step 730). In the case where none of the strategies are necessarily more permissive overall, this process may be repeated for each strategy applicable to the output target, or otherwise the related strategies may be compiled together, for example using a Satisfiability Solver (SAT Solver).

[0067] Figure 8 Flowchart 800 showing an example of applying a processing strategy is illustrated. The processing strategy can be applied by the management environment 160 to control the behavior of the processing environment 130 or the entire device. In step 810, it is determined whether the state reset condition has been met. This is a condition: under this condition, the internal state of the processing node will be erased. For example, this can be after each input data has been processed, after each N input data has been processed, or randomly (for example, there is a certain probability when each input data is processed). If this condition is met, then in step 820, the internal state of the processing node is erased. This therefore prevents data from one input from being carried to another input. The state can be erased, for example, by actively erasing the memory assigned to the processing node, or by assigning a new piece of memory to the processing node to erase the state, or by restarting the processing node with a newly allocated and reset memory to erase the state. In any case, in step 830, it is determined whether the operation of the processing node should be recorded. In other words, it is determined whether the recording condition is met. If so, then in step 840, logging is enabled and the contents of the log are encrypted by a public key (e.g., a public key held by the management environment). In step 850, it is determined whether conditions are met so that the log can be forwarded to an external server. If so, then in step 860, the log is forwarded. In any case, the process then proceeds to step 870, where it is determined whether conditions for changes in the error response routine are met. If so, then in step 880, the error responder is changed. Therefore, errors that occur (e.g., attempted policy violations) can be handled in different ways, such as being notified to different entities (e.g., a supervisory environment, rather than a management environment). The process then returns to step 810. This entire process can be performed every period of time. In some embodiments, the process is performed each time data is about to be processed by the processing environment 130.

[0068] Fig. 9An arrangement 900 is illustrated in which a first input filter 910a receives data and forwards it (as appropriate) to a first processing environment 920a. After processing this, the data is then forwarded by a first output filter 930a (as appropriate) to a second input filter 910b for a second processing environment 920b. Here, the data received by the second input filter 910b is processed and passed to the second output filter 930b for further forwarding (again as appropriate). In this embodiment, each of the input policy, output policy, and (if used) processing policy is passed to a management environment 940. Here, the policies are combined and can be output as requested. This can allow, for example, a healthcare policy compliance inspector to verify healthcare regulatory compliance.

[0069] Fig.10 An embodiment in which a policy has an origin is illustrated. For example, an input filter includes a base input policy 1010a, which is associated with a base input policy origin 1030a. Here, the base input policy origin 1030a verifies the base input policy 1010a. For example, it may contain a cryptographic hash of the base input policy 1010a. The hash may also be cryptographically signed to verify that it comes from a specific source. Similarly, an output filter may include a base output policy 1010b, which carries an accompanying base output policy origin 1030b. The origin of the policy may be verified by the management environment 1050. In the event of a verification error, the management environment 1050 may cause the error to be triggered. For example, the entire device may refuse to operate, and / or the error may be indicated to the operator. In some embodiments, if the processing environment 1060 has an associated processing policy that defines an error response routine, such a routine may be called in response to such an error. Such a policy may be provided in the case where the National Health Service stipulates a policy to be applied to a specific system. For example, the National Health Service may require that a certain resolution or quality of data be required when heart rate monitoring is performed in the context of a healthcare system. The provenance of such input policies may then be provided to help verify that the policies that are met are those implemented by the National Health Service.

[0070] In addition, in this example, other input strategies 1020a are shown, together with their associated origin 1040a. In this case, other input strategies 1020a are designed to extend the basic input strategy 1010a. This allows other input strategies 1020a to tighten the requirements provided by the basic input strategy 1010a. Therefore, other input strategies 1020a are not allowed to introduce any requirements that 1010a will not meet. This allows the processing environment to operate according to (in this example) the even more stringent requirements that the National Health Service requires it to comply with. Equally, this compliance can be confirmed by the management environment, such as by using a logic analyzer (such as a SAT solver). As before, if other strategies 1020a include requirements that are not the tightening requirements of the basic strategy 1010a, then an error can be raised. Similar to other input strategies 1020a, other output strategies 1020b that extend the basic output strategy 1010b can be provided. Similarly, in each case, other strategies 1020a, 1020b may each be accompanied by their own provenance information to help confirm the validity of these other strategies. In this way, strategies may be connected in a "graph" (eg, tree) structure.

[0071] Fig.11 A flowchart 1100 showing an example of data processing is illustrated according to some embodiments. In step 1110, input data is received along with an input origin. In step 1120, the input data and the input origin are forwarded according to the input policy selected by the input filter. In step 1130, the processing environment receives the forwarded input data, and in step 1140 the processing environment processes the input data. In step 1150, an authentication is generated. This may occur, for example, via the management environment 160. In step 1160, this authentication is used together with the input origin to generate an output origin. Again, this may be performed by the management environment 160. Finally, in step 1170, the output filter receives the output data (which is generated as a result of processing the input data in step 1140) and the output origin and these are forwarded to one or more targets based on one or more output policies.

[0072] Thus, through the above examples, it can be seen that it is possible to produce a system in which the receipt and transmission of data is accompanied by provenance information that reflects the processing that has been performed on the input data to date. Furthermore, by continuing to provide authentication regarding the processing that continues to be performed on the data, it is possible for later nodes in the chain of processing nodes to have confidence in the required quality of the data being operated on. Furthermore, an audit trail can be provided for security and reliability so that any failures or errors that occur can be traced back to the source of these problems.

[0073] In this application, the word "configured to" is used to mean that elements of a device have a configuration that can perform a defined operation. In this context, "configuration" refers to the arrangement or interconnection of hardware or software. For example, a device may have dedicated hardware that provides a defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that the device elements need to be changed in any way in order to provide the defined operation.

[0074] Although illustrative embodiments of the present invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the present invention is not limited to these exact embodiments and that various changes, additions and modifications may be implemented therein by those skilled in the art without departing from the scope and spirit of the present invention as defined in the appended claims. For example, the features of the dependent claims may be variously combined with the features of the independent claims without departing from the scope of the present invention.

Claims

1. A data processing device, comprising: an input policy filter for receiving input data and an input origin regarding the input data, and forwarding some or all of the input data and the input origin according to at least one input policy; a processing environment for receiving input data forwarded by the input policy filter and processing the input data to generate output data; a management environment for generating an attestation of said processing environment and generating an output provenance based on said input provenance and said attestation; as well as an output policy filter for receiving the output data and the output origin and forwarding the output data and the output origin according to at least one output policy, wherein The input origin is cryptographically signed; and The management environment causes the authentication of the processing environment to be cryptographically signed, The authentication of the processing environment includes a hash of at least a portion of the processing environment or a hash of the output data.

2. The data processing device according to claim 1, wherein The at least one input policy includes at least one input origin condition; and The input data and the input origin are forwarded according to the at least one input origin condition.

3. The data processing apparatus according to claim 2, wherein The input origin condition is applied to a subset of the inputs of the input policy filter; and In response to the input origination condition being missing, an error is triggered.

4. The data processing device according to any one of claims 1 to 3, wherein The input policy filter is adapted to prohibit the input origin from being passed to the processing environment and to forward the input origin to the management environment.

5. The data processing device according to any one of claims 1 to 3, wherein At least one of the following occurs: The at least one input policy limits forwarding of the input data based on an identity of a source of the input data, and The at least one output policy limits forwarding of the output data based on an identity of a destination of the output data.

6. The data processing device according to any one of claims 1 to 3, wherein The at least one input strategy includes a plurality of input strategies; The input policy filter applies one of the plurality of input policies; and One of the plurality of input strategies is selected according to a data source of the input data or a type of the input data.

7. The data processing device according to any one of claims 1 to 3, wherein The at least one output strategy includes a plurality of output strategies; The output policy filter applies one of the plurality of output policies; and One of the plurality of output strategies is selected according to a target of the output data or a type of the output data.

8. The data processing device according to any one of claims 1 to 3, wherein The input data includes data received via a plurality of data sources; and The input provenance includes provenance information about each of the plurality of data sources.

9. The data processing device according to any one of claims 1 to 3, wherein The processing environment is signed with a cryptographic signature; and The management environment is adapted to check the validity of the cryptographic signature.

10. The data processing device according to any one of claims 1 to 3, wherein The at least one input policy includes at least one of a required input data type, a maximum input data quantity, a maximum input data rate, and a maximum input data latency.

11. The data processing device according to any one of claims 1 to 3, wherein The at least one output policy includes at least one of a required output data type, a maximum output data quantity, a maximum output data rate, and a maximum output data latency.

12. The data processing device according to any one of claims 1 to 3, wherein The at least one output policy includes a requirement that a type of the output data matches a type of the input data.

13. The data processing device according to any one of claims 1 to 3, wherein The output policy filter is adapted to perform a conversion from a type of the output data to a type of the input data in response to the type of the output data being different from the type of the input data.

14. The data processing device according to any one of claims 1 to 3, wherein The management environment is adapted to generate the output provenance by concatenating the certificate with the input provenance.

15. The data processing device according to any one of claims 1 to 3, wherein The management environment is adapted to generate the output provenance by merging the attestation with the input provenance.

16. The data processing device according to any one of claims 1 to 3, wherein In response to the input provenance satisfying a condition, the management environment is adapted to generate the output provenance by outputting the attestation.

17. The data processing apparatus according to claim 16, wherein The conditions include a requirement that the origin of the input be verified.

18. The data processing device according to any one of claims 1 to 3, wherein The processing environment is adapted to process the input data or the output data to generate further output data; and The output policy is adapted to permit forwarding of the further output data in dependence on the output data.

19. The data processing apparatus according to claim 18, wherein The output policy is adapted to permit forwarding of the further output data in dependence on the output data having a given characteristic.

20. The data processing device according to any one of claims 1 to 3, wherein The management environment is provided by a hypervisor; and The processing environment is a virtual machine managed by the hypervisor.

21. The data processing device according to any one of claims 1 to 3, wherein The management environment is adapted to control the behavior of the processing environment to operate according to at least one processing policy.

22. The data processing apparatus according to claim 21, wherein The at least one processing strategy includes a state reset condition; and In response to the state reset condition being satisfied, the management environment causes a processing state of the processing environment to be reset.

23. The data processing apparatus according to claim 21, wherein The at least one processing strategy includes a logging condition; and In response to the recording condition being satisfied, the management environment causes a processing state to be performed to be recorded.

24. The data processing apparatus according to claim 21, wherein The at least one processing strategy includes one or more error handling rules; and In response to an error condition occurring in the processing environment, the management environment causes the error condition to be handled according to the one or more error handling rules.

25. The data processing device according to any one of claims 1 to 3, wherein Authentication is provided for at least one of the at least one input policy and the at least one output policy.

26. The data processing device according to any one of claims 1 to 3, wherein At least one of the at least one input policy and the at least one output policy includes a base policy and other policies; and The other policies are at least as restrictive as the base policy.

27. A method of data processing, comprising: receiving input data and input origin regarding said input data; forwarding some or all of the input data and the input origin according to at least one input policy at an input policy filter; receiving input data forwarded by the input policy filter; processing the input data to generate output data; generating a cryptographically signed certificate of the processing environment; generating an output provenance based on the input provenance and the authentication; and receiving the output data and the output origin and forwarding the output data and the output origin according to at least one output policy, wherein The input origin is cryptographically signed, The authentication of the processing environment includes a hash of at least a portion of the processing environment or a hash of the output data.

28. A data processing device, comprising: means for receiving input data and input origination regarding said input data; means for forwarding some or all of said input data and said input origin according to at least one input policy; means for receiving input data forwarded by the means for forwarding; means for processing said input data to generate output data; means for generating a cryptographically signed certificate of the processing environment; means for generating an output provenance based on said input provenance and said authentication; as well as means for receiving the output data and the output origin and forwarding the output data and the output origin according to at least one output policy, wherein The input origin is cryptographically signed, The authentication of the processing environment includes a hash of at least a portion of the processing environment or a hash of the output data.

Images