Patent Application
20230336362
This disclosure relates to a module and a method for producing a data block. The disclosure further relates to a system comprising the module and a server, a computer program and a computer-readable storage medium.
In an IoT system, physical objects (or groups of such objects) are embedded with sensors, processing ability, software, and other technologies to connect and exchange data with other devices and servers over the Internet or other communications networks. With increased popularity of such systems, also security issues are increasingly imminent. The security issues, however, are not limited to IoT systems. Hence, there is an ongoing demand to solve the problem of ensuring authenticity and integrity of data generated by communication devices.
The above-mentioned problem is solved by the subject-matter of the attached independent claims. Further embodiments are disclosed in the attached dependent claims.
According to a first aspect of the disclosure, a module comprises at least one sensor, a processing unit, and a memory unit. The at least one sensor is configured to obtain sensor data. The processing unit is configured to obtain a hash value of a payload. The processing unit is further configured to generate a signature of the obtained hash value and the sensor data using a signature key stored in the memory unit. The processing unit is further configured to produce a data block comprising the obtained hash value, the sensor data, and the generated signature. The at least one sensor comprises a positioning sensor. The obtained sensor data comprises a positioning information regarding a position of the module where the processing unit obtained the hash value.
An advantage of the above module is that payloads, obtained or generated by a device comprising said module, may be made verifiable, i.e., it is verifiable that the payload existed at the device in combination with the sensor data obtained by the module and it is unchanged. So, the above module solves the problem of ensuring the authenticity and the integrity of a payload obtained or generated in field by coupling its hash value with the sensor data obtained by the module in order to certify that the payload was obtained or generated at a certain location.
The payload may be any payload of such device or of the module itself. In case the payload is a payload of the device, the hash value of the payload may be determined by the device and the module may receive, by a receiver, the hash value. In case the payload is a payload of the module itself, the module itself generates the hash value of its own payload. In both cases, the processing unit obtains the hash value of the payload.
It is further advantageous that, for verification of the existence of the payload at the device in combination with the sensor data obtained by the module, the payload itself does not have to be disclosed and, hence, can be kept secret, therewith allowing the protection of the payload data confidentiality and allowing the compliance with stricter data privacy rules.
Furthermore, by using sensor data obtained by the at least one sensor of the module itself, it can be assured that the sensor data is authentic, since it is not necessary to rely on external, and in general not trusted, sources of such sensor data.
Additionally, since the produced data block merely comprises a hash of the payload and not the payload itself, the data block may be conveniently stored, for example in public clouds or blockchains, without the risk of exposing the payload. In particular, separate storing of payloads and the data blocks is possible, which further increases security. Such data block may also be called a trust bundle.
By using the sensor data in the produced data block, an indexing of the data block in accordance with the sensor data is possible, such that improved search opportunities of a certain data block are achieved. Since the at least one sensor comprises a positioning sensor, indexing in accordance with positioning data may allow search for data blocks related to payloads that existed on a corresponding device or module at a certain location. For example, in case the at least one sensor further comprises a time sensor, indexing in accordance with time data may allow search for data blocks related to payloads that existed on a corresponding device or module at a certain time.
The positioning information may be any information determining a position or useful to determine a position (like raw measurements) of the module such as for example the information retrieved from GNSS constellations, 3GPP mobile communication networks, WiFi access points, Bluetooth beacons, etc. The positioning information may include accuracy and/or integrity related data.
A payload in this application may be any digital information, obtained and/or generated by a device comprising the module or obtained and/or generated by the module itself.
With the above, a module is presented, with which a zero knowledge proof scheme of ownership of a payload could be achieved, wherein the payload itself does not need to be disclosed. For instance, the verifier, having access to a produced data block, can provide to the prover the hash value and the sensor data contained in it. With this info, the prover, having access to the signature key, is able to generate exactly the same signature of the original produced data block and deliver it to the verifier for the verification, demonstrating this way the ownership without disclosing the payload content. Proof of integrity is also possible in that the owner of a corresponding device with such module can demonstrate that the payload existed in accordance with the obtained sensor data, and that the payload is unchanged.
According to at least one embodiment, the at least one sensor further comprises additionally at least one of the following:
The time information may be, for example, a timestamp. The time sensor may be, for example, an internal clock tracking for example a Coordinated Universal Time, UTC, in the module, or may be a sensor which obtains time information from a system time, such as, for example, from a mobile communication network based on 3GPP standards or from a GNSS constellation like GPS, BeiDou, GALILEO, GLONASS, etc. The time information may include accuracy and/or integrity related data and/or time metadata, in case the time sensor comprises a Temperature Compensated Crystal Oscillator, TCXO, comprising information regarding the crystal oscillator type and model, and/or the measured temperature when the time has been determined.
The environmental information may be any information relating to the environment in which the module operates. The environmental information may be, for example, a temperature, information obtained from a light sensor, a humidity, a pressure, a UV value, information relating to noise, rain, vibration, a VOC (Volatile Organic Compound) value, a geomagnetic or gravimetric value, etc.
In particular, also combination of the above mentioned sensors may be used in the module. Hence, the module may comprise, for example, a time sensor and a positioning sensor, or a positioning sensor and an environmental sensor, or any other combination of the above, also of more than two sensors.
An advantage of the specific sensors is that existence of the payload may be verified in each case in correlation with the specific obtained information. For example, it can be verified that the payload existed on a device at a certain time, a certain location, a certain temperature, etc. Additional security, integrity, and usability - for example due to the possibility to search for data blocks according to a time, a position, a temperature, etc. - is provided.
According to at least one advantageous embodiment, the positioning information comprises at least one of the following:
For example, in case the positioning information comprises raw data, from which positioning coordinates are derivable, the raw data may be GNSS raw measurement and/or an identification of e.g. a 3GPP mobile network cell, in which the module is located, and/or an identification of e.g. a WiFi access point or a Bluetooth beacon, whose signals are available where the module is located, and/or a direction of received signals from known sources and/or the strength and/or quality of the received signals. From the raw data, the position of the module may be derivable with a certain level of accuracy, quality and/or integrity. The 2-dimensional or 3-dimensional positioning coordinates may include accuracy and/or integrity related information.
According to at least one embodiment, the positioning information comprises information related to a source of the positioning information and/or a type of raw data of the positioning information from which a position of the module is obtained.
If the positioning sensor is not capable of determining the position of the module or it is not configured to do that in order to save energy on a battery-operated device, it may collect positioning raw measurements and enriches them with metadata like the source of the measurements, their type, the configuration parameters at which they are sampled and so on, to allow the module position determination by a server receiving those raw measurements.
According to at least one embodiment, the module further comprises a transmitter, wherein the transmitter is configured to transmit the produced data block.
An advantage thereof is that the data block may be transmitted to, for example, a server or a cloud service, where the data block may be stored and/or verified. In that the module itself comprises the transmitter, via which the data block is transmitted, a high security level is achieved as the module can control all the communication details.
According to at least one embodiment, the produced data block further comprises an identifier of the module.
In case the produced data block also comprises such identifier of the module, also the signature generated using the signature key stored in the memory unit is preferably determined based on the obtained hash value, the obtained sensor data and the identifier of the module.
An advantage thereof is that security is further improved in that it can be verified that a certain data block is from a certain module. Furthermore, searchability for data blocks from a certain module is provided. Moreover, the identifier of the module provides an efficient possibility to retrieve a verification key to be used to verify the data block signature.
The produced data block may further also comprise information such as a version of the data block format, a firmware and/or hardware version of the module, etc.
In all above embodiments, the module may be, for example, a positioning module, for example a Global Navigation Satellite System, GNSS, module and/or a communication module, for example a module according to a 3GPP standard or an IEEE standard, for example using LTE, 5G, 6G, or WiFi or Bluethooth.
According to a second aspect of the disclosure, a method for producing a data block comprises:
wherein the obtaining, by at least one sensor of the module, sensor data comprises obtaining, by a positioning sensor, sensor data comprising a positioning information regarding a position of the module where the processing unit of the module obtained the hash value.
Advantages and embodiments of the second aspect correspond, in general, to those of the first aspect and vice versa.
According to at least one embodiment, the method further comprises transmitting, by a transmitter of the module, the produced data block to a server, wherein the server certifies the coupling of the obtained hash value of the payload and the sensor data obtained by the at least one sensor by verifying the data block signature with a verification key corresponding to the signature key used by the module.
According to at least one embodiment, the signature key is provided to the module by a trusted entity and/or at a time of production of the module.
If the module comprises a Root of Trust (RoT), an advantage hereof is that the RoT can store securely and protect the usage of the signature key, according to which a high security and integrity of the produced data block is ensured.
According to at least one embodiment, a verification key corresponding to the signature key used by the module is provided to the server by a trusted entity and/or at a time of production of the module.
This way, the high security and integrity of the produced data block is ensured also on the server side, for the verification of the data block.
According to a third aspect, a system comprises a module according to the first aspect and a server. The module is configured to transmit the produced data block to the server. The server is configured to receive the data block from the module. The server is further configured to determine the coupling of the hash value of the payload obtained by the module and the sensor data obtained by the at least one sensor of the module by verifying the data block signature with a verification key corresponding to the signature key used by the module.
The determining of the coupling of the hash value of the payload and the sensor data in this context describes the determining of whether said hash value was indeed obtained in correspondence with the obtained sensor data, i.e., that the hash value is coupled to the sensor data.
Herein, it is advantageous that the server may perform verification of the existence of the payload, and hence provide a trusted verification result.
Further advantages and embodiments of the third aspect correspond to the first and second aspect, and vice versa.
According to a fourth aspect, a computer program comprises instructions which, when executed by at least one processor, performs the method according to the second aspect.
According to a fifth aspect, a computer-readable storage medium comprises the computer program according to the fourth aspect.
Further advantages and embodiments of the fourth and fifth aspect correspond to the first, second and third aspect, and vice versa.
In all of the above aspects, a payload describes any data which may be generated or obtained and processed by a device, which, for example, comprises or is connected to the module according to the first aspect, or by the module itself. For example in case such device is an image generating device, the payload may be one or more images generated by the device. For example such device is an information forwarding device, the payload may be information data, obtained and forwarded by the device, etc.
In the drawings:
The module 10 further comprises an environmental sensor 17, which is configured to obtain an environmental information such as, for example, a temperature, an illuminance, a humidity, a pressure, a UV value, information relating to noise, rain, vibration, a VOC (Volatile Organic Compound) value, a geomagnetic or gravimetric value, etc.
The positioning sensor 12, the time sensor 11, and the environmental sensor 17 are, in this exemplary embodiment, arranged in a sensor unit 18. Alternatively, the sensors 11, 12, 17 may be arranged as separate individual sensors, or as separate sensors in separate sensor units, or any combination thereof.
The module 10 further comprises a receiver 13 and a transmitter 14. The receiver 13 is configured to receive a hash value of a payload, which is to be made verifiable for integrity reasons, i.e. lodged to be verified that the corresponding payload existed at a certain time at a certain location. The hash value may be received, e.g. from a microcontroller unit (MCU) of a device in which the module is arranged. This is described in more detail with reference to
The module 10 further comprises a memory unit 15, in which a signature key is stored. The signature key may either be for symmetric cryptography to provide a message authentication code, like with Hash-based Message Authentication Code (HMAC), or for asymmetric cryptography to provide a digital signature, like with Elliptic Curve Digital Signature Algorithm (ECDSA). Additionally, in the memory unit 15, an identifier of the module 10 is stored. The signature key and the identifier of the module 10 can be provided to the module 10 for example in a secure environment during production of the module 10 and they can be protected by a Root of Trust 19 (RoT). The RoT 19, in fact, for example can allow the storage of the signature key in the memory unit 15 in encrypted form and allow its utilization for the signature of data provided as input without never disclosing it in plain text. In alternative, the memory unit 15 can be a subunit of the RoT 19, this way the access to any content stored in the memory unit 15 can be protected by the RoT 19. The module 10 therefore can be a secure module.
Furthermore, the module 10 comprises the processing unit 16, which may be, for example, a common processor, microcontroller, etc. The processing unit 16 is configured to generate a signature of the received hash value and the obtained sensor data using the signature key stored in the memory unit 15, and produce a data block comprising the received hash value, the obtained sensor data, and the generated signature.
The transmitter 14 is configured to transmit the data block, for example to a server. To do so, the module 10 may have a type of transmitter 14, which is directly capable of communicating with such server. This is the case, for example, if the module is a communication and positioning module, which provides communication and positioning capabilities. Alternatively, the module 10 may transmit the data block indirectly to the server, e.g. by providing the data block to an MCU of a device in which the module 10 is arranged, which then sends the data block to the server. This may be the case, for example, in case the module is a positioning module.
The module 10 described herein may be, for example, a positioning module or a combined positioning and communication module. The module may be implemented as an integrated circuit (IC) or may be implemented as a printed circuit board (PCB), on which a corresponding IC is mounted.
In particular in IoT devices, payloads are continuously generated in a high volume. For security reasons, it may be advantageous to verify, however, whether a payload, which allegedly existed on a certain IoT device, really existed as claimed. The IoT device described herein allows an owner of the IoT device to prove, without disclosing the payload itself, that the payload existed on the IoT device and has not been tempered with.
The IoT device 20 comprises number keys 21 and a display 22, for example to display payment particulars and enter a payment PIN, etc.
The IoT device 20 is configured to process payment transactions, for example by obtaining particulars such as an amount of money which is to be paid, credit card information from which the money is to be deposited, PIN information authorizing the payment transaction, etc. The entire processing of one payment transaction, in this case, is a payload of the IoT device 20.
The IoT device 20 comprises a microcontroller unit (MCU) 23, which is also known as a host of IoT device 20. The MCU 23 is processing the payload of the IoT device 20. The MCU 23 is further configured to generate a hash value of the payload.
The IoT device 20 further comprises a module 10, which is configured to obtain sensor data, obtain a hash value of the payment payload from the MCU 23, generate a signature of the received hash value and the obtained sensor data using a signature key, and produce a data block comprising the received hash value, the obtained sensor data, and the signature.
For example, the sensor data comprises a time and positioning information of when and where the payment transaction was processed by the payment IoT device 20 and the sensor data further comprises a temperature information of an environment of where the payment transaction was processed by the IoT device 20 at the time it was processed. Then it is possible, in case verification of the payment transaction is needed, to verify, that the hash value corresponding to the performed transaction was received by the module 10 at that time and location and temperature lodged in the data block.
Assuming that the hash value of the payload is obtained by the module 10 immediately or shortly after (e.g., not more than a few seconds, in particular time used for processing) the payload is processed on the IoT device 20, it can be verified that the payload existed on the IoT device 20 at such corresponding time and position of the IoT device 20.
The module 10 of the IoT device 20 may be, for example, the module 10 described with reference to
The frame structure 30 may be, for example, a frame structure of the data block produced by the modules 10 discussed in
A first field 31, may comprise a fixed size hash value of a payload.
In a second field 32, a trusted UTC time at which the hash value was obtained by the module may be comprised. The UTC time is trusted in that it is obtained by a trusted entity, for example by the module itself. Additional information like the accuracy and/or integrity and/or time metadata may also be included.
In a third field 33, trusted 3-dimensional position data (latitude, longitude, and altitude) of a position where the device producing the data block was located when the hash value was obtained may be comprised. The position is trusted in that it is obtained by a trusted entity, i.e., by the module itself. In alternative, trusted 2-dimensional position data (latitude, longitude) may be comprised. In yet another alternative, raw measurements data useful to determine a position may be comprised. Additional information like the accuracy and/or integrity and/or metadata about raw measurements (like source of information and type of raw data) may also be included.
In a fourth field 34, optionally, an identifier of a module, which produced the data block, whose frame structure is shown here, is comprised. In the fourth field 34 or in further fields not discussed in detail herein, also a version of the frame format may be comprised, a module firmware and/or hardware version may be comprised, and if required, additional parameters to help the processing depending on a frame format version may be included.
In a fifth field 35, a signature of the above fields 31, 32, 33, 34 is comprised. The signature is calculated using a signature key stored in a memory unit and/or protected by a RoT.
Further fields may be included in the frame structure of the data block, for example comprising further sensor data, or other information.
With said frame structure of a data block, verification, with a high level of security and integrity, that a payload corresponding to the hash value contained in said data block existed in combination with the sensor data obtained by the at least one sensor of the module, is made possible to everyone having access to the verification key corresponding to the signature key used by the module.
An advantage of said frame structure is that its size is independent by the size of the original payload and it can be constant. The constant size of the frame and the availability of the identifier of the module allow efficient interoperability for the frame structure with existing systems and efficient processing of the data block. In fact, the second, third, fourth and fifth fields can be of fixed size and the first field stores only a hash of the payload, so a fixed size payload digest. In case for instance cryptographic hash functions are used, like SHA-2 or SHA-3, the payload digest size is also quite small as it can be 224 or 256 or 384 or 512 bits.
In a step S1, a module 10, for example a module 10 corresponding to the modules 10 described with reference to
In a step S2, the module obtains, by at least one sensor of the module 10, sensor data. In particular, the module obtains, by at least one positioning sensor, positioning information regarding a position of the module where the processing unit obtained the hash value of the payload.
In a step S3, the module generates, by a processing unit, a signature of the received hash value and the obtained sensor data using a signature key stored in a memory unit of the module and/or protected by a RoT of the module. The determining of the signature may be done, with the signature key, using symmetric cryptography to produce a message authentication code, like with HMAC, or using asymmetric cryptography to produce a digital signature, like with ECDSA.
In a step S4, the module produces, by the processing unit, a data block comprising at least the received hash value, the obtained sensor data, and the signature.
For producing the data block, for example, the hash value of the payload, wherein the hash value may have a fixed size, may be added to a first field of a frame structure of the data block. The sensor data obtained by the at least one sensor may be added to further respective field of a frame structure of the data block. For example, the sensor data obtained by different sensors may be added to respective such fields of the frame structure.
In case, for example, the at least one sensor comprises a time sensor and a positioning sensor, time information obtained by the time sensor may be added to one second field and positioning information obtained by the positioning sensor may be added to a third field. The hash value and the sensor data may be added to the respective fields in plain text form.
The signature, determined in step S3 may, for example, be added to a respective field of the frame structure of the data block.
In a step S5, the module transmits, either directly or via an MCU of a device in which the module is arranged, the produced data block to a server 40 and the server receives the data block. The server may be, for example, a server with a high level of security, for example located in a safe environment and administered by a trusted provider that has been provisioned with the verification keys corresponding to the signature keys used by the modules. Such trusted provider may be, for example, a provider of verification procedures of payloads on devices. The trusted provider may be, for example, a manufacturer of the modules described herein.
In a step S6, the server verifies the signature comprised in the data block with a verification key corresponding to the signature key used by the module. By verifying the signature, it can be determined that the payload, whose hash value is comprised in the data block and based on which, among others, the signature is determined, existed in unchanged form. In case the payload would have been tempered with after producing the data block, such modification could be detected due to a mismatch of the hash value thereof. Additionally, it can be determined that payload existed in correspondence with the sensor data. For example, in case the sensor data comprises time and positioning information, it can be determined that the hash of the payload was obtained by the module at a certain time while the module was located at a certain position.
10
11
12
13
14
15
16
17
18
19
20
21
22
23
30
31
32
33
34
35
40
400
| Number | Date | Country | Kind |
|---|---|---|---|
| 22168237.0 | Apr 2022 | EP | regional |
