Patent Description:
Sensors are ubiquitous in everyday life, and are essential for the functioning and maintenance of almost every device that we see and use. There is a need to ensure that data obtained by a given sensor cannot be accessed or modified by any other device. For example, it may be desirable that data collected by a sensor which detects wear and tear in industrial machinery only be accessible by devices belonging to engineers charged with maintenance of those machines. Similarly, it is also important to ensure that the sensor data cannot be manipulated, except by authorized parties. Conventionally, the access permissions of a device have been controlled by a security platform. However, with the advent of edge computing, in which data processing takes place at devices on the nodes of a network, rather than being performed centrally, the edge devices may be separated significantly from the security platform, by a so-called "air gap". In these cases, there may not be a secure connection or secure network between the edge device and the security platform. There is therefore a need for a system in which access to sensor data by a device can be securely controlled, even when the device and the sensor are remote from the security platform which controls the access permissions. This need is addressed by the invention to which the present application is directed.

<CIT> describes methods and systems for security and data privacy of lighting sensory networks. "<NPL>) describes a generic solution to ensure end-to-end access control for data generated by wireless sensors and consumed by business applications, based on a new approach for encryption-based access control.

In general terms, the present invention provides a system in which access control data, included on e.g. an authorization token which may be generated by a remote security platform is deployed on a device such as an edge device, the access control data e.g. on the authorization token defining the sensor data which the device has access to, and operations which the device is permitted to execute on that sensor data. A sensor generates sensor data, protects it, and then transmits it to the device for storage. So, even though the sensor data is stored on the device - the device may be unable to make use of it, because it is protected. If the device wishes to access the sensor data, it may send a request to the sensor, along with the access control data on e.g. the authorization token. The sensor then enables the device to execute only certain permitted operations, for example by returning to the device, keys which are usable only to execute the permitted operations. By deploying the authorization token on the device, there is no need for the device to have a physical connection with the security platform. And, because the data stored on the device is protected, and can only be accessed with the correct permissions, data security is not compromised. It will be noted that there are numerous components to this invention, each of which contributes to the technical advantages achieved. Accordingly, there are numerous aspects of the present invention.

One aspect of the invention provides a method of controlling access to sensor data, as set out in claim <NUM>.

Herein, the sensor data may be protected using a secret key, such as an encryption key.

Specifically, enabling the device to execute the permitted operation may comprise transmitting, to the device, a signal comprising one or more keys, or data encoding one or more keys, the one or more keys usable by the device to execute the permitted operation on the protected sensor data. Another aspect of the invention provides a sensor as set out in claim <NUM>.

There are two important ways in which access to the sensor data may be controlled: firstly, depending on the permitted operation, different keys may be provided to the device. Alternatively, or additionally, the sensor data may include a plurality of subsets (which may be distinct) of sensor data, each individually protected. In that case, the sensor may provide the device only with keys which are usable to access permitted subsets of the sensor data.

Another complementary aspect of the invention is a method which is performed by the device, rather than the sensor, specifically a method of accessing protected sensor data by a device, as set out in claim <NUM>.

A further aspect of the invention provides a device as set out in claim <NUM>.

Implementations of the present invention enable increased amounts of processing and computation to performed at "the edge" with reduced risk of interference by malicious actors. As a result, the invention may advantageously be applied to various use cases, such as smart vehicles and smart buildings. In the context of the present invention, the term "smart" is may be used generally to refer to areas of technology in which data is collected by sensors throughout e.g. the vehicle or the building, and the data is used to inform control processes relating to the vehicle or the building. With the advent of the so-called "internet of things", an increased amount of computation and processing is performed at the sensors themselves as well. According to a further aspect of the invention, there is provided a building comprising a plurality of sensors interconnected by a network, wherein at least one sensor of the plurality of sensors is a sensor according to a previous aspect of the present invention. Preferably, each sensor of the plurality of sensors is a sensor according to a previous aspect of the invention. Equivalent aspects of the invention provide a vehicle rather than a building.

The sensors according to all aspects of the invention may include any or all of the following: cameras, proximity sensors, CO<NUM> sensors, smoke sensors, pressure sensors, humidity sensors, accelerometers, position sensors, motion sensors, LiDAR-based sensors, temperature sensors, force sensors, vibration sensors, piezoelectric sensors, fluid property sensors, photo-optic sensors, light intensity sensors. It will be appreciated, however, that this is a non-exhaustive list, and the invention is in no way limited to these types of sensors.

In the context of vehicles, the "sensors" of the invention may be configured to sense specific conditions within the vehicle.

Then, the data may be protected to ensure that only authorized maintenance personnel are able to access the sensor data in order to inform maintenance decisions. Specific types of sensor data or other information which could be obtained in the context of smart vehicles or vehicles more generally include the following:.

The commercial contexts in which sensors obtaining this kind of information might be particularly useful include: insurance, fleet management, commerce/transactions, vehicle health/maintenance, vehicle-to-vehicle communications, autonomous vehicles, smart parking, traffic management.

Similar considerations apply to buildings including sensors: it is important to ensure that sensor data is only accessible by authorized maintenance personnel.

Embodiments of the invention will now be described with reference to the following drawings in which:.

The present invention relates to various methods and devices. In particular, the invention relates to a method performed by a sensor, a method performed by a device such as an edge device or a server, and a method performed by a system including the two. The invention also relates to the sensor, the device, and the system themselves. <FIG> shows a system <NUM> including a sensor <NUM> and a device <NUM>. <FIG> and <FIG> show, respectively, a specific example of a method according to the present invention that may be performed by the sensor <NUM> and the device <NUM>.

As discussed, the system <NUM> of <FIG> includes a sensor <NUM> and a device <NUM>. The sensor <NUM> and the device <NUM> are connected via a connection C. The connection C may be any form of connection which is able to convey data and/or information between the two. Preferably, the connection C is an electrical connection, and may be a wired connection or a wireless connection, such as a connection via a wireless network, such as a Wi-Fi or cellular network. Alternatively, the wireless connection may be in the form of a Bluetooth connection or a near-field communication connection. It will be understood that connection C could take a number of different forms which need not be explicitly set out here.

The sensor <NUM> includes a processor <NUM>, which includes an encryption module <NUM> and an access determination module <NUM>. Both with reference to <FIG>, and to the rest of the application, it should be noted that the term "module" refers to any functional unit configured to perform a given function. The module may be implemented either with dedicated, adapted, or modified hardware, or may alternatively be implemented in the form of a software module, e.g. in the form of a section of code.

The sensor <NUM> further includes a transmitter <NUM> and a receiver <NUM>. Here, the terms "transmitter" is used broadly to cover any component which is capable of transmitting data, or effecting the transmission of data. For example, the transmitter <NUM> may be configured to generate and send a wireless signal, the wireless signal encoding the data. Alternatively, the transmitter <NUM> may be configured to effect the transmission of data via a wired connection, such as the connection C. The term "receiver" should be treated similarly broadly as any component which is capable of receiving data. For example, the receiver <NUM> may be configured to receive a wireless signal, or may be configured to receive data via a wired connection, such as the connection C. The functions of the sensor <NUM>, processor <NUM>, encryption module <NUM>, access determination module <NUM>, transmitter <NUM>, and receiver <NUM> are described in more detail later in this application, with reference to <FIG> and <FIG>.

The device <NUM> includes a receiver <NUM>, a memory <NUM>, a processor <NUM> and a transmitter <NUM>. The terms "transmitter" and "receiver" should be interpreted as set out in the previous paragraph. The memory <NUM> of the device <NUM> includes, or has stored thereon an authorization token <NUM>, and encrypted sensor data <NUM>. The nature of these will be described later.

Before describing specific embodiments of the invention, we first set out optional features of the first aspect of the invention and the second aspect of the invention in general terms. Although reference numerals are used in the disclosure below, it should be noted that it is explicitly envisaged that the method may be implemented using a system other than the system shown in <FIG>.

As discussed previously, the first aspect of the invention provides a method of controlling access to sensor data, the method including the steps of generating sensor data, and protecting the sensor data using one or more secret keys, to generate protected sensor data <NUM>; and transmitting the protected sensor data <NUM> to a device <NUM> for storage; receiving, by the sensor <NUM>: an authorization token <NUM> including access control data defining one or more operations which the device <NUM> is permitted to execute on the protected sensor data <NUM>; determining by the sensor <NUM>, based on the access control data, an operation which the device <NUM> is permitted to execute on the protected sensor data <NUM>; providing, to the device <NUM>, one or more keys usable by the device <NUM> to execute the permitted operation on the protected sensor data <NUM>. In preferred cases, in order to reduce the storage requirements of the sensor <NUM> (specifically, a memory thereof), the method may further include a step of deleting the sensor data after the step of transmitting it to the device <NUM>. At the heart of the invention is the idea that the sensor <NUM> will provide to the device <NUM> only the key or keys which are usable by the device <NUM> to execute operations which it is permitted to execute, based on the access control data in the authorization token <NUM>. The permitted operations, and the nature of the keys associated therewith will be discussed in more detail later on, but before that, we describe a general case, in which various keys may be applied during the generation of the protected sensor data, and combinations of those keys are usable to execute various operations on the protected sensor data. It should be noted that the various keys may be applied one after the other, in a "stacked" manner.

In some cases, protecting the sensor data includes applying a first secret key to the sensor data, to generate first protected sensor data. Then, if the access control data defines that the device is permitted to execute a first operation on the first protected sensor data, the step of providing may include providing, to the device, a first complementary key, usable by the device to execute the first operation. Here, the first operation may be complementary to the application of the first secret key to the sensor data, e.g. encryption/decryption (this specific example is discussed in some detail later on in the application). Herein, the term "complementary" should be understand to mean that the key is able to perform the complementary action to the secret key. For example, if the secret key is an encryption key, the complementary key may be the corresponding decryption key. If the secret key is used to generate an authentication code, then the complementary key may be the same as the secret key, thereby enabling the device to generate the same authentication code, in order to authenticate the protected sensor data. It is important to note that the complementary key may be the same as the secret key.

In a preferred case, the first secret key is an encryption key, and the first protected sensor data is encrypted sensor data. The first operation may then be a decryption or reading operation. In that case, the step of providing may include providing a complementary key in the form of a decryption key to the device. In some embodiments, the encryption key may be a symmetric encryption key, in which case the encryption key and the decryption key may be the same. In this example, the sensor encrypts the sensor data and the device can only receive the key to decrypt it if the access control data specifies that it is permitted.

In other cases, protecting the sensor data may include applying a second secret key to the first protected sensor data, to generate second protected sensor data. Then, two possible outcomes are possible:.

Below, we describe two example scenarios in which two keys may be used.

The first is where the sensor data first has an authentication key applied to it, to generate an authentication code. Then, an encryption key is applied to the combination of the sensor data and the authentication code, to generate encrypted sensor data. In this case, the first secret key is the authentication key; the first protected data is the combination of the sensor data and the authentication code; the second secret key is the encryption key; and the second protected sensor data is the encrypted sensor data. Then, consider cases <NUM> and <NUM> referred to above:.

In a second example, the first secret key may be an encryption key, and the first protected sensor data may be encrypted sensor data. Then, the second secret key may be a second authentication key (unrelated to the first authentication key which formed part of the previous example), and the second protected sensor data may take the form of an authentication code or, preferably, a combination of the encrypted sensor data and the authentication code. The first operation may be a decryption operation, and the second operation may be an authentication operation. Note that this is opposite from the previous example.

The above examples only require (explicitly) the application of a first secret key and a second secret key. However, it will be appreciated that the method may be generalized to the application of a general plurality of secret keys. In such cases, protecting the sensor data may include applying, a plurality of secret keys to the sensor data to generate the protected sensor data. Then, the step of providing may include providing, to the device, a plurality of complementary keys, each complementary to a respective secret key of the plurality of secret keys, a combination of the plurality of complementary keys usable by the device to execute the permitted operation.

In a case which is an extension of the specific example discussed above, three keys are used:.

In this case, protecting the sensor data includes the following steps: applying the first authentication key to generate first protected sensor data including the sensor data and a first authentication code; applying the encryption key to the first protected sensor data to generate second protected sensor data in the form of encrypted sensor data (which is an encryption of both the sensor data and the first authentication code); and applying the second authentication key of the second protected sensor data to generate third protected sensor data including the encrypted sensor data and a second authentication code.

This example effectively combines the two examples set out above. In this case:.

If the access control data defines that the device is permitted to authenticate the encrypted sensor data, the step of providing may include: providing, to the device, the second authentication key usable by the device to authenticate the encrypted sensor data.

If the access control data defines that the device is permitted to decrypt the encrypted sensor data, the step of providing may include providing to the device, a decryption key (complementary to the encryption key) usable by the device to decrypt the encrypted sensor data. In the case that a symmetric encryption key is used, the encryption key and the decryption key may be identical. In the event that the access control data defines that the device is permitted to authenticate and decrypt the encrypted sensor data, then both keys may be provided, to enable the device to execute both operations.

If the access control data defines that the device is permitted to decrypt and re-authenticate the encrypted sensor data, or to modify the sensor data, the step of providing may include:.

It may be the case that the order in which the plurality of secret keys is applied is important, and correspondingly, the order in which the plurality of complementary keys is applied is also important. In these cases (which may or may not form a subset of the previous cases outlined above), protecting the sensor data may include: applying, in succession, N secret keys to the sensor data, to generate Nth protected sensor data, wherein application of the first key to the sensor data generates first protected sensor data, and, for k > <NUM>, applying the kth key to the (k-<NUM>)th protected sensor data generates kth protected sensor data, wherein <NUM> < k ≤ N. Then, if the access control data defines that the device is permitted to execute a Mth operation on the Nth protected sensor data, where <NUM> ≤ M ≤ N, the step of providing includes providing, to the device (N + <NUM> - M) complementary keys to the subset of keys of the plurality of secret keys for which M ≤ k ≤ N, the M keys being usable in succession from the Nth complementary key to the Mth complementary key, to execute or facilitate execution of the Mth operation. Specifically, the device may then apply the plurality of complementary keys on the Nth protected sensor in succession from N to M, wherein application of the kth complementary key to the kth protected sensor data retrieves the (k - <NUM>)th protected sensor data for k > <NUM>, and wherein application of the first complementary key to the first protected sensor data retrieves the sensor data.

According to certain implementations, the method may further include a step of generating a secret key for each individual piece of data which is generated by the sensor. The generation and storage of the secret keys in this manner is explained in more detail later in this application, in the context of encryption keys. However, it should be noted that that disclosure applies equally well to the case of a generic secret key used to protect the sensor data.

In some cases, the device may be permitted to execute different operations on different subsets of the data. For example, a given device may be able to modify and re-authenticate one subset of the data, but only to decrypt another subset. Such permissions are preferably defined in the access control data included in the authorization token. Specifically, the sensor data may include a first subset of sensor data, and a second subset of sensor data. Accordingly, generating the protected sensor data may include: protecting the first subset of sensor data to generate a first subset of protected sensor data, and protecting the second subset of sensor data to generate a second subset of protected sensor data. The way in which the sensor data may be divided into subsets is set out in detail later in this application. As before, generating the first subset of protected sensor data may include applying a first secret key to the first subset of sensor data, and generating the second subset of protected sensor data may include applying a second secret key to the second subset of sensor data.

In these cases, the access control data may define: a first operation which the device is permitted to execute on the first subset of protected sensor data; and/or a second operation which the device is permitted to execute on the second subset of protected sensor data.

Then, the step of determining may include determining, based on the access control data: a first operation which the device is permitted to execute on the first subset of protected sensor data; and/or a second operation which the device is permitted to execute on the second subset of protected sensor data. The device may not be permitted to execute an operation on both the first subset and the second subset. Accordingly, the step of providing may include: only if it is determined that the device is permitted to execute the first operation, providing one or more keys usable by the device to execute the first operation on the first subset the protected sensor data; and only if it is determined that the device is permitted to execute the second operation, providing one or more keys usable by the device to execute the second operation on the second subset of protected sensor data. In other words, the first and second operations cannot be executed unless the access control data dictates that the device is permitted to do so.

In a more general case, the sensor data may include a plurality of subsets of sensor data. The step of encrypting the sensor data may then include protecting each of the plurality of subsets of sensor data with a respective key to generate a respective plurality of subsets of protected sensor data. Accordingly then, the access control data may define one or more operations which the device is permitted to execute on a respective subset of protected sensor data. For example, an operation may be defined for each of the subsets of data, only for one of them, or for some of them. The step of determining may then include determining one or more operations which the device is permitted to execute on a respective subset of protected sensor data. Once this determination has taken place, the method may include a step of providing, to the device, one or more keys, each key usable by the device to execute a permitted operation on a respective subset of the protected sensor data.

In the above examples, it is only specified that the authorization token is received by the sensor. It should be understood that the determining step takes place in response to receiving the authorization token. In the cases above, it should be understood that in response to the step of determining, the sensor provides, to the device, the key or keys which are usable by the device to execute all of the operations which are permitted, based on the access control data. However, in some cases, the device may not wish to execute all possible operations. In such cases, the method may further include a step of receiving an access request from the device, the access request specifying one or more of: the first operation to be executed on the first subset of protected sensor data, and the second operation to be executed on the second subset of protected sensor data. Then, the step of determining may include: determining whether the device is permitted to execute the first operation on the first subset of protected sensor data; and/or determining whether the device is permitted to execute the second operation on the second subset of protected sensor data. Then, as already discussed, the relevant keys will be provided only in the event that a positive determination has taken place.

Above, we have set out implementations in which more than one operation may be executed on the protected sensor data, depending on the permissions of a given device. We have also set out implementations in which a device may perform different operations on different subsets of sensor data. It should be noted that the invention also encompasses implementations in which each of the plurality of subsets of protected sensor data are protected by a plurality of secret keys, and the access control data defines separate operations which may be executed for each subset of protected sensor data. Such an implementation is obtainable by combining the optional features set out above, and should be considered to be explicitly disclosed in this application.

When the sensor <NUM> receives the authorization token <NUM>, it may perform a step of authenticating the authorization token <NUM>. For example, when it is generated, the authorization token <NUM> may have been signed using e.g. an elliptic curve digital signature algorithm and a private key. The private key may be on-boarded in a PKI, so it is signed by a certification authority (CA) in the form of certificates. The root CA public key may be hardcoded into the sensor <NUM>, e.g. a sensor secure element thereof, and may then be used to authenticate the authorization token <NUM>. When the device <NUM> requests access to data, a secure channel may be set up between the sensor <NUM> and the device <NUM>. In this case, the sensor <NUM> and/or the device <NUM> may perform a mutual authentication process, using either e.g. a pre-shared symmetric key, or an asymmetric PKI.

In a preferred implementation of the present invention, the method is used to protect the sensor data at least by encrypting it, thereby generating encrypted sensor data. In such cases, the method includes the steps of generating sensor data, and encrypting the sensor data using an encryption key, to generate encrypted sensor data <NUM>; and transmitting the encrypted sensor data <NUM> to a device <NUM> for storage; receiving, by the sensor <NUM>: an authorization token <NUM> including access control data defining one or more operations which the device <NUM> is permitted to execute on the encrypted sensor data <NUM>; determining by the sensor <NUM>, based on the access control data, an operation which the device <NUM> is permitted to execute on the protected sensor data <NUM>; providing, to the device <NUM>, one or more keys usable by the device <NUM> to execute the permitted operation on the encrypted sensor data <NUM>. Additional optional features of the invention are set out below. It should be noted that the features set out below may represent re-wording of the examples described above. Where compatible, any optional feature of the invention disclosed in this application may be combined with any other feature, without extending beyond the intended scope of this disclosure. In particular, it should be noted that any optional features set out below relating to encryption, or encryption keys may apply equally well for general protection using secret keys or the secret keys themselves, and their complements.

An important aim of the present invention is to ensure that the sensor data remains secure, and can only be read and/or modified by particular, specified, parties. Accordingly, the operations may include decrypting the encrypted sensor data <NUM>, and modifying and re-authenticating the sensor data. In the latter case, it will be appreciated that the encrypted sensor data <NUM> must first be decrypted before the corresponding (i.e. non-encrypted) sensor data can be modified.

We first consider the case where the access control data defines that the device <NUM> is permitted to decrypt the encrypted sensor data <NUM>. In this case, the method may include providing, to the device <NUM>, a decryption key usable by the device <NUM> to decrypt the encrypted sensor data. In other words, because the access control data defines that the device is permitted to decrypt the encrypted sensor data <NUM>, it will be determined (based thereon) that the device is permitted to decrypt the encrypted sensor data <NUM>. In some cases, the encryption key may be a symmetric key, in which case the decryption key may be the same as the encryption key which was used to encrypt the sensor data in the first place.

In other cases, the device <NUM> may be permitted to go one step further, and to modify the sensor data. It will be noted that any party with the decryption key would be able to decrypt and modify the data. However, it is of vital importance that unauthorized modifications of the data are identifiable so that they may be disregarded. In order to ensure that this is the case, the step of encrypting may include applying a first authentication key to the data before using the encryption key. In this way, if an unauthorized party were to modify the sensor data, and then to re-encrypt it, without the first authentication key, they would be unable to authenticate the data, and it would be straightforward to detect that unauthorized tampering had taken place. Consider now the case where a device <NUM> is permitted to modify the data. If the access control data that the device <NUM> is permitted to modify the sensor data, the method may include: providing to the device <NUM>, a decryption key usable to decrypt the encrypted sensor data, thereby outputting the sensor data; and providing to the device <NUM> the first authentication key, usable by the device <NUM> to re-authenticate the modified sensor data. The device <NUM> may thus be configured to decrypt the data, modify it, and reapply the authentication key to authenticate the modified sensor data. The device <NUM> may then re-encrypt the data.

In some other cases, the operations may include authenticating the encrypted sensor data only. In other words, in some cases, the device <NUM> may wish to confirm that the encrypted sensor data <NUM> has not been tampered with between its generation and transmission to and storage on the device. In order to achieve this, the step of encrypting may include applying a second authentication key after to the encrypted sensor data <NUM>. Then, the step of providing may include providing, to the device <NUM>, the second authentication key, usable by the device <NUM> to authenticate the encrypted sensor data. It should be noted that in cases in which the device <NUM> is permitted to decrypt and/or modify the sensor data, as described above, the second authentication key may also be provided to the device <NUM>.

It should be noted that in the context of the present application, an authentication key is a key which may be applied to some data (either encrypted or unencrypted) which outputs a message authentication code (MAC). The MAC may then be tagged to the original data (i.e. the "message"). Specifically, applying an authentication key to the data may comprise applying a key-based algorithm to the data, which is an algorithm whose output depends on the input data and the key. In other words, the same result is only obtained if both the input data and the key are the same. A different key will yield a different result. In preferred examples, applying an authentication key to the sensor data (or encrypted sensor data) may comprise using a keyed hash algorithm or HMAC scheme involving an authentication key, on the sensor data (or encrypted sensor data) to generate a HMAC. Other keyed authentication schemes are also envisaged.

It should be noted that any actions described throughout this application in respect of the encryption key may also be performed in respect of the first and/or second authentication keys (particularly those actions relating to generation and/or retrieval of those keys).

In some cases, different operations may be permitted for different subsets of the sensor data. For example, a sensor <NUM> may obtain two different types of data, and a given device <NUM> may be permitted only to read one type of data, but to modify the other type. Alternatively, the device <NUM> may only be permitted to view data which was recorded within a specific time frame. Some implementations of the present invention enable different rules to apply for different subsets of the sensor data. Specifically, the sensor data may include a first subset of sensor data and a second subset of sensor data. Of course, the sensor data may be divided into a general plurality of subsets of sensor data. Here, the division into a first subset and second subset is for illustrative purposes. The general case will be described later.

There are numerous ways in which the sensor data may be divided into subsets. For example, the method may include generating and appending a header to each piece of sensor data generated, the header including metadata containing information about that piece of sensor data, the metadata including one or more of: a timestamp indicating a time and/or date at which the piece of sensor data was collected/generated; a sensor ID identifying the sensor which collected the data; a data type indicating the type of data; and one or more device IDs identifying devices <NUM> which are permitted to access the data. In such cases, the subset to which each respective piece of sensor data belongs is based on the metadata in the header of that piece of sensor data.

The step of encrypting may include encrypting the first subset of sensor data with a first encryption key to generate a first subset of encrypted sensor data <NUM>; and encrypting the second subset of sensor data with a second encryption key, different from the first encryption key, to generate a second subset of encrypted sensor data <NUM>. In such cases, the access control data may define a first operation which the device <NUM> is permitted to execute on the first subset of encrypted sensor data <NUM>; and/or a second operation which the device <NUM> is permitted to execute on the second subset of encrypted sensor data <NUM>. Accordingly, the step of determining may include determining, based on the access control data: a first operation which the device <NUM> is permitted to execute on the first subset of encrypted sensor data <NUM>; and/or a second operation which the device <NUM> is permitted to execute on the second subset of encrypted sensor data <NUM>. The device <NUM> may not be permitted to execute an operation on both the first subset and the second subset. Accordingly, the step of providing may include: only if it is determined that the device <NUM> is permitted to execute the first operation, providing one or more keys usable by the device <NUM> to execute the first operation on the first subset the encrypted sensor data <NUM>; and only if it is determined that the device <NUM> is permitted to execute the second operation, providing one or more keys usable by the device <NUM> to execute the second operation on the second subset of encrypted sensor data <NUM>. In other words, the first and second operations cannot be executed unless the access control data dictates that the device <NUM> is permitted to do so.

In a more general case, the sensor data may include a plurality of subsets of sensor data. The step of encrypting the sensor data 24may then include encrypting each of the plurality of subsets of sensor data with a respective key to generate a respective plurality of subsets of encrypted sensor data <NUM>. Accordingly then, the access control data may define one or more operations which the device <NUM> is permitted to execute on a respective subset of encrypted sensor data <NUM>. For example, an operation may be defined for each of the subsets of data, only for one of them, or for some of them. The step of determining may then include determining one or more operations which the device <NUM> is permitted to execute on a respective subset of encrypted sensor data <NUM>. Once this determination has taken place, the method may include a step of providing, to the device <NUM>, one or more keys, each key usable by the device <NUM> to execute a permitted operation on a respective subset of the encrypted sensor data <NUM>.

In the above examples, it is only specified that the authorization token <NUM> is received by the sensor <NUM>. It should be understood that the determining step takes place in response to receiving the authorization token <NUM>. In the cases above, it should be understood that in response to the step of determining, the sensor <NUM> provides, to the device <NUM>, the key or keys which are usable by the device <NUM> to execute all of the operations which are permitted, based on the access control data. However, in some cases, the device <NUM> may not wish to execute all possible operations. In such cases, the method may further include a step of receiving an access request from the device <NUM>, the access request specifying one or more of: the first operation to be executed on the first subset of encrypted sensor data <NUM>, and the second operation to be executed on the second subset of encrypted sensor data <NUM>. Then, the step of determining may include: determining whether the device <NUM> is permitted to execute the first operation on the first subset of encrypted sensor data <NUM>; and/or determining whether the device <NUM> is permitted to execute the second operation on the second subset of encrypted sensor data <NUM>. Then, as already discussed, the relevant keys will be provided only in the event that a positive determination has taken place.

As before, this may be generalized to the case where there are a plurality of subsets of sensor data. In this case, the access request may specify one or more operations to be executed on a respective subset of sensor data, and the step of determining includes determining whether the device <NUM> is permitted to execute each specified operation on the respective specified subset of encrypted sensor data <NUM>.

The optional features presented above relate primarily to the first aspect of the invention, namely the method executed by the sensor <NUM>. However, it will be appreciated that, where compatible, these features apply equally well to the second aspect of the invention, namely the method executed by the device <NUM>. Below, we set out, in general terms, some additional optional features which may apply to the second aspect of the invention. the second aspect of the invention provides a method of accessing protected sensor data by a device <NUM>, device <NUM> having stored thereon an authorization token <NUM> including access control data defining one or more operations which the device <NUM> is permitted to execute on encrypted sensor data <NUM>, the method including the steps of: receiving encrypted sensor data <NUM> from a sensor, the encrypted sensor data encrypted using an encryption key; storing the received sensor data; sending the authorization token <NUM> to the sensor; and receiving a key usable by the device <NUM> to execute a permitted operation on the encrypted sensor data <NUM>. As previously discussed, the operations may include decrypting the encrypted sensor data <NUM>; and modifying and re-authenticating the sensor data.

When the invention is defined in broad terms, as above, the device <NUM> sends only the authorization token <NUM> to the sensor <NUM>. In these cases, the device <NUM> may receive keys which are usable to execute all of the operations permitted by the access control data of the authorization token <NUM>. However, in some cases where this is not desirable, the device <NUM> may send an access request to the sensor <NUM>, the access request specifying a requested operation to be executed on the encrypted sensor data <NUM>.

As we explained above with reference to the first aspect of the invention, the sensor data may include a first subset and a second subset, and the device <NUM> may be permitted to execute different operations on the different subsets. As before, the encrypted sensor data <NUM> may include a first subset of encrypted sensor data <NUM> and a second subset of encrypted sensor data <NUM>. Then, the access control data may define a first operation which the device is permitted to execute on the first subset of encrypted sensor data <NUM>, and/or a second operation which the device is permitted to execute on the second subset of encrypted sensor data <NUM>. In such cases, as a result of the determination step which takes place at the sensor <NUM>, the step of receiving may include: only if it defined in the access control data that the device is permitted to execute the first operation, receiving one or more keys usable by the device <NUM> to execute the first operation on the first subset of the encrypted sensor data <NUM>; and only if it is defined in the access control data that the device <NUM> is permitted to execute the second operation, receiving one or more keys usable by the device <NUM> to execute the second operation on the second subset of encrypted sensor data <NUM>. Of course, the sensor data may include more than just first and second subsets. The optional features described in this paragraph may be generalized to a general plurality of subsets of sensor data. Specifically, the device <NUM> may receive a plurality of subsets of encrypted sensor data <NUM>, and the access control data may define one or more operations which the device <NUM> is permitted to execute on a respective subset of encrypted sensor data <NUM>. For example, an operation may be defined for each of the subsets of data, only for one of them, or for some of them. Then, the method include a step of receiving from the sensor <NUM>, one or more keys, each key usable by the device <NUM> to execute a permitted operation on a respective subset of the encrypted sensor data <NUM>.

In cases where the device <NUM> sends an access request, the access request may specify one or more of: the first operation to be executed on the first subset of encrypted sensor data <NUM>, and the second operation to be executed on the second subset of encrypted sensor data <NUM>.

For added security, the sensor <NUM> may encrypt the key or keys before providing them to the device. In preferred implementations, the sensor <NUM> may be pre-loaded with a public key, and the device <NUM> may be pre-loaded with a private key, and the method may include a step of encrypting the key or keys using the public key. Because only the device <NUM> to which the key or keys are being sent has the private key which is capable of decrypting the encrypted keys, other external parties are prevented from accessing the key or keys, and accordingly, the sensor data. Method of the second aspect of the invention may include a corresponding step of decrypting the key or keys, preferably using a private key.

The method of the second aspect of the invention may further include a step of using the key or keys received from the sensor to execute the permitted operations, e.g. the first operation and/or the second operation.

<FIG> and <FIG> present a specific example of the method of the first and second aspects of the invention, in the form of a series of steps S1 to S12 which may be performed by system <NUM> of <FIG>. In preferred cases, the steps S1 to S12 are performed that order, though the skilled person will appreciate that it may be possible to vary the order of some of the steps. <FIG> shows the steps which are performed by the sensor <NUM>, and <FIG> shows the steps which are performed by the device <NUM>.

In step S1, the sensor <NUM> generates sensor data. At this point, it is worth specifying some of the envisaged uses of the present invention. For example, the device <NUM> may be an edge gateway or control unit which manages several sensors, for which it needs different and specific accesses. One example may be a tracking control unit connected to a container which uses accelerometer data generated to guide specific operations (e.g. plane landing detection) and which also store encrypted data generated by temperature sensor or door status sensors to be reported in a cloud to guarantee transport quality and non-tampering. The integrity and privacy of temperature and door status tracking data are end-<NUM>-end protected between the sensor and the system. In another example: a vehicle (such as a car, a boat, a train etc.) with several sensors all connected to a local network in which there are different control units that need different and specific access to the data generated by the sensors. One sensor may provide different types of data to different control units, all managed and authorized by a system setup at production, in maintenance phase or in the field on-request when connected.

Once the sensor data has been generated by the sensor <NUM>, in step S2, the sensor data is encrypted by the encryption module <NUM> of the processor <NUM>. Then, in step S3, the transmitter <NUM> sends the encrypted sensor data <NUM> to the device <NUM>, which is received by the receiver <NUM> of the device <NUM> in step S4 in <FIG>. In preferred cases, the method further includes a step of deleting the sensor data after transmitting it to the device <NUM> for storage in memory <NUM>. Alternatively put, the sensor <NUM> may be configured to delete the sensor data after transmitting it to the device <NUM> in storage in memory <NUM>.

Then, in step S5, the encrypted sensor data <NUM> is stored in the memory <NUM> of the device <NUM>. At this point, when a user of the device <NUM> wishes to access some or all of the encrypted sensor data <NUM>, in step S6 the processor <NUM> of the device <NUM> may generate an access request, which may, optionally, specify a subset of the encrypted sensor data <NUM> which the user of the device <NUM> wishes to access. The access request is a request from the device <NUM> to execute some kind of operation on the encrypted sensor data, and will be discussed in detail later on in this application. In step S7, the transmitter <NUM> of the device <NUM> transmits the request to the sensor <NUM>, along with the authorization token <NUM>, or a copy thereof. It should be noted that in some cases, the transmitter <NUM> may transmit only the authorization token <NUM>. In such cases, the sensor <NUM> may send to the device <NUM> the keys enabling all permitted actions to be executed.

The authorization token <NUM> includes access control data defining sensor data <NUM> which the device <NUM> is permitted to access. For example, the access control data may define one or more subsets of the sensor data <NUM> which the device <NUM> is permitted to access. In addition, the access control data may define operations which the device <NUM> may execute on the encrypted sensor data.

The features of the authorization token <NUM> will be described in more detail later on in this application. Returning to <FIG>, in step S8, the receiver <NUM> of the sensor <NUM> receives the access request and the authorization token <NUM> from the transmitter <NUM> of the device <NUM>. Then, in step S9, the access determination module <NUM> of the processor <NUM> of sensor <NUM> determines, based on the access control data in the authorization token <NUM>, whether the device <NUM> is permitted to access the encrypted sensor data <NUM>. In some cases, the access determination module <NUM> determines which encrypted sensor data <NUM> the device <NUM> is permitted to access, or which operations the device <NUM> is permitted to execute. This access determination process is central to the invention, and will be described in more detail later on. In step S10 the sensor <NUM>, specifically the transmitter <NUM> thereof, sends one or more access keys to the device <NUM>, the key(s) usable to execute the permitted operations. Returning finally to <FIG>, the receiver <NUM> of the device <NUM> receives the access key in step S11, and the processor <NUM> of the device <NUM> uses the access key or keys to execute the permitted operation on the encrypted sensor data <NUM>.

<FIG> shows an alternative example of a sensor module <NUM> which may form part of a system of the present invention or may perform a method of the present invention (e.g. steps S1, S2, S3, S8, S9, and S10 as shown in <FIG>). The fundamental structure of the sensor module <NUM> of <FIG> is similar to the structure of the sensor <NUM> of <FIG>, but shows numerous optional features.

Although the optional features of <FIG> are shown in a single drawing, it should be stressed that, by their very nature as optional features, it is not necessary for all of this features to be present in combination exactly as is shown in <FIG>. They are shown in a single sensor <NUM> for illustrative purposes, and it should be understood that any, some, or all of the features shown in the alternative sensor <NUM> of <FIG> may be excluded from the example without the resulting arrangement falling outside the scope of this disclosure.

As with <FIG>, we will first describe the structure of sensor <NUM>, and then explain the function of the various optional modules. Sensor <NUM> includes a sensor secure environment (SSE) <NUM>, which may be defined as sub-system of the sensor <NUM> which implements the controlled storage and use of sensor data. One purpose of secure environments such as SSE <NUM> is to protect secure/confidential data in the event of a data loss. SSE <NUM> may use cryptographic means, such as hashing, as a way to protect information. In <FIG>, the SSE <NUM> includes processor <NUM>, memory <NUM>, data collection module <NUM>, and a device interface module <NUM>. It is preferable that the processor <NUM> and memory <NUM> are located within SSE <NUM>, however, the device interface module <NUM> may be located within the sensor <NUM> but outside the SSE <NUM>. The device interface module <NUM> acts as an interface between external signals and devices (e.g. device <NUM> or device <NUM>) and the sensor <NUM>. The device interface module <NUM> in <FIG> includes transmitter <NUM> and receiver <NUM>. Alternatively, in other cases, the device interface module <NUM> may act as an interface only, and be configured to convey signals to a transmitter <NUM>, and to receive signals from a receiver <NUM>; such examples still fall within the scope of the invention.

The processor <NUM> of <FIG> may include one or more of: an encryption module <NUM>, an access determination module <NUM>, and an authorization module <NUM>. Likewise, the memory <NUM> may include a persistent memory <NUM> and a buffer <NUM>. The buffer may have a capacity of 100KB to 10MB. Here, the term "persistent memory" should be understood to refer to long-term memory, or permanent memory. Only data which requires long-term storage should be stored on the persistent memory <NUM>, such as metadata <NUM> and encryption key data <NUM> in the present example. The nature of this data will be described in more detail later on. Buffer <NUM> is short-term memory, and may be used to store sensor data <NUM> after it has been generated and before it has been transmitted by e.g. transmitter <NUM> to the device (e.g. <NUM> or <NUM>).

The function of the components shown in <FIG> will now be described in more detail, in the context of the high-level method of <FIG> and <FIG>, setting out any further optional features.

The data collection module <NUM> is the module of the sensor <NUM> which performs the sensing itself, and as such it may include a sensing element <NUM> which is configured to sense, detect, and/or measure, some external parameter. The sensing element <NUM> may include one or more of the following: a temperature sensor, a light sensor, a sound sensor, a moisture sensor, a CO<NUM> sensor, a smoke sensor, a pressure sensor, a humidity sensor, a proximity detector or a camera. It may also include a device or devices configured to measure one or more of the following: voltage, current, resistance, magnetic field strength, magnetic flux density, capacitance, inductance, frequency, and wavelength. The sensing element <NUM> may also include an accelerometer. It will be appreciated the sensing element <NUM> may include a device which is configured to sense, detect, or measure any form of external physical or environmental stimulus. As well as detecting a physical or environmental stimulus, the sensing element <NUM> may be implemented in the form of a software module, which is configured to detect the occurrence of a predetermined process in a computer device (such as a computer, a tablet, or a smartphone). For example, the sensing element <NUM> may be configured to detect a predetermined data processing operation, or to detect a particular result of a data processing operation. The sensing element <NUM> may include a counter configured to count the number of times a particular event takes place. The data collection module <NUM> may optionally include its own processor, configured to convert the raw data collected by the sensing device <NUM> into a form which can be processed by the processor <NUM>. Alternatively, the raw data may be sent straight to the processor <NUM>, whereupon it is converted into a more suitable form. It should be appreciated that the sensor <NUM> may include more than one data collection module <NUM>. Each data collection module <NUM> may also include one or more sensing element <NUM>, of the type described in this paragraph.

In step S2 of <FIG>, the sensor data is encrypted. Before discussing the encryption process, it is useful to describe in some more detail the possible nature of the sensor data which is obtained, and optional processes that may be carried out on it before it is encrypted.

When a piece of sensor data is first collected, the processor <NUM> may be configured to generate a header, and append that header to the piece of data. Between collection of data and the appending of the header, the piece of sensor data may be stored in the buffer <NUM> of the memory <NUM> of the sensor <NUM> for processing. The buffer <NUM> is suitable for this storage, because it is short term storage only. The header preferably contains metadata containing information about that piece of sensor data, the metadata preferably including one or more of: a timestamp indicating a time and/or date at which the data was collected, a sensor ID indicating the identity of the sensor <NUM> or sensing element <NUM> which collected the data, a data type indicating the type of data (e.g. the physical parameter to which the data pertains, or the type of activity detected), nonce material, and key-generation data which may be used to generate the required keys, sensor information such as hardware and firmware references (e.g. ID and version). These are referred to as "types of metadata". The sensor data may be divided into a plurality of subsets. These may be exclusive subsets, i.e. each piece of sensor data belongs to one subset only. Alternatively, each piece of sensor data may belong to one or more subsets. A subset may including only a single piece of sensor data.

The sensor data may be subdivided into subsets based on a first type of metadata. In other words, the sensor data may be divided into a plurality of subsets, each subset being recorded within a different time frame, or each being a different type of data, or each being recorded by a different sensor. The sensor data may be further divided into a plurality of subsets based on a second type of metadata.

Here, the term "divided" need not mean that the sensor data is partitioned, or that the different subsets are stored separately from each other, though this may optionally be the case. Preferably, though, the plurality of subsets may be assigned based on the metadata, but (at least at this point) are not separated from each other. At this point, we have established a plurality of subsets of data, each piece of data optionally including a header containing metadata which provides information about that data, and the subsets being based on the metadata. At this point, the pieces of data with the appended headers may temporarily be stored in the buffer <NUM> of the memory <NUM> of the sensor <NUM>.

Then, the encryption module <NUM> of the processor <NUM> is configured to encrypt the sensor data, to generate encrypted sensor data. The encryption module <NUM> may be configured to encrypt both the sensor data and the header, but preferably encrypts only the sensor data. Specifically, the encryption module <NUM> is configured to encrypt each of the plurality of subsets of data with a different respective encryption key.

In the case where each piece of sensor data belongs to a single subset of the plurality of subsets, this is straightforward.

However, in the event that a piece of data may belong to or be assigned to more than one subset (e.g. a subset established based on the time at which the data was recorded, and a subset based on the sensing element <NUM> which recorded the data), the situation is more complex, and may be addressed in any of the following ways:.

We now discuss how the encryption takes place. In a simple case, the encryption module <NUM> may be configured to encrypt a given piece of sensor data (throughout this application, unless otherwise specified, the term "sensor data" can be understood to refer to unencrypted sensor data) using an encryption key to generate a corresponding piece of encrypted sensor data. The encryption key may be a symmetric key or an asymmetric key. Each of these types of keys has associated advantages, depending on the priorities of the system. For example, symmetric keys are far simpler to generate, so if the encryption key is a symmetric key, the processing requirements of the processor <NUM> are reduced, allowing for the sensor <NUM> to be simpler, smaller, and cheaper to manufacture. On the other hand, an asymmetric key is more secure, but requires greater processing capability to generate and apply.

In order to be able to identify and transmit the appropriate access key to the device <NUM> or <NUM> in response to a request and a determination that access is permitted, the sensor <NUM> must be able either to store the keys in association with the metadata identifying the sensor data or encrypted data in the memory <NUM>. Alternatively, in order to reduce the memory requirements of the memory <NUM> of the sensor <NUM>, the processor <NUM> of the sensor <NUM> may be able to reliably re-generate the access keys based on some input. Both of these possibilities are described below.

The method of the first case is illustrated in <FIG>, which illustrates the process being performed on a single piece of sensor data. In step S108A, the piece of sensor data is received at the encryption module <NUM>, the piece of sensor data including metadata, the metadata identifying a subset to which that piece of sensor data belongs. Then, in step S108B, the encryption module <NUM> (or alternatively the processor <NUM>) is configured to perform a lookup in the encryption key data table <NUM> to determine whether an encryption key exists corresponding to the subset. Optionally, before this step is performed, the encryption module <NUM> or the processor <NUM> may remove the header from the piece of sensor data, and extract the metadata either containing or indicating the subset ID from the piece of sensor data (not shown). In the event that an encryption key does exist, in step S108C, the key is retrieved from the encryption key data table <NUM>, and used to encrypt the piece of sensor data in step S108E. In the even that it determined that no key exists corresponding to the subset, a new key is generated in step S108D, for example by key generation module <NUM>, and stored in the encryption key data table <NUM>, before that key is used to encrypt the piece of sensor data in step S108E. The method may stop here, but alternatively, it may continue to step S108F in which it is determined whether the piece of sensor data belongs to any additional subsets. If not, processing of that piece of data is complete, and the method may optionally return to step S108A, receiving a further piece of sensor data. Otherwise, if it is determined that the piece of sensor data does belong to another subset of sensor data, then the method returns to step S108B. Using this method, as more sensor data is received, the encryption key data table <NUM> grows. Two examples of example layouts of the encryption key data tables are shown in <FIG>. In <FIG>, the encryption keys are stored in association with subset IDs denoting a particular subset, whereas in <FIG>, the encryption keys are stored in association with a particular piece of metadata corresponding to a subset and a subset ID. In a slightly different case, the subset ID may not be included in the encryption key data table <NUM>.

It should be noted that, where asymmetric keys are used by the encryption module <NUM> to encrypt the piece of sensor data, in step S108D both the encryption key and the complementary decryption key should be generated, and then both are stored in the encryption key data table <NUM>. Alternatively, once the encryption key has been generated and used, it may be deleted, and only the decryption key stored.

In the examples given above, an encryption key data table <NUM> is generated and grown with the receipt of more and more sensor data. In some cases, e.g. when the capacity of memory <NUM> is limited, this may be undesirable. So, in an alternative example, the key generation module <NUM> may be configured to generate an encryption key which is based on one or more of the metadata or subset ID, and local key generation data <NUM>, which is unique to the sensor <NUM> and secret. In this way, once the encryption key has been generated, there is no need to store it in the memory of the sensor <NUM>, or elsewhere, because it can be reliably regenerated based on metadata relating to the sensor data which it protects. All that need be stored in the memory is the local key generation data <NUM>. <FIG> shows an example of this method. In step S109A, a piece of sensor data is received at the encryption module. Then in step S109B, the key generation module <NUM> may generate an encryption key based on the metadata in the header of the piece of sensor data, and the local key generation data <NUM>. It is important that the local key generation data <NUM> is used, and remains secret, otherwise it would be possible for any other actor to re-generate the key with only knowledge of the metadata, presenting a clear and not insignificant security risk. In step S109C, the generated encryption key is used to encrypt the piece of sensor data. Then, the generated encryption key may be deleted in step S109D. Alternatively, the generated encryption key may be stored in the buffer <NUM> in the temporary key data table <NUM>. In this way, when another piece of sensor data from the same subset is encountered, the encryption module <NUM> may perform a lookup in the temporary key data table <NUM>, in order to determine whether an encryption key corresponding to that subset has already been generated, in which case that encryption key is retrieved from the temporary key data table <NUM>, and used to encrypt the subsequent piece of sensor data. This may be particular useful in scenarios in which the subsets are based on the time at which the data is collected, so the same encryption key can be used to encrypt a series of pieces of sensor data, all of which were collected within a predetermined time range. Accordingly, the generated encryption keys which are stored in the temporary key data table <NUM> may have an associated lifespan or expiry time, after which they are deleted from the table <NUM>. After the piece of sensor data has been encrypted in step S109C and deleted in step S109D, the method returns to step S109A, with the arrival of a new piece of sensor data. In cases where asymmetric keys are generated, in step S109B both the encryption key and complementary decryption key are generated by the key generation module <NUM>. Then, the encryption key (preferably a private key) is used to encrypt the piece of sensor data in step S109C. The decryption key is preferably a public key.

The encryption of the data using the generated or retrieved encryption keys ensures that the data is, effectively, scrambled beyond recognition, in order to ensure that it is confidential, i.e. ensuring that a user intercepting its transmission is unable to derive any meaning from it. In addition to encrypting the sensor data, it is also important that the sensor <NUM>, and the device <NUM> or <NUM> are able to ensure that the data that they have received is received from the entity that they believe it has been received from - this is known as "authentication". A number of schemes are available for this process, such as encrypt-then-MAC, MAC-then-encrypt, and encrypt-and-MAC. It is preferred that the encrypt-then-MAC process is used in the present invention. This will be explained for a first piece of sensor data, but it will be understood that the method may be applied to every incoming piece of sensor data.

An example of this is shown in <FIG>. Firstly in step S108M, the piece of sensor data may be encrypted as explained in the preceding paragraphs, to generate a piece of encrypted sensor data. Then, in step S108N the encryption module <NUM> may be configured to apply an authentication key to the piece of encrypted sensor data, to generate a message authentication code (herein, "MAC"). It should be stressed that the piece of encrypted sensor data is not deleted; the MAC is generated alongside the piece of encrypted sensor data. Then in step S108O, the piece of encrypted sensor data and the MAC may be concatenated, to generate a message. The fate of such a message is discussed later on. In some cases, an authentication key may be applied to the sensor data before it is encrypted using the encryption key. This is described elsewhere in this application.

At this point, in step S3 of <FIG>, the encrypted sensor data is transmitted, by the transmitter <NUM> to the device <NUM> or <NUM>. Specifically, either the piece of encrypted sensor data may be transmitted, or the message generated as explained in the previous paragraph. In some cases, rather than transmitting the encrypted sensor data as soon as it is generated, the encryption module <NUM> may transmit the piece of encrypted sensor data to the buffer <NUM> for temporary storage. The transmitter <NUM> may then send all of the encrypted sensor data in the buffer <NUM> either when it exceeds a predetermined threshold volume. Alternatively, the transmitter <NUM> may be configured to send all of the encrypted sensor data in the buffer <NUM> at regular time intervals. Before discussing in more detail the steps which are performed by the device <NUM> or <NUM>, it is useful to consider in more detail the structure of the device.

Accordingly, much like <FIG>, <FIG> shows an alternative example of a device <NUM> which may form part of a system of the present invention or may perform a method of the present invention (e.g. steps S4, S5, S6, S7, S11, and S12). The fundamental structure of the device <NUM> of <FIG> is similar to the structure of the device <NUM> of <FIG>, but shows numerous optional features. Although the optional features of <FIG> are shown in a single drawing, it should be stressed that, by their very nature as optional features, it is not necessary for all of this features to be present in combination exactly as is shown in <FIG>. They are shown in a single device <NUM> for illustrative purposes, and it should be understood that any, some, or all of the features shown in the alternative device <NUM> of <FIG> may be excluded from the example without the resulting arrangement falling outside the scope of this disclosure.

Before discussing the components which make it up, it is important to consider what the device <NUM> actually is. In preferred cases, the device <NUM> is an edge device. In the context of the present invention, the term "edge device" should be understood to refer to a device which provides an entry point into a network of devices, the device having some processing capability of its own, in order to allow processing to take place non-centrally, thus improving the efficiency of the overall network. In some cases, the device may be a server. The device may also be an electronic control unit of a vehicle or other system, or a basic embedded system with a multipoint control unit (MCU) which uses one or more types of sensor data as an input.

The device <NUM> of <FIG> is connected via a connection C2 to a security platform <NUM>. The security platform <NUM> includes an authorization token generation module <NUM>, the function of which will be described later. Like e.g. the sensor <NUM>, the device <NUM> includes a secure environment, in this case a device secure environment (DSE) <NUM>. In the example shown in <FIG>, the DSE <NUM> includes: a processor <NUM> and a memory <NUM>. In addition, the DSE <NUM> may also include: a user interface module <NUM>, a sensor interface module <NUM>, and a security platform interface module <NUM>. Even though, the five aforementioned components are shown to be part of the DSE <NUM> in <FIG>, it must be appreciated that one or more, or all of the components could be located outside of the DSE <NUM>. The processor <NUM> may include one or more of: a decryption module <NUM>, an access request generation module <NUM>, and an authorization module <NUM>. The memory <NUM> may include a persistent memory <NUM> (having the same meaning as in <FIG>), which itself may store an authorization token <NUM> and encrypted sensor data <NUM>. The user interface module <NUM> may include a display <NUM> and a user input receiver <NUM>. The sensor interface module <NUM> may include a transmitter <NUM> and a receiver <NUM>. Finally, the security platform interface module <NUM> may also include a transmitter <NUM> and a receiver <NUM> (which may, optionally, be the same, respectively, and the transmitter <NUM>, and the receiver <NUM>). The operation of the various components of <FIG> will now be described in the context of the method shown in <FIG>, as well as the disclosure of optional features.

In step S4, the receiver <NUM> of the sensor interface module <NUM> receives the encrypted sensor data which was transmitted by the transmitter <NUM> of the sensor <NUM>. Thereupon, in step S5, the received encrypted sensor data <NUM> is stored in the persistent memory <NUM>.

At this point, it may be necessary for a user of the device <NUM> to access a subset of the data collected by the sensing element <NUM> of the data collection device <NUM> of the sensor <NUM>. The user is typically a maintenance user who needs to access a data of the sub-system (i.e. a sensor data stored in the device <NUM>). The user may connect to the device with e.g. a smartphone, a USB stick, a maintenance device or a device UI, provides their credential to get the authorization token to request the secret key to process the sensor data.

In order to do so, in step S6, the access request generation module <NUM> generates an access request. The data to which the user is permitted access is governed by the authorization token <NUM>, so before discussing the generation of the request by the access request generation module <NUM>, the nature of the authorization token <NUM> is described.

Broadly speaking, the authorization token <NUM> is an electronic token which is deployed in the persistent memory <NUM> of the memory <NUM> of the device <NUM>, which includes access control data defining one or more subsets of sensor data which the device <NUM> is permitted to access. As is illustrated in <FIG>, the authorization token <NUM> may be generated by an authorization token generation module <NUM> of a security platform <NUM>.

The authorization token <NUM> may define the subsets using e.g. a subset ID, or preferably in terms of the metadata associated with the subset. Specifically, the authorization token <NUM> may define one or more of the following:.

In addition to specifying metadata related to the collected sensor data, the authorization token <NUM> may also include other constraints. For example, in some cases, the authorization token <NUM> may define one or more validity conditions. Herein, a "validity condition" refers to a rule defining when the authorization token <NUM> may be valid, may be used, or may be effective. If the validity condition is not met, then the authorization token <NUM> is deemed invalid. The validity conditions may include one or more of the following:.

<NUM> This is not to be confused with the restriction on the time period over which the sensor data is recorded. The validity conditions are a property of the authorization token itself, and apply regardless of the nature of the sensor data in question.

The authorization token <NUM> may specify specific types of access to the data:.

Optional features of this process will now be explained, with reference to <FIG>. In step S6, an access request is generated. In some examples of the method, the access request includes an indication of a subset or subsets of encrypted sensor data. However, in other cases, the request does not include such an indication. In these latter cases, step S7 simply involves transmitting the request to access some data, and the authorization token <NUM> to the sensor <NUM>.

It is desirable, however, for the request to include some indication of the encrypted sensor data <NUM> stored in the memory <NUM> of the device which the device <NUM> wishes to access (i.e. decrypt). Before the access request is generated, the under input receiver <NUM> of the user interface module <NUM> may receive a user input from a user. The user input may be in the form of a request to access a specific subset of the data obtained by the sensor <NUM>. The request may include information identifying the subset of sensor data which the user wishes to access, for example, it may include the type of data, the time frame during which the data was collected, and/or the specific sensor or sensing element which collected the data. It will be recalled that when the data was first collected, a header containing metadata may have been appended thereto, the metadata including information about the specific piece of sensor data. In some cases, the request from the user may include metadata in the same form.

After the request for data has been received via the user interface module <NUM>, the access request generation module <NUM> generates a request based on what is received from the user. There are a number of ways in which this may take place, all having broadly the same result. Broadly, these may be divided into two categories: (i) cases in which the request identifies the subset ID, and (ii) cases in which the request does not identify the subset ID.

At this point, the access request generation module <NUM> has generated the request, the request optionally including an indication of the subsets of the encrypted sensor data <NUM> which it would like to be able to decrypt. The indication of the subsets may be in the form of metadata relating to the data, or in the form of a subset ID.

Then, in step S8, the transmitter <NUM> of the sensor interface module <NUM> sends the request and the authorization token <NUM> to the sensor <NUM>. At this point, we return to <FIG>, step S8, in which the receiver <NUM> of the device interface module <NUM> receives the request and the authorization token <NUM>.

Before determining, by the access determination module <NUM>, which sensor data the device <NUM> is permitted to access, the processor <NUM> or the sensor <NUM>, or the access determination module <NUM> may optionally first determine whether the validity condition is met, if the authorization token <NUM> includes one.

Then, in step S9, the processor <NUM> (specifically, the access determination module <NUM> thereof) determines, using the authorization token <NUM>, whether the device <NUM> is permitted to access the sensor data which it has requested. There are a handful of scenarios here: scenarios in which the request does not include an indication of the requested data, scenarios in which the request includes the metadata but not the subset ID, and scenarios in which the request includes the subset ID. These are discussed below.

Optionally, there may be an additional step wherein the processor <NUM> performs a lookup to identify the subset IDs corresponding to metadata in the request or the metadata which the device <NUM> has access to, and then performing the lookup of the encryption key data table <NUM> using the identified subset IDs as the input.

The above refers to scenarios in which the encryption/decryption keys are stored in the encryption key data table <NUM>. However, we have also discussed the possibility that the encryption and/or decryption keys may be generated based on the metadata and/or subset IDs, and locally-stored key generation data <NUM>. In these cases, if there is no data specified or indicated in the request, then the access determination module <NUM> may forward all of the metadata and/or subset IDs defined in the access control data of the authorization token <NUM> to the encryption module <NUM>, the key generation module <NUM>, or any other appropriate module of the processor <NUM> (not shown). There, the method may include a step of generating a decryption key for each piece of encrypted sensor data corresponding to the metadata and/or subset IDs defined by the access control data. The decryption key is generated deterministically, in the same way as the encryption key, as discussed earlier in the application.

The process for cases in which the request includes an indication of the requests metadata/subset IDs is analogous. It is first necessary to verify whether access is permitted by the device <NUM> to that data. Accordingly, the access determination module <NUM> validates the metadata or subset IDs in the request based on the access control data of the authorization token <NUM>. Specifically, the access determination module compares the metadata or subset IDs in the request with the metadata or subset IDs listed in the access control data. Then, as before:.

At this point, decryption keys corresponding to the pieces of encrypted sensor data <NUM> defined by the metadata or subset IDs have been generated or retrieved on the sensor <NUM>, e.g. by the key generation module <NUM>, the access determination module <NUM>, or any other suitable module on the processor <NUM>. In some cases, decryption keys corresponding to all of the pieces of encrypted sensor data <NUM> defined by the metadata or subset IDs to which the device <NUM> is permitted access, as defined by the access control data in the authorization token have been retrieved or generated. In other cases, decryption keys corresponding to all of the pieces of encrypted sensor data <NUM> defined by the metadata or subset IDs included in the request have been retrieved or generated. And, in other cases, decryption keys corresponding to all of the pieces of encrypted sensor data <NUM> defined by the metadata or subset IDs included in the request, and to which the device <NUM> is permitted access, as defined by the access control data in the authorization token have been retrieved or generated. Then, in step <NUM>, the transmitter <NUM> of the device interface module <NUM> of the sensor <NUM> transmits those decryption keys to the device <NUM>.

Returning to <FIG>, the receiver <NUM> of the sensor interface module <NUM> of the device <NUM> receives the transmitted keys, and the decryption module <NUM> of the processor <NUM> is then able to use the received decryption keys to decrypt the required data, for further processing, completing the method.

<FIG> shows a system <NUM>, which includes various components. As will be appreciated from the following description, system <NUM> represents an environment in which the present invention may be deployed. Specific use cases, with reference in particular to the types of sensor and operating parameters in question are also described below. The details of the method of the invention, which has been described in detail above in the foregoing description, and the various optional are not repeated here, but it should be understood that where compatible, any features previously described may be combined with any of the following features.

System <NUM> includes a plurality of sensors 1002a, 1002b, 1002c, 1002d, 1002e (though it will be appreciated that the container may include any number of sensors, including just a single sensor <NUM>). Each of the sensors <NUM> may be configured to perform the method of the first aspect of the invention. Each sensor <NUM>, may include a buffer memory in which sensor data is stored temporarily, e.g. a protection key generated and stored on the respective sensor <NUM>. Alternatively, as discussed previously, the sensor <NUM> may generate the keys on an ad hoc basis, and the keys may be used only to protect the generated sensor data, and not be stored on the sensor <NUM>. The sensors <NUM> may be as described previously in this application.

The system <NUM> also includes a plurality of devices 1006a, 1006b, 1006c. In the example shown in <FIG>, each of the devices <NUM> may correspond to a respective sensor <NUM>. However, this need not be the case. For example, it is envisaged that each of the sensors <NUM> could send their generated protected sensor data to a single device <NUM>. Alternatively, a single sensor <NUM> might send different kinds of protected sensor data to different devices <NUM>. In this example, the devices <NUM> may be in the form of monitoring stations on or near the system <NUM>, alternatively they may be terminal devices (accessible by a user), or control units. One example of each of these is shown in <FIG>, for illustrative purposes.

Each of the devices <NUM> may include a memory 1008a, 1008b, 1008c, (where the protected sensor data may be stored), and a respective processor 1010a, 1010b, 1010c. One use of the devices <NUM> is to allow a user to access the permitted data, e.g. for system maintenance, control or quality control purposes. A few examples (to reiterate, although these examples are disclosed here in combination with the specific example of system <NUM>, they may be applied generally to any implementation of the invention):.

Some specific use cases are described below.

In one scenario, the system <NUM> may in the form of a container (such as a shipping container) for transporting goods. For example, the container may be configured to transport foodstuffs over long distances. In this case, the container may include a refrigeration unit, the refrigeration unit may include a temperature sensor, and the operating parameter may be the temperature of a storage area of the refrigeration unit.

In this way, the system <NUM> is able to securely monitor the temperature of the refrigeration unit, and to adjust the temperature based on the temperature data which is received. In the container example, other sensors which may be included are other kinds of environmental sensors such as temperature sensors, humidity sensors, pressure sensors, door-status sensors, motion sensors, and the like. Users such as maintenance staff or engineers can thereby monitor the conditions in the container, without any risk that the sensor data has been tampered with, since only authorized personnel will be able to access the data, and it can be ensured that any tampering is detectable.

In an alternative case, the system <NUM> may be in the form of a vehicle, such as a car, a train, a plane, a bus, a helicopter, or any other vehicle. In preferred cases, the system <NUM> may be in the form of a "smart" vehicle. The invention could be particularly advantageous in two scenarios in a vehicle or a smart vehicle (having various types of sensors such as radar sensor, laser sensor, including 3D lidar sensor, or ultrasonic sensor):.

Similar to the smart vehicle use case, the present invention may also be applicable to industrial control systems, in both the monitoring and control contexts. In other words, the system <NUM> may be an industrial control system. The monitoring context, the system may work very similarly to the case for the smart vehicle. In the case of industrial control, the parameters which are measured by the sensors may be different. For example, they may be configured to measure environmental conditions, such as temperature, pressure, humidity/moisture level, pH, concentrations or partial pressures of certain substances. Additional conditions may include various electrical properties (e.g. current, voltage, power, electric field strength/flux density, magnetic field strength/flux density, charge, resistance, inductance, capacitance, conductivity/conductance, resistivity/resistance), thermal conductivity, and any other parameters which may give an indication as to the progress of an industrial process. In addition, it is also envisaged that "wear and tear" sensors also be employed, in order to monitor the health of industrial components. As before, a control unit may be configured to vary one or more operating parameters based on the sensor data.

Another scenario in which the present invention may be used is in a hospital.

While the invention has been described in conjunction with the exemplary embodiments described above, many equivalent modifications and variations will be apparent to those skilled in the art when given this disclosure. Accordingly, the exemplary embodiments of the invention set forth above are considered to be illustrative and not limiting. Various changes to the described embodiments may be made without departing from the scope of the invention.

Claim 1:
A method, performed by a sensor (<NUM>), of controlling access to sensor data, the method including the steps of:
generating (S1) sensor data, and protecting (S2) the sensor data to generate protected sensor data; and
transmitting (S3) the protected sensor data to a device (<NUM>) for storage;
characterized in that:
the method further comprises:
receiving (S4), from the device (<NUM>) an authorization token (<NUM>) including access control data defining one or more operations which the device is permitted to execute on the protected sensor data (<NUM>);
determining (S9), based on the access control data, an operation which the device (<NUM>) is permitted to execute on the protected sensor data (<NUM>);
providing (S10), to the device (<NUM>), one or more keys usable by the device to execute the operation on the protected sensor data (<NUM>).