CA2900137A1 - Tamper-evident data store method and system, and device configured - Google Patents

Abstract

Described are various embodiments of a tamper-evident data storage method and system, and device configured therefor. In some embodiments, tamper-evident data storage is enabled as part of a device. In general, these devices will each comprise a hardware hasher or the like, operatively configured to compute and supply a hash value to their respective data storage interface via an independent path distinct from the device's one or more software-accessible paths, where it may be combined with data storage access operations to provide indication of possible code tampering. In some embodiments, such hash values may further or alternatively be used for the encryption/decryption of stored data.

Description

TAMPER-EVIDENT DATA STORE METHOD AND SYSTEM, AND DEVICE CONFIGURED
THEREFOR
FIELD OF THE DISCLOSURE
[0001] This patent application relates to data processing systems, and in particular, to a method and apparatus for being able to read and write data in a storage medium only while the software on the system has not been tampered.
BACKGROUND

[0002] Both the increased amount of data available, and the increased requirements for security of the data, necessitate the prevention of data access by unauthorized parties. In present software, while the actual code may go to ever increasing lengths to prevent access by unauthorized parties to critical data, when the system is compromised the attacker is able to gain access to the data. This is the case because while the uncompromised software may go to great lengths to hide access to the data, such as hiding the decryption keys, once an attacker gains control of the system they are able to extract those keys from the system. Once the attacker has the keys, they can write code that dumps the data from the once-secure storage locations to a location of the attacker's choosing. At that point, the once-secure data is now visible to the attacker.
An attacker may also choose to modify the data. In this case, the attacker would locate both the encrypt and decrypt keys (if they aren't the same), decrypt the data, modify it, and then encrypt it and place it back in the secure storage area. After the attack, the attacker can RKIPO1C Page 1 of restore the system software to its original uncompromised state, leaving the system in its original state with leaked and / or compromised data.

[0003] The fundamental problem is that anything that the software can do in order to protect the data can be observed by the attacker, and then subverted to suite the attacker's purposes. For example, common techniques include software reverse engineering, replay attacks, simulation, and emulation.

[0004] In software reverse engineering, the software is extracted from the target machine, and disassembled. This is aided by both common off-the-shelf modern software reverse engineering tools such as Ida Pro, Oily Debug, and by custom tools that the attacker may possess. The disassembly of the program tells the attacker exactly what the program is doing, and how it does it, in machine language. Higher level tools, that take the machine language output and "uncompile" it into high-level languages, are also known.
These allow the attacker to understand the function of the program at a higher level, which generally cuts down on the time required for such understanding. Once the attacker understands the operation of the program, they can proceed to follow its operation and eventually find where the keys are stored for encrypting and/or decrypting data in the secure storage area. Once the keys are found, the attacker can access the data as they see fit.

[0005] In a replay attack, the attacker simply observes the operation of the software using a debugger, and is able to stop execution when an event of significance occurs.

Page 2 of 13 Such an event might be, for example, a call to a function to decrypt a block of data. In this case, the attacker has everything they need to either watch the decryption operation occur (and thus extract the keys, and/or the clear text version of the data), or substitute in their own data to be decrypted and wait for the decryption function to perform the operation.
The attacker may instead, or in addition, choose the encryption function with the same goal and general steps.

[0006] In simulation and emulation, the attacker can construct an execution platform that allows the software that they have extracted from the target to run in an environment that the attacker controls. The attacker can instrument the environment to present arbitrary data to the program (for example, in order to subvert the program into encrypting or decrypting arbitrary data), or to cause the program to perform abnormal actions when certain conditions are reached (for example, stopping execution of the program when the first data element of the secure storage is read), etc.

[0007] This background information is provided to reveal information believed by the applicant to be of possible relevance. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art.
SUMMARY

[0008] The following presents a simplified summary of the general inventive concept(s) described herein to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is not intended to restrict key or critical elements of the invention or to delineate the scope of the invention beyond that Page 3 of 13 which is explicitly or implicitly described by the following description and claims.

[0009] A need exists for a tamper-evident data store method and system, and device configured therefor, that overcomes some of the drawbacks of known techniques, or at least, provides a useful alternative thereto. Some aspects of this disclosure provide examples of such methods, systems and devices.

[0010] In accordance with one aspect, there is provided a data storage interface device reading and writing data stored on a data storage medium, the device comprising: a data storage interface to read and write the data; a memory having software code stored thereon; a processor to operatively interface with said memory in executing said software code to at least partially operate the device; and a hardware hasher to operatively interface with said code storage device to compute a hash value over at least a designated area thereof and supply said hash value to said data storage interface via an independent path distinct from any software accessible path so as to be used to encrypt at least some of the said data being written to said storage medium and decrypt at least some of the said data being read from said storage medium.

[0011] In accordance with one embodiment, said decryption operation includes a decryption success indicator such that unsuccessfully decrypted data causes said success indicator to become activated.

[0012] In accordance with one embodiment, said additional data is supplied to said RKIPO1C Page 4 of 13 hardware hasher in computing said hash value.

[0013] In accordance with one embodiment, said additional data is at least one of supplied by and accessible to executed code.

[0014] In accordance with one embodiment, said hardware hasher periodically computes said hash value during operation so as to signal possible code tampering upon identification of a change in said periodically computed hash value.

[0015] In accordance with one aspect there is provided a method for reading and writing tamper-evident data stored on a data storage device, the method comprising:
executing software code stored on the device to at least partially operate the device;
computing a computed hash value over at least a portion of said code via a hardware hasher; supplying said computed hash value to a data storage interface via an independent path distinct from any software accessible path; and encrypting at least some of the said data being written to said storage medium and decrypting at least some of the said data being read from said storage medium.

[0016] In accordance with one embodiment, said decryption operation includes a decryption success indicator such that unsuccessfully decrypted data causes said success indicator to provide evidence of tampering.

[0017] In accordance with one embodiment, said computing comprises computing said RKIPO1C Page 5 of 13 computed hash value as a function of additional data available to said hardware hasher.

[0018] In accordance with one embodiment, said additional data is at least one of supplied by and accessible to said executed software code.

[0019] In accordance with one embodiment, said computing comprises periodically computing said hash value.

[0020] In accordance with one embodiment, said computing comprises periodically computing said hash value such that a detected change in said periodically computed hash value provides evidence of tampering.
BRIEF DESCRIPTION OF THE DRAWINGS

[0021] One or more embodiments of the foregoing will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0022] Figure 1 is a schematic view of one example embodiment of a data processing system, depicting a computer with a secure storage area;

[0023] Figure 2 is the same as Figure 1 except includes an additional data element combined with the firmware being hashed; and

[0024] Figure 3 is the same as Figure 2 except that it includes multiple zones of secure storage.
DETAILED DESCRIPTION
RKIPO1C Page 6 of 13

[0025] Generally, the following description is directed toward the provision of tamper-evident data storage devices. In general, these devices will each comprise a hardware hasher or the like, operatively configured to compute and supply a hash value to their respective data storage interface via a dedicated and independent path distinct from the device's standard software-accessible paths, where it may be combined with data written to the storage medium, or again evaluated against data read from the storage medium to verify an authenticity of the software load present on the device.

[0026] Turning to Figure 1, in the present disclosure, a system 300 is described in which a Central Processing Unit (CPU, or processor) 10, executes instructions stored in a firmware module 20. The CPU 10 accesses the instructions to execute by setting the address of the instruction to fetch on the address bus 50 and issuing a hardware read request. The firmware module 20 responds with the content of the firmware at the requested location and presents the data on the data bus 60. The CPU 10 reads the data from the data bus 60 and executes the instruction. In this manner, the CPU 10 is able to execute all instructions in its program. In a similar manner, the CPU 10 is also able to read other non-instruction data from the firmware 20. Writing data is accomplished in a similar manner, and is known in the art.

[0027] When accessing the secure data storage area 21, the CPU 10 proceeds as follows. The CPU 10 sets the address of the location within the secure data area 21 on the address bus 50 that the CPU 10 wishes to access, and issues a hardware read or write request (depending on if the CPU 10 is reading or writing data). The hardware read or RKIPO1C Page 7 of 13 write request causes the encrypt / decrypt engine 22 to cause encrypted data to be read from the secure data store 21 or written to the data store 21, as appropriate to the operation. The encrypt / decrypt engine 22 relies on the key generated from the optional converter 200 in order to encrypt or decrypt the data. Generation of this key is described shortly.

[0028]
Both before the CPU 10 starts normal operation, and periodically in conjunction with the normal operation of the CPU 10, a hardware hasher 30 computes a hash 100 of all or a selected portion of the firmware 20, by reading the data from the firmware 20 in the same manner that the CPU 10 does during normal operation; that is, the hasher 30 emits sequential addresses on the address bus 50 and reads the resulting content from the data bus 60. When performing this operation in conjunction with the normal operation of the CPU 10, the hardware hasher 30 can use bus-sharing techniques as are commonly known in the art (e.g., by stealing bus cycles from the CPU 30). The address range used by the hasher 30 is relevant to the present disclosure only insofar as it must be of sufficient range to provide assurance of the software's untampered state (that is to say, selecting only address ranges that are relevant to the operation of the software). The hasher computes a hash of the resulting data in a manner known to those skilled in the art (for example, the hasher 30 may be an embodiment of a cryptographically secure hasher, such as that described in US patent #7,489,779 "Hardware implementation of the secure hash standard" by Scheuermann). It is understood that while the specific hashing algorithm selected is not relevant to the present disclosure, it will be appreciated by a person having ordinary skill in the art that the ability for the attacker to tamper the software will be a direct Page 8 of 13 function of the security of the hash algorithm (that is to say, a "weak" hash, such as a CRC32, allows the attacker to construct tampered software that, while compromised, will yield the same hash value as untampered software (a "collision") thus appearing uncompromised, whereas a "strong" hash, such as SHA-256, will provide a unique value for the untampered software for which it will be infeasible for the attacker to create a collision). Once the hash value has been computed over the specified address range, the hash value is stored in a hash value register 100 for later use. The hash value may be computed throughout the operation of the system 300; in which case, upon the completion of each computation cycle, the newly computed value of the hash value will be stored in the hash value register 100.

[0029] Because the sizes of hashes vary (as examples, CRC32 produces a 32-bit value, SHA-1 produces a 160-bit value, and SHA256 produces a 256-bit value), and because the sizes of keys also vary (as examples, DES requires a 56-bit key, requires a 168-bit key, AES-256 requires a 256-bit key), a converter 200 may be required to convert the hash value 100 into a key suitable for the encrypt / decrypt engine 22. It is assumed that every time a hash value is computed and stored in the hash value register 100 that a conversion (if required) takes place by the converter 200 and an appropriately sized key is available to the encrypt / decrypt engine 22. It is also assumed that the encrypt / decrypt algorithm selected uses the same key for both encryption and decryption (a "symmetrical" algorithm). In case the size of the hash is the same as (or bigger than) the size of the key, the hash (or a subset of it) can be used directly as the key. In case the size of the hash is smaller than the size of the key, certain key bits can be generated (for Page 9 of 13 example, set to zero, set to one, duplicated from other bits from the hash, mathematically combined from other bits in the hash, etc). It should be obvious to a person having ordinary skill in the art that it's ideal if the hash has the same number (or more) bits than the key, in which case the converter 200 can be simplified or eliminated altogether. It should also be obvious that in case the hash has fewer bits than the key, the generated bits must be generated consistently (so that they don't change between encryption and decryption cycles) and predictably (in case its a requirement to be able to access the data by another system that needs to be able to generate keys). As an example, for greater clarity, if the hash value 100 was a 160-bit SHA-1 value, and the encrypt /
decrypt engine 22 used DES which requires a 56-bit key size, the converter 200 would be responsible for converting the 160-bit value to a 56 bit value. It could simply discard 104 bits (160 ¨ 56).
Similarly, if 3DES was used, implying a 3 x 56 = 168 bit key size, the converter 200 could supply eight additional bits of key in order to convert the 160-bit SHA1 value to 3 56-bit values. (The actual operation of the converter 200 is not relevant to this patent disclosure;
it could supply bits that are all zeros, all ones, duplicates of other bits, etc., as described above.) If, on the other hand, SHA-256 was used in the hasher 30, and AES-256 was used in the encrypt / decrypt 22 block, then converter 200 would not be required because the key size matched the hash size, and the hash value 100 would be used directly as-is.

[0030] Once the hash value 100 has been computed (and optionally converted by the converter 200), the software in the system 300 may proceed to access the data in the secure data area 21 as required. If the software has not been tampered, then the key generated will be correct, and the encryption / decryption operations will produce the Page 10 of 13 correct results (that is, they will correctly decrypt data encrypted with the original key, and correctly encrypt data so that it can be decrypted with the original key).

[0031] In case the software is tampered, then the hash value 100 computed by the hashing hardware 30 will be different, and the resulting conversion output of the optional converter 200 will yield a key that's different than the original key. An attempt to decrypt data using the different key will yield unusable data; an attempt to encrypt data using the different key will yield data that, while usable by the program while in its tampered state (because it will be decrypting data using the new, different key), becomes unusable when the program is restored to its untampered state. In this manner, the objects of the present disclosure (that is, to provide a tamper-proof secure storage area) are met.

[0032] It should be apparent that the encrypt / decrypt engine 22 needs to protect the key by not allowing the software to supply a key for any operation, and having the key be transported only through a hardware path. It should also be apparent that the term "encryption / decryption" need not necessarily imply a cryptographically secure operation, and may instead be an operation as insecure as a simple exclusive-or operation (e.g., for signal pseudo-randomization). It should also be apparent that the secure data store may be implemented in any number of ways, (including, but not limited to: RAM, flash, rotating media, network filesystem, etc., and may also include other general encrypt /
decrypt targets, such as, but not limited to, network traffic), without altering the inventive aspects of the present disclosure.
RKIPO1C Page 11 of

[0033] In a further embodiment of this disclosure, additional data can be provided to the hardware hasher 30. Turning to the system 301 of Figure 2, the additional data is illustrated as an initialization vector 31. The purpose of the initialization vector 31 is to seed the hashing hardware 30 with a unique number (such as a serial number or node number). Whether the initialization vector 31 is considered before the firmware 20 being hashed, or at some other point, is not relevant to the spirit of the disclosure. By seeding the hashing hardware 30 with a unique number 31, the hash value 100 produced (and subsequently the key produced through the optional converter 200) is different between nodes having the same software on them. This provides additional robustness in the protection of the data being protected in the secure data storage area 21 because it means that an attacker would need to derive keys on a per-device basis, rather than on a per-software-load basis. In one embodiment, this additional data can be stored in hardware, with no software path to access the data. This means that the attacker would need to resort to hardware reverse engineering for each device in order to gain access to the data.

[0034] In another embodiment, shown as the system 302 in Figure 3, additional pieces of additional data (31a, 31b, and 31c) may be provided, some accessible through software, and some accessible only through hardware. The purpose of the additional pieces of additional data 31a accessible through software are to allow the software to create different zones 21a (shown as dashed areas) within the data store 21. Additional pieces of additional data 31b, 31c accessible through hardware can be used to allow different versions of software to be loaded on the same device, with the particular version loaded (and hence the hash value 100 and hence the resultant key) determining which zone (21b RKIPO1C Page 12 of and 21c) (dashed areas within the data store 21) is accessible. In such an implementation, for example, the manufacturer would create two additional hardware pieces of additional data 31b, 31c, one for each of the two different versions of software they produce. The vendor, being able to compute a priori the resulting key, would be able to populate both zones (shown with dashed lines) within the secure data storage area 21b, 21c with values valid to each zone. The customer, for example, would be able to select which version of software they want to run on the system, and because the selected version of software would create a key, it would be able to unlock only one of the two zones:
namely, the zone associated with the selected software.

[0035] While the present disclosure describes various exemplary embodiments, the disclosure is not so limited. To the contrary, the disclosure is intended to cover various modifications and equivalent arrangements included within the general scope of the present disclosure.

Page 13 of 13

Claims (11)

What is claimed is:

1. A data storage interface device reading and writing data stored on a data storage medium, the device comprising:
a data storage interface to read and write the data;
a memory having software code stored thereon;
a processor to operatively interface with said memory in executing said software code to at least partially operate the device; and a hardware hasher to operatively interface with said code storage device to compute a hash value over at least a designated area thereof and supply said hash value to said data storage interface via an independent path distinct from any software accessible path so as to be used to encrypt at least some of the said data being written to said storage medium and decrypt at least some of the said data being read from said storage medium.

2. The device of claim 1, wherein said decryption operation includes a decryption success indicator such that unsuccessfully decrypted data causes said success indicator to become activated.

3. The device of any one of claim 1 or claim 2, wherein additional data is supplied to said hardware hasher in computing said hash value.

4. The device of claim 3, wherein said additional data is at least one of supplied by and accessible to executed code.

5. The device of any one of claims 1 to 4, wherein said hardware hasher periodically computes said hash value during operation so as to signal possible code tampering upon identification of a change in said periodically computed hash value.

6. A method for reading and writing tamper-evident data stored on a data storage device, the method comprising:
executing software code stored on the device to at least partially operate the device;

computing a computed hash value over at least a portion of said code via a hardware hasher;
supplying said computed hash value to a data storage interface via an independent path distinct from any software accessible path; and encrypting at least some of the said data being written to said storage medium and decrypting at least some of the said data being read from said storage medium.

7. The method of claim 6, wherein said decryption operation includes a decryption success indicator such that unsuccessfully decrypted data causes said success indicator to provide evidence of tampering.

8. The method of any one of claim 6 or 7, wherein said computing comprises computing said computed hash value as a function of additional data available to said hadrware hasher.

9. The method of claim 8, wherein said additional data is at least one of supplied by and accessible to said executed software code.

10. The method of any one of claims 6 to 9, wherein said computing comprises periodically computing said hash value.

11. The method of any one of claims 6 to 9, wherein said computing comprises periodically computing said hash value such that a detected change in said periodically computed hash value provides evidence of tampering.