Patent Application
20250005202
The present disclosure relates to a storage device. Furthermore, the present disclosure relates to a corresponding method of operating a storage device.
A storage device may contain one or more special function registers for temporarily storing control data or configuration data. Such a storage device may for example be integrated into an interface unit, which is interposed between a bus and a peripheral device. In that case, the control data or configuration data may be provided to the peripheral device through the special function registers. However, these special function registers may be vulnerable to fault injection attacks.
In accordance with a first aspect of the present disclosure, a storage device is provided, comprising: one or more special function registers; a preloading stage comprising a first preload register, wherein the preloading stage is configured to preload data in the first preload register before loading the preloaded data into the special function registers; wherein the preloading stage is further configured to perform a verification of the integrity of the preloaded data before loading said preloaded data into the special function registers.
In one or more embodiments, the preloading stage further comprises a second preload register, and the preloading stage is configured to perform the verification by calculating a checksum on the preloaded data and comparing said checksum with a reference checksum stored in the second preload register.
In one or more embodiments, the preloading stage further comprises a third preload register, and the preloading stage is configured to perform the verification by calculating a combined checksum on the preloaded data and on an address preloaded in the third preload register, and comparing the combined checksum with the reference checksum stored in the second preload register.
In one or more embodiments, the address is an address of a specific one of the special function registers, and the preloading stage is configured to load the preloaded data into said specific one of the special function registers if the combined checksum matches the reference checksum.
In one or more embodiments, the preloading stage is further configured to discard the preloaded data if the address stored in the third preload register does not match any of the addresses of the special function registers.
In one or more embodiments, the preloading stage is configured to discard the preloaded data by loading the preloaded data into a null register or by flushing the preload registers.
In one or more embodiments, the reference checksum is a pre-calculated checksum.
In one or more embodiments, the pre-calculated checksum is based on an error detection code, in particular a cyclic redundancy check, or on an XOR-based longitudinal parity check.
In one or more embodiments, the reference checksum has been pre-calculated by software or firmware.
In one or more embodiments, the preloading stage is further configured to generate an error message upon or after an unsuccessful verification of the integrity of the preloaded data.
In one or more embodiments, the storage device further comprises a default secure destination, wherein said default secure destination is an unassigned address.
In one or more embodiments, an interface unit comprises a storage device of the kind set forth.
In accordance with a second aspect of the present disclosure, a method of operating a storage device is conceived, wherein: a preloading stage comprised in the storage device preloads data in a first preload register before loading the preloaded data into one or more special function registers comprised in the storage device; the preloading stage performs a verification of the integrity of the preloaded data before loading said preloaded data into the special function registers.
In one or more embodiments, the method further comprises storing a reference checksum in a second preload register comprised in the preloading stage, wherein the preloading stage performs the verification by calculating a checksum on the preloaded data and comparing said checksum with the reference checksum stored in the second preload register.
In one or more embodiments, the method further comprises storing an address of said data in a third preload register comprised in the preloading stage, and the preloading stage performs the verification by calculating a first checksum on the preloaded data, calculating a second checksum on the address stored in the third preload register, combining the first checksum and the second checksum, and comparing the combined checksum with the reference checksum stored in the second preload register.
Embodiments will be described in more detail with reference to the appended drawings.
As mentioned above, a storage device may contain one or more special function registers for temporarily storing control data or configuration data. Such a storage device may for example be integrated into an interface unit, which is interposed between a bus and a peripheral device. In that case, the control data or configuration data may be provided to the peripheral device through the special function registers. However, these special function registers may be vulnerable to fault injection attacks. Unlike secure elements, which may be able to counter the fault injection attacks by applying an end-to-end integrity concept, most peripherals do not have enough resources for applying such a concept. In other words, for most peripherals applying an end-to-end integrity concept is too power consuming and costly in area. However, protection against fault injection attacks may be desirable for a very reduced set of highly sensitive security configurations. For those cases, the options are very limited since traditionally security has been applied in an all-or-nothing approach.
Now discussed are a storage device and a corresponding method of operating a storage device, which facilitate countering fault injection attacks. The storage device and corresponding operating method may be used to advantage in an interface unit of the kind set forth above.
In one or more embodiments, the preloading stage further comprises a second preload register, and the preloading stage is configured to perform the verification by calculating a checksum on the preloaded data and comparing said checksum with a reference checksum stored in the second preload register. In this way, the verification of the integrity of the preloaded data is facilitated. In one or more embodiments, the preloading stage further comprises a third preload register, and the preloading stage is configured to perform the verification by calculating a combined checksum on the preloaded data and on an address preloaded in the third preload register, and comparing the combined checksum with the reference checksum stored in the second preload register. By verifying both the data and the address of the special function register into which the data will be loaded, the resilience against fault injection attacks may be further increased.
In one or more embodiments, the address is an address of a specific one of the special function registers, and the preloading stage is configured to load the preloaded data into said specific one of the special function registers if the combined checksum matches the reference checksum. This results in a practical implementation of verifying the integrity of the data and the address of the special function register into which said data should be loaded. In one or more embodiments, the preloading stage is further configured to discard the preloaded data if the address stored in the third preload register does not match any of the addresses of the special function registers. In this way, the resilience against fault injection attacks may be further increased. In a practical implementation, the preloading stage may be configured to discard the preloaded data by loading the preloaded data into a null register or by flushing the preload registers.
In one or more embodiments, the reference checksum is a pre-calculated checksum. In this way, the reference checksum may easily be generated. Furthermore, in one or more embodiments, the pre-calculated checksum is based on an error detection code (EDC) or an XOR-based longitudinal parity check. More specifically, the EDC may be a cyclic redundancy check (CRC). These are types of checksums which are particularly suitable for verifying the integrity of the preloaded data. However, the skilled person will appreciate that these types merely represent examples, and that other types of checksums may also be used. Furthermore, in a practical implementation, the reference checksum has been pre-calculated by software or firmware. In one or more embodiments, the preloading stage is further configured to generate an error message upon or after an unsuccessful verification of the integrity of the preloaded data. In this way, the system may be triggered to react to a likely fault injection attack in an appropriate manner.
The presently disclosed storage device and corresponding operating method facilitate implementing a virtual end-to-end integrity concept, using a mix of software and hardware. By means of multiple accesses to a set of registers indicating destination (e.g., address), contents, and integrity information, the presently disclosed mechanism may ensure that multiple accesses must be successfully attacked for an attacker to inject any fault into the protected special function registers. Otherwise stated, the attacker should not just apply the right timing for the attack once, but also multiple times to different information types (address, contents, integrity) and with timings subject to software modification, with different characteristics each time. This increases exponentially the difficulty of the attack at a negligible software cost and as a consequence significantly reduces the likelihood of the attacker's success.
The virtual end-to-end integrity concept may offer a secure and reliable mechanism to bring the integrity protection benefit of highly secure products to a selected subset of special function registers at a negligible cost, compared to the traditional end-to-end integrity concept. Moreover, it increases exponentially the difficulty for the attacker and therefore diminishes exponentially their rate of success. In addition, since the integrity verification is performed before the data is loaded into the special function registers, it removes the vulnerability that for a few clock cycles a destination register (i.e., a special function register) may contain faulty data before the system starts responding.
More specifically, the virtual end-to-end integrity concept may be based on a system that comprises a control, a set of pre-loading stage registers containing the data and its destination, and an integrity protection (e.g., based on error detecting codes) covering the data and optionally its destination (i.e., the address of the data). Once all the pre-loading registers have been loaded and their integrity has been confirmed, the control may ensure the transfer of the preloaded data to integrity-protected special function registers. It is noted that, in addition to the integrity verification performed on the preloaded data, a further integrity verification may be performed on the data loaded into the special function registers. Furthermore, it is noted that the default secure destination may be an unassigned address (i.e., null, for example 0xFFFF_FFFF). The control may be fully hardware automated, in that the hardware may trigger the loading of the data into the special function registers once the data has been preloaded and their integrity has been confirmed. Alternatively, the control may be implemented by a software access to a dedicated preload register CTRL. Furthermore, once the preload registers have been copied to the destination registers, they may be left in a reactive state. Furthermore, the preload registers may be flushed or overwritten, and subsequently the next secure load may be initiated.
It is noted that the embodiments above have been described with reference to different subject-matters. In particular, some embodiments may have been described with reference to method-type claims whereas other embodiments may have been described with reference to apparatus-type claims. However, a person skilled in the art will gather from the above that, unless otherwise indicated, in addition to any combination of features belonging to one type of subject-matter also any combination of features relating to different subject-matters, in particular a combination of features of the method-type claims and features of the apparatus-type claims, is considered to be disclosed with this document.
Furthermore, it is noted that the drawings are schematic. In different drawings, similar or identical elements are provided with the same reference signs. Furthermore, it is noted that in an effort to provide a concise description of the illustrative embodiments, implementation details which fall into the customary practice of the skilled person may not have been described. It should be appreciated that in the development of any such implementation, as in any engineering or design project, numerous implementation-specific decisions must be made in order to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another.
Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill.
Finally, it is noted that the skilled person will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference sign placed between parentheses shall not be construed as limiting the claim. The word “comprise(s)” or “comprising” does not exclude the presence of elements or steps other than those listed in a claim. The word “a” or “an” preceding an element does not exclude the presence of a plurality of such elements. Measures recited in the claims may be implemented by means of hardware comprising several distinct elements and/or by means of a suitably programmed processor. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202341043853 | Jun 2023 | IN | national |
