METHOD FOR VERIFYING DIGITAL SIGNATURES, VEHICLE COMPUTING UNIT AND VEHICLE

Description

[0001] The invention relates to a method for verifying digital signatures of the type defined in more detail in the preamble of claim 1, a vehicle computing unit with a flash memory, and a vehicle with such a vehicle computing unit.

[0002] With increasing digitalization, the level of automation in vehicles is also rising. Vehicles are increasingly equipped with sophisticated and complex computing units for evaluating sensor signals and calculating control variables. These computing units execute machine-readable code to provide their functionality. This code is stored as software on physical data storage devices. To introduce new functionalities, fix bugs, and / or close security gaps, this software is updated via a software update.

[0003] During the initial startup of a vehicle's computer unit, which can occur, for example, when the vehicle is started, data is read from the physical data storage. When software updates are installed, data can not only be read but also overwritten or deleted. To prevent the compromise of the computer unit or the data stored in the physical data storage, the data is typically digitally signed. This signature allows verification of whether the data has been manipulated by third parties or whether a software update originates from a trusted source. This ensures that only code from trusted sources is executed on the computer unit's processor.

[0004] One technique underlying digital signatures is the calculation of so-called hash values. To calculate a hash value, any data, such as a text document, an image, an email, program code, a code snippet, or similar, is used as input for a mathematical function that calculates an arbitrarily long sequence of digits from the data. This sequence can include numbers and / or letters. The mathematical function used for this is also called a hash function and is ideally deterministic. This means that using the same input data, a specific hash function will always calculate the same result, i.e., the same hash value. A hash function should be powerful enough that no different data can lead to the same hash value.

[0005] Checksums are used to verify whether data stored in a memory element of a physical data storage device has been written "correctly." This is known as cyclic redundancy checking (CRC). Errors can occur when writing and / or reading data from the data storage device, resulting in incorrect data being read or written. CRC is suitable for detecting random errors. If data integrity also needs to be verified, cryptographic hash functions should be used instead of checksums. For this purpose, a hash is generated from the written or read data and compared to a reference hash. Hashes exchanged between systems can be transmitted using established signature verification methods. If the two hashes match, this means that the data has been written or read correctly.However, checking the data is comparatively time-consuming, as a hash value must be generated from the relevant data for each check.

[0006] Various storage media, such as hard drives or flash memory, are used to store data. Distributed devices, such as embedded systems (e.g., vehicle control units), typically use flash memory to store relevant data. Such flash memory can also be permanently integrated into a processing unit, as in a system-on-a-chip (SoC). A flash memory device comprises at least one memory element for storing data and a memory controller for addressing that element. The memory element itself is structured as blocks and pages. A memory element contains a multitude of blocks, each of which contains a multitude of pages. Data is stored page by page and erased block by block in flash memory.

[0007] Secure hybrid boot systems and secure boot procedures for hybrid systems are disclosed in German patent application DE 10 2020 117 552 A1. Such a hybrid system comprises several different subsystems, each with its own storage device for storing software and its own CPU (processor) for executing the software. To enhance cybersecurity, a signature-based authentication check of the software stored on the various storage devices is performed during the boot process of a corresponding subsystem or hybrid device. This boot procedure stipulates that a first subsystem has a first signature, which corresponds to a first hash of the software stored on the storage device of the first subsystem.The first hash of the first software is transmitted from the first subsystem to the second subsystem, which has a second signature that corresponds to the first hash of the first software. The authentication validation check is then performed by comparing the corresponding hashes.

[0008] Furthermore, US patent 2018 / 113703 A1 discloses a method for updating the software of a vehicle control unit. To validate that the update originates from a trusted source, hash values ​​are generated from the program code of the complete program, and a signature is determined for these hash values. This signature is then compared with a reference signature obtained from an external software update entity. Since calculating hash values ​​from data is time-consuming, the hash values ​​are generated before the actual software update is performed and stored in a test data block for later use.

[0009] Furthermore, US Patent 2007 / 192610 A1 discloses a method and device for the secure booting of software from an external storage device. To validate the trustworthiness of software to be loaded, a hash value for the software is calculated and compared with a reference hash securely stored in a non-overwritable data memory. To save time in calculating the hash value, it is not calculated separately later, but rather during the software loading process.

[0010] Furthermore, US patent 2018 / 183605 A1 discloses a software distribution device and software distribution method, as well as a vehicle. The patent also describes validating the trustworthiness of software by comparing a hash value generated by the software with a reference hash obtained from an external source.

[0011] Furthermore, the validation of a vehicle control unit is known from US 2020 / 0314096 A1.

[0012] The present invention is based on the objective of providing a method for verifying digital signatures, which accelerates the storage, reading and / or deletion of data in or from a storage element of a flash memory.

[0013] According to the invention, this problem is solved by a method for verifying digital signatures with the features of claim 1. Advantageous embodiments and further developments, as well as a vehicle computing unit with flash memory and a vehicle with such a vehicle computing unit, are described in the dependent claims.

[0014] In a method for verifying digital signatures of the type mentioned above, a hash processed to generate a signature is created by applying a hash function to data stored in flash memory. According to the invention, at least the following method steps are performed: Writing data to at least one memory element of the flash memory; for each written block of the flash memory: calculating a hash from the data written to the respective block by a memory controller of the flash memory and storing the calculated hash, together with the data, in the block; calculating a verification hash by applying a hash function to at least one hash stored in a block by the memory controller; reading at least one hash stored in a block and the verification hash for the blocks whose signature is to be checked by a system superior to the flash memory; calculating a check hash by applying a hash function to at least one of the read hashes by the system superior to the flash memory; comparing the calculated check hash with the read verification hash; and if the check hash matches the verification hash: confirming the signature.

[0015] The method according to the invention accelerates the verification of digital signatures of data stored in flash memory. This allows the corresponding data to be read from or overwritten in the flash memory more quickly. A corresponding computer system or processing unit can thus boot faster, load executable software more quickly, or update software stored in the flash memory more quickly. The core idea is that, to generate the verification hash, it is no longer necessary to create a hash of the data stored in the flash memory, but rather the verification hash is calculated by applying a hash function to the stored hash(s). Due to the smaller amount of data, the hashes can be read from the flash memory more quickly than the data used to create the software.

[0016] Any cryptographic hash function such as HAVAL, Whirlpool or Secure Hash Algorithm (SHA), especially SHA2 or SHA3, can be used as the hash function.

[0017] The individual hashes stored in the blocks, as well as the verification hash, are calculated by the flash memory itself, more precisely by the flash memory's memory controller. The verification hash can be stored in any block of a memory element within the flash memory. Since the memory controller addresses a corresponding memory element, it also knows where to read the verification hash as soon as a corresponding request is received. The flash memory is integrated into a higher-level system. This higher-level system is a processing unit. The processing unit includes a processor for executing the software stored as data on the flash memory. It is also possible for the system that oversees the flash memory to communicate with another processing unit.This allows data to be read from the flash memory and forwarded from the higher-level system to the next processing unit. Conversely, data can be transmitted from the next processing unit to the higher-level system and thus transferred to the flash memory for storage. This enables, for example, the installation of software updates for the software running on the higher-level system.

[0018] If the system overlying the flash memory is, for example, a vehicle control unit that is to be booted, the corresponding software stored in the form of data on the flash memory is read and executed by the processor. However, to read the corresponding software, a successful signature check must be performed to prevent potentially manipulated data, and thus compromised software injected into the vehicle control unit, from being executed. With the method according to the invention, it is therefore no longer necessary to read the respective data from the blocks and calculate the check hash for signature verification. Instead, only the hash(s) already calculated and stored in the flash memory are read, and the check hash is calculated by applying the hash function to the hash(s) read from the blocks. This is significantly faster.This allows the system above the flash memory to boot faster, the corresponding software to start and run faster, and software updates to be installed faster.

[0019] When a software update is installed, the data, or a portion thereof, in the individual blocks of the flash memory's storage element is replaced or supplemented with new data. Since the data changes, the corresponding hash of each block containing the modified data also changes. When new or modified data is written to a block, the flash memory, specifically the memory controller, calculates a new hash for that block. Similarly, a new verification hash must also be calculated, as the underlying hash(s) have changed. This may require modifying the firmware of the flash memory and / or the system supporting the flash memory, so that the memory controller can store the calculated hashes in the flash memory's storage element, or so that the hash stored in each block can be read.

[0020] An advantageous further development of the method according to the invention provides that the signature of at least one block is verified in order to read and / or overwrite the data stored in the block. As already mentioned, this prevents the implementation or execution of compromised software in a vehicle control unit.

[0021] According to a further advantageous embodiment of the method, an individual page hash is generated for at least one written page of a block of flash memory, i.e., the corresponding memory element, and stored on that page. Data is always stored in the flash memory element in block form, with each block being stored as a page. To provide at least one hash for a block, the corresponding hash can be stored on any page of that block. However, a separate hash can also be generated for one, several, or each written page of a block. Accordingly, a hash function can then be applied to one page hash, several page hashes, or all page hashes of a block to generate the verification hash.It is also possible to calculate a hash for the corresponding block from one or more page hashes, and this block hash calculated from at least one page hash can then be used to calculate the verification hash.

[0022] Generally, any combination of page and / or block hashes can be used to calculate the verification hash. However, the system calculating the verification hash must have information about which hashes are used in the calculation in order to achieve a match between the verification hash and the check hash.

[0023] According to a further advantageous embodiment of the method according to the invention, when verifying the signatures of at least two blocks, the signature of each block is checked separately. If software is so large that the corresponding code must be stored in multiple blocks, then each block, or rather the data stored therein, must also be checked for integrity. This can be done individually for each block. For each block, the memory controller calculates a verification hash from a hash representative of the respective block (optionally including page hashes) and stores it in the corresponding block. Similarly, the system higher than the flash memory calculates a check hash for each block from the hashes representative of the respective blocks and compares these with the respective verification hashes. This allows for particularly secure signature verification.If data has been manipulated, this allows the blocks containing the corrupted data to be directly identified.

[0024] A further advantageous embodiment of the method according to the invention provides that, when a signature verification of at least two blocks is pending, it is also possible to verify a common block signature. For this purpose, a common verification hash is calculated from the respective hashes of the blocks. This can further reduce the time required to read the data from the corresponding blocks, since the signature of the corresponding blocks can be verified even faster. It is possible for the flash memory to generate a common signature for several blocks, i.e., the corresponding common verification hash, before data is to be read from the corresponding blocks. This is possible, for example, during the initial saving, i.e., installation of software in the flash memory.This allows the memory controller to know which data belongs to the corresponding software and which blocks need to be read when the software is loaded. For these blocks, the memory controller can then calculate the common verification hash from the individual block hashes in advance.

[0025] However, installing an update may require replacing only individual code blocks within the software. These blocks and pages can be located in any number of blocks and pages. Therefore, the memory controller cannot know in advance which blocks and pages it will need to access. Consequently, one possible implementation of the process could involve the memory controller generating the corresponding verification hash only when a request to read or write data from different blocks is made.

[0026] Reading and / or overwriting data stored in different blocks and pages is particularly relevant for installing differential software updates. Signature verification is preferably performed during a differential software update of software executable on the system that overlies the flash memory. A differential software update is a software update in which only changed code blocks are replaced. This reduces the size of the corresponding software update. Consequently, less data needs to be written, which shortens the installation time.

[0027] In a vehicle computing unit with flash memory, the flash memory is configured according to the invention to carry out the method described above. The vehicle computing unit can be any computing unit. For example, the vehicle computing unit can be a central on-board computer, a telematics unit, or any control unit of a vehicle subsystem. The flash memory can be implemented as NAND flash or NOR flash. The flash memory can have one or more memory elements. A corresponding memory element consists of several blocks in which data is stored page by page in memory cells. A memory element can have any size. For example, a memory element can have a size of 100 KB, 64 MB, 1 GB, 128 GB, 1 TB, or the like.The flash memory also includes a memory controller for addressing the corresponding memory elements. The vehicle's computer unit can communicate with other vehicle computers. For example, software updates can be received over-the-air from a communication module and forwarded for installation, such as an update to the engine control software.

[0028] According to the invention, a vehicle comprises a vehicle computing unit as described above. The vehicle can be any type of vehicle, such as a car, truck, van, bus, or the like. Using the inventive method and the inventive vehicle computing unit, the boot process and the software loading process in the vehicle can be accelerated. Furthermore, software updates can be implemented more quickly in the corresponding vehicle computing unit or its flash memory. Since signature verification is performed to access the flash memory, the cybersecurity of the corresponding vehicle computing unit is maintained.

[0029] Further advantageous embodiments of the inventive method for verifying digital signatures, the vehicle computing unit and the vehicle also result from the exemplary embodiments which are described in more detail below with reference to the figures.

[0030] This shows: Fig. 1 a schematic top view of a vehicle computing unit; Fig. 2 a schematic representation of the memory structure of a memory element of a flash memory; and Fig. 3 a schematic sequence of a signature verification for read and / or write access to the flash memory.

[0031] Figure 1Figure 5 shows a vehicle processing unit 5, for example, an engine control unit or a central on-board computer. The vehicle processing unit 5 comprises at least one flash memory 1 and thus represents a system 3 superior to the flash memory 1. Furthermore, the vehicle processing unit 5 comprises a processor 6 for executing program code stored on the flash memory 1.

[0032] The flash memory 1 also comprises at least one memory element 1.1 and a memory controller 1.2. Data is stored on a memory element 1.1. The memory controller 1.2 addresses the respective memory elements 1.1, so that the correct data is addressed during a write or read access to the flash memory 1.

[0033] Figure 2Figure 1.1 illustrates the structure of a memory element. A memory element comprises a multitude of blocks in which data to be stored is placed page by page, i.e., in the form of at least one page. Flash memory can only be written to page by page and erased block by block.

[0034] To enhance cybersecurity, a signature check is performed before any read or write access to the data stored in flash memory 1. Signature verification requires comparing hash values. According to current best practices, at least one hash value is calculated from the data stored in flash memory 1 and stored. When accessing the data, the processor accessing the data also calculates a hash value from the read data. This hash value is then compared to the previously calculated hash value. If both hash values ​​match, the signature verification is confirmed. However, this process is relatively time-consuming, as a hash value must be recalculated for each read or write access to the data.

[0035] According to a method according to the invention, the flash memory 1, i.e., the memory controller 1.2, calculates a hash for at least each block 2 when writing data to the flash memory 1 and stores this hash together with the data to be written in the respective block 2. The underlying idea of ​​the method according to the invention is that, for calculating the hashes used for signature verification, the data stored in the flash memory 1 are no longer read into a corresponding hash function, but rather the hashes calculated by the flash memory 1. The advantage is that reading the hashes calculated by the flash memory 1 is much faster than reading the data itself. Thus, signature verification can be performed much faster.

[0036] A verification hash #P is used for signature verification (see Figure 3) is compared with a verification hash #V. The verification hash #V is calculated from at least one block hash #B. At least one block hash #B is read into a hash function, and the verification hash #V is derived from this function. Each block hash #B and the verification hash #V are stored on a page 4 of a block 2. Any page 4 can be used for this purpose. Thus, the verification hash #V can be, as in Figure 2 Indicated by a dashed triangle, it can also be placed on a different side 4 than the block hash #B of the corresponding block 2.

[0037] It is also possible that when writing data to flash memory 1, a single page hash #S is generated for at least one page 4 of a block 2. In this way, a certain fraction of the user data 7, i.e., the code for implementing a program, is stored on each page 4. Flash memory 1, i.e., memory controller 1.2, reads the user data 7 as input into a hash function and calculates the respective block hashes #B and / or page hashes #S from it.

[0038] The user data 7, optionally including the page hashes #S, is stored on a respective page 4. Once the write operation is complete, the verification hash #V is determined for the corresponding blocks 2 from the respective block hashes #B using another hash function. The verification hash #V is then also stored on any page 4 of any block 2. The individual hash functions used to calculate the hashes can be identical or different. They can also differ in their power.

[0039] Blocks 2 whose block hashes #B were calculated differently can also be combined to calculate the verification hash #V. For example, in the first set of blocks 2, the respective block hashes #B may have been calculated from the payload data 7, and in the second set of blocks 2, the respective block hashes #B may have been calculated from page hashes #S.

[0040] Figure 3 This section now shows a schematic sequence of the signature verification process. First, the flash memory 1, or more precisely the memory controller 1.2, calculates block-specific block hashes #B from the data to be written to flash memory 1. A block hash #B can be calculated either directly from the user data 7 or from the page hashes #S. The verification hash #V is then calculated from at least one block hash #B and also stored in a block 2. Since theoretically only one block hash #B is sufficient to calculate the verification hash #V, in Figure 3Only one block hash #B is connected to the verification hash #V by a solid line. The dashed lines symbolize that the use of multiple block hashes #B and / or page hashes #S for calculating the verification hash #V is optional, or only relevant if so much user data 7 needs to be written / read that it must be written to or read from multiple blocks 2.

[0041] If access to the user data 7 is required, whether for reading, writing, and / or deleting, a processor 6 of a data-accessing computing unit, for example, the vehicle's computing unit 5, calculates a verification hash #P that appropriately corresponds to the verification hash #V. If the verification hash #P matches the verification hash #V, then the signature verification is successful. If, however, the verification hash #P and the verification hash #V do not match, this indicates manipulation of the user data 7, whereupon the signature verification is rejected.

[0042] To calculate the verification hash #P, the processor 6 uses the same hash functions as the flash memory 1. Instead of the user data 7, the page hashes #S and / or block hashes #B are read from the flash memory 1 by the processing unit accessing it, according to the inventive method. If the data was compromised between its initial storage on the flash memory 1 and its readout by the processing unit, the hashes now read from the flash memory 1 will no longer match the original hashes, since the memory controller 1.2 calculates new block hashes #B when writing data. However, since the verification hash #V was not changed during the manipulation process, the verification hash #P will not match the verification hash #V if the data has been manipulated.

[0043] However, if the data stored in flash memory 1 is modified by a trusted source, the verification hash #V is recalculated after successful signature verification.

[0044] Compromising the hash values ​​exchanged between the computing unit and the flash memory 1 can be prevented by using encryption techniques proven in signature verification, such as encryption and decryption with private and public keys.

Claims

1. Method for verifying digital signatures, a hash that is processed in order to generate a signature being created by applying a hash function to data stored in a flash memory (1), characterized by at least the following method steps: - writing data into at least one memory element (1.1) of the flash memory (1); - for each written block (2) of the flash memory (1): calculating, by means of a memory controller (1.2) of the flash memory (1), a hash from the data written into the relevant block (2) and storing the calculated hash, together with the data, in the block (2); - calculating, by means of the memory controller (1.2), a verification hash (#V) by applying a hash function to at least one hash stored in a block (2); - reading out at least one hash stored in a block (2) and the verification hash (#V) for the blocks (2), the signature of which is to be verified by means of a system (3) which is of a higher level than the flash memory (1); - calculating a check hash (#P) by applying a hash function to at least the one read-out hash by means of the system (3) which is of a higher level than the flash memory (1); - comparing the calculated check hash (#P) with the read-out verification hash (#V); and - if the check hash (#P) matches the verification hash (#V): confirming the signature.

2. Method according to claim 1, characterized in that the signature of at least one block (2) is verified in order to read out and / or overwrite the data stored in the block (2).

3. Method according to claim 1 or claim 2, characterized in that, for at least one described page (4) of a block (2) of the flash memory (1), an individual page hash (#S) is generated and stored on the relevant page (#S).

4. Method according to claim 3, characterized in that, in order to generate the hash of a block (2), a hash function is applied to at least one page hash (#S).

5. Method according to any of claims 1 to 4, characterized in that, in the event of a pending verification of the signatures of at least two blocks (2), the signature of a relevant block (2) is verified separately.

6. Method according to any of claims 1 to 4, characterized in that, for a pending verification of the signatures of at least two blocks (2) by means of a common signature, a verification hash (#V) is calculated from the two individual hashes of the blocks (2) to be verified.

7. Method according to any of claims 1 to 6, characterized in that a signature check takes place while performing a differential software update of software, which can be executed on the system (3) of a higher level than the flash memory (1).

8. Vehicle computing unit (5) comprising a flash memory (1), characterized in that the flash memory (1) is configured to carry out a method according to any of claims 1 to 7.

9. Vehicle, characterized by a vehicle computing unit (5) according to claim 8.