Procedure for authenticating data files
The method uses a manifest file with separate digital signatures for each subfile to authenticate and verify the integrity of vehicle control module software, addressing the challenge of cross-application authenticity and integrity verification.
Patent Information
- Application Number
- DE102012215729
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2011-09-19
- Filing Date
- 2012-09-05
- Publication Date
- 2025-07-10
- Estimated Expiration
- 2032-09-05
AI Technical Summary
Existing methods for authenticating vehicle control module software files lack a reusable approach that ensures authenticity and integrity across multiple vehicle control modules and applications, requiring re-signing with different digital signatures for different vehicle lines or regions.
A method involving a manifest file with a separate digital signature and individual digital signatures for each software subfile, using hash values to verify authenticity and integrity, ensuring files are from trusted sources and have not been tampered with.
Ensures the authenticity and integrity of software files by verifying hash values, preventing unauthorized use and tampering, and allowing seamless integration across different vehicle control modules and regions.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
FIELD OF THE INVENTIONExemplary embodiments of the invention relate to a method for authenticating data files, and more particularly to a method for authenticating data files, in which a plurality of subfiles of software are digitally signed with a unique, separate digital signature, respectively.BACKGROUNDDrivers have many ways to personalize their vehicles according to their preferences. For example, a user may download files from the Internet or from a computer and then store the files in a vehicle control module. Specifically, a user(s) may download files such as music files or navigation files, and then store the files in the infotainment control module of his or her vehicle. However, it may sometimes be that these files are not always downloaded from trusted sources and have integrity and authenticity issues.Another challenge that may arise in the field of vehicle electronics is the problem of multiple files, each programmed by different suppliers or sources and integrated into a single vehicle control module or modules.The vehicle control modules may specifically contain various files, each generated by a different source, which files may be tied together as hard-linked files that are part of a software package. For example, the hard-coupled files that are part of a software package may include a first file that contains an algorithm for an airbag control module and a second file that contains calibration information that defines when an airbag associated with the airbag control module will deploy. In another example, a single monolithic image corresponding to a vehicle control module may be too large and thus must be segmented into individual separate files. However, each file contained in the software package must be evaluated for authenticity and integrity. It should also be noted that updates, new features, or other types of changes to some of the files may also be made at a later time.Currently, there are several approaches to judging each of the files that are part of the software package. For example, a digital signature associated with a set of hard-coupled files may be used to authenticate the files. However, the files must be re-signed with a different digital signature if the files are included in a different application, such as a different vehicle line, or for applications in different regions of the world. Accordingly, it is desirable to provide a system for authenticating multiple files using a reusable approach that can be integrated into multiple vehicle control modules.US 2003 / 0 056 102 A1 discloses a method and an apparatus for continuously protecting the system integrity of a software product with the aid of digital signatures, in which a manifest file is used which contains, in addition to referencing all the required files of the software product, a signature of the manifest file, while signatures of the required files of the software product are stored in the respective files. Further prior art is known from US 2006 / 0 206 943 A1, US 2007 / 0 005 992 A1, US 2009 / 0 172 814 A1, US 2007 / 0 244 987 A1, WO 01 / 082 035 A2, US 2006 / 0 236 254 A1, US 2005 / 0 240 921 A1 and PAPAGEORGIU, Dimitrios: The virtual osgi framework. Master Work. ETH, Swiss Federal Institute of Technology, Department of Computer Science, Systems Group, 2008.SUMMARY OF THE INVENTIONIt is an object of the invention to provide an improved method for authenticating data files.To achieve the object, a method having the features of claim 1 is provided. Advantageous embodiments of the invention can be taken from the dependent claims, the description and the drawings.According to the present invention, there is provided a method of authenticating data files. The method includes providing a plurality of subfiles of software and a manifest file associated with the subfiles of the software. The manifest file identifies each of the plurality of subfiles of the software. The method includes associating a separate manifest digital signature with the manifest file. The method also includes digitally signing the manifest file with the separated digital manifest signature. The separated manifest digital signature authenticates the manifest file. The method includes associating each of the plurality of subfiles of the software with one of a plurality of distinct digital signatures. The method includes digitally signing each of the plurality of subfiles of the software with one of the plurality of distinct digital signatures. Each of the plurality of distinct digital signatures authenticate one of the plurality of subfiles of the software. The method also includes computing a manifest file hash value of the manifest file and extracting a hash value of the manifest digital signature from the separated manifest digital signature and comparing the manifest file hash value and the hash value of the manifest digital signature to determine whether the manifest file hash value and the hash value of the manifest digital signature match. In addition, a list of part numbers representing the plurality of part files of the software is extracted from the manifest file when the manifest file hash value and the hash value of the manifest digital signature match. The method further includes computing a hash value for the subfile of the software for each of the plurality of subfiles of the software and comparing the hash value for the subfile of the software with a respective hash value present in the manifest file, and wherein if the hash value for the subfile of the software matches the respective hash value of the manifest file, then extracting a hash value of a corresponding separate digital signature from each of the plurality of unique separate digital signatures. Finally, the hash value of the software subfiles is compared with the hash value of the separated digital signatures, all the software subfiles being authenticated if the hash values of the software subfiles and the corresponding separated digital signatures match.The above features and advantages and other features and advantages of the invention will be readily apparent from the following detailed description of the invention when read in conjunction with the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGSOther features, advantages, and details appear, by way of example only, in the following detailed description of embodiments, the detailed description referring to the drawings, in which: FIG. 1 is a schematic illustration of an example system for authenticating data files that includes a storage device and at least one vehicle control module; FIG. 2 is a block diagram of the system shown in FIG. 1 having a plurality of data files stored therein; and FIG. 3 is a process flow diagram illustrating a method of operating the system shown in FIG. 1.DESCRIPTION OF THE EMBODIMENTSThe following description is merely exemplary in nature and is not intended to limit the present disclosure, its application, or uses. It should be understood that corresponding reference numerals designate like or corresponding parts and features throughout the several drawings. As used herein, the terms "module" and "submodule" refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) having memory that executes one or more software or firmware programs, a combinational logic circuit, and / or other suitable components that provide the described functionality.According to an exemplary embodiment of the invention, FIG. 1 is an illustration of a data file authentication system 10. the data file authentication system 10 includes a storage device 20, a communication interface 22, and at least one control module 24. In the exemplary embodiment shown, the data file authentication system 10 is deployed in a vehicle 30, wherein the control modules 24 are vehicle control modules. The control modules 24 may be, for example, an infotainment module, a radio control module, a human machine interface (HMI) module, an airbag control module, or a navigation control module. It should be understood, however, that the data file authentication system 10 may also be used in other applications.The storage device 20 is typically any type of computing device having a memory to store data files therein, and may have the capability to store files in the vehicle. For example, in one embodiment, the storage device 20 is a Universal Serial Bus (USB) flash drive. In another embodiment, the storage device 20 is part of a service center diagnostic tool located at a dealer, the service center diagnostic tool including a memory for storing various files. In yet another embodiment, the storage device 20 is part of a flash programming tool located at a production facility. The storage device 20 is in communication with one or more of the control modules 24 through the communication interface 22. In one embodiment, the communication interface 22 is a USB interface, however, it should be appreciated that other data interface approaches may also be used. For example, in an alternative embodiment, an 8 contact plug or radio link may also be used.Referring now to FIG. 2, a block diagram of the storage device 20, the communication interface 22, and the control module 24 is illustrated. The storage device 20 contains a plurality of subfiles 40 of software and a manifest file 42. The software subfiles 40 can be, for example, software files, calibration files, reference data files, image files or voice files. Each of the software subfiles 40 may contain a unique identifier, such as a part number, assigned by a manufacturer. That is, each part file 40 of the software has a corresponding identifier, such as a corresponding part number. The manifest file 42 identifies each of the software subfiles 40 by the unique identifier of the software subfile. Specifically, in one example, the manifest file 42 identifies each of the software subfiles 40 by a respective part number. The software subfiles 40 are a set of related files. That is, the subfiles 40 of the software are likely to depend on each other. In one embodiment, the software files are, for example, a set of hard-coupled files. The software subfiles 40 may be, for example, part of a software package that includes a first file containing an algorithm for the airbag control module and a second file containing calibration information that defines when an airbag associated with the airbag control module will deploy. Alternatively, in another embodiment, the software subfiles 40 may include a first file that updates a user interface of an HMI module and a second file that includes algorithms to process specific user requests for a radio control module.Each software subfile 40 has a corresponding unique, separate digital signature 46. In particular, the separate digital signatures 46 are separately stored digital signatures that are used to authenticate the software subfiles 40. The separated digital signatures 46 indicate whether the software subfiles 40 are from a trusted source. The separated digital signatures 46 may also indicate whether the software subfiles 40 have been manipulated. The manifest file 42 also includes a corresponding distinct digital manifest signature 50. Similar to the distinct digital signatures 46, the distinct digital manifest signature 50 indicates whether the manifest file 42 originated from a trusted source and whether the manifest file 42 has undergone tampering. In the exemplary embodiment shown in FIG. 2, the unique distinct digital signatures 46 and the distinct manifest digital signature 50 are part of a single file 52 having distinct digital signatures. Each of the subfiles 40 of the software is digitally signed with one of the separate digital signatures 46, and the manifest file 42 is signed with the separate manifest digital signature 50.In one embodiment, storage device 20 may also further include license file 62. License file 62 is used to prevent unauthorized use of software files 40 in general. The license file 62 contains a digital signature 64, wherein the digital signature 64 authenticates or validates the license file 62. In one embodiment, if the data file authentication system 10 is located in a vehicle 30, then the license file 62 may include the vehicle identification number (VIN) and the digital signature 64 may be based on the VIN as well as the manifest file 42.In one embodiment, the software subfiles 40 and the manifest file 42 are digitally signed through the use of a message digest, also referred to as a hash value. The hash value represents a variable length data string that has been transformed into a fixed length data string. The hash value may be associated with an electronic data file or data string of varying length and is used to verify that the electronic data has not been altered by an unauthorized user. The hash value may be calculated by a hash function. A hash algorithm or similar function may be any type of approach for recalculating a variable string of characters into a fixed string of characters. Some examples of a hash function include, but are not limited to, MD5, SHA1, SHA-256, SHA-384, and SHA-512. The separated digital signatures 46 and the separated manifest digital signature 50 each contain an encrypted hash value.With continued reference to FIG. 2, the control modules 24 include control logic for monitoring the storage device 20 for a data signal including the encrypted hash values of separate digital signatures 46 and the separate manifest digital signature 50. The control module 24 also includes control logic to extract the encrypted hash values from the separated digital signatures 46 and the separated manifest digital signature 50. The control module 24 includes control logic for monitoring the storage device 20 for data including the software subfiles 40 and the manifest file 42. The control module 24 further includes control logic for computing a hash value representing the data contained in each of the software subfiles 40 and the manifest file 42. More specifically, the control module 24 uses the hash function to generate a hash value corresponding to each of the subfiles 40 of the software and another hash value representing the data contained in the manifest file 42.The control module 24 further includes control logic for comparing the hash value of the manifest file 42 to the hash value of the distinct manifest digital signature 50. In the event that the integrity of the manifest file 42 is determined, the control module 24 includes control logic for calculating hash values for the data contained in each of the subfiles 40 of the software and comparing the generated hash values with a respective hash value present in the manifest files 42. The control module 24 also includes control logic for comparing the calculated hash values of the software subfiles 40 with hash values extracted from the respective separate digital signatures 46. In the event that the hash values of the software subfiles 40 and the hash values extracted from the respective separate digital signatures 46 are both matched, this indicates that the authenticity of the software subfiles 40 is valid. Moreover, matching the hash values also verifies the integrity of the software data files 40. Thus, the software subfiles 40 and the manifest file 42 may be stored in a memory of one or more of the control modules 24. In the event that the integrity of the manifest file 42, any of the software subfiles 40, or the entire software package, is not verified, then the software subfiles 40 and manifest file 42 are not stored in the memory of the control modules 24.In one embodiment, if a license file, such as license file 62, is needed to download the software subfiles 40, then manifest file 42 stores a license flag. The license flag is sent to one or more of the control modules 24. The license flag is an indication that a license is needed to download the software subfiles 40. The control modules 24 include control logic for requesting the license file from the storage device 20. Thus, license file 62 is used to ensure that the software subfiles 40 have not been stolen or otherwise acquired from an unauthorized source.A method of operating the data file authentication system 10 will now be explained. With reference to FIG. 3, and with continued reference to FIGS. 1-2, an example process flow diagram illustrating an example process for operating the data file authentication system 10 is generally indicated by reference numeral 100. The method 100 begins at step 102, where one or more control modules 24 include control logic to monitor the storage device 20 for a data signal including a hash of a separate manifest digital signature 50 and for data including a manifest file 42 illustrated in FIG. 2. The method 100 may then proceed to step 104.At step 104, the control module 24 includes control logic for computing a hash value for the data contained in the manifest file 42. In particular, in one embodiment, the control modules 24 use a hash function to generate a hash value for the data contained in the manifest file 42. The control module 24 also includes control logic for extracting the encrypted hash values from the separated manifest digital signature 50. the method 100 may then proceed to step 106.At step 106, the control module 24 includes control logic for comparing the hash value of the manifest file 42 to the hash value of the distinct digital manifest signature 50. Therefore, the method 100 will then end. In the event that the hash values of the manifest file 42 and the separated manifest digital signature match, this authenticates the manifest file 42. once the manifest file 42 has been authenticated, the method 100 may then proceed to step 108.At step 108, the control module 24 includes control logic for monitoring the storage device 20 and extracting from the manifest file 42 a list of part numbers representing part files 40 of the software.At step 110, the control module 24 includes control logic for computing a hash value for the data contained in each of the software data files 40. The control logic compares the calculated hash values of the software data files 40 with corresponding hash values present in the manifest file 42 to verify the integrity of the entire software package. In the event that the integrity has not been established, the method 100 will then end. The control module 24 also includes control logic for extracting the encrypted hash values from each of the separated digital signatures 46. the method 100 may then proceed to step 112.At step 112, the control module 24 includes control logic for comparing the hash of the software subfiles 40 to the hash of the separated digital signatures 46. In the event that not all the hash of the software datafiles 40 and the corresponding separated digital signatures 46 match, this is an indication that the software datafiles 40 may have been manipulated or otherwise altered. Therefore, the method 100 will then end. In the event that the hash values of the software subfiles 40 and the corresponding separate digital signatures 46 match, this authenticates all the software subfiles 40 and the method 100 may then proceed to step 114.At step 114, the control module 24 includes control logic for storing the software subfiles 40 and the manifest file 42 in a memory of the control modules 24 since the integrity of the manifest file 42 and all the software subfiles 40 has been verified. The method 100 may then end.Although the invention has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. It is therefore intended that the invention not be limited to the particular embodiments disclosed, but that the invention will include all embodiments falling within the scope of the application.
Claims
A method for authenticating data files, comprising: providing a plurality of subfiles (40) to software and a manifest file (42) associated with the subfiles (40) of the software, the manifest file (42) identifying each of the plurality of subfiles (40) to the software; associating a separate manifest digital signature (52) with the manifest file (42); digitally signing the manifest file (42) with the separate manifest digital signature (50), the separate manifest digital signature (50) authenticating the manifest file (42); associating each of the plurality of subfiles (40) with the software one of a plurality of unique separate digital signatures (46); each of the plurality of subfiles (40) of the software is digitally signed with one of the plurality of distinct digital signatures (46), each of the plurality of distinct digital signatures (46) authenticating one of the plurality of subfiles (40) of the software; calculating a manifest file hash value of the manifest file (42) and extracting a hash value of the manifest digital signature from the distinct manifest digital signature (50); comparing the manifest file hash value and the hash value of the manifest digital signature to determine whether the manifest file hash value and the hash value of the manifest digital signature match; a list of part numbers representing the plurality of part files (40) of the software is extracted from the manifest file (42) when the manifest file hash value and the hash value of the manifest digital signature match; a hash value for the part file of the software is calculated for each of the plurality of part files (40) of the software and the hash value for the part file of the software is compared to a respective hash value present in the manifest file (42), and wherein when the hash value for the part file of the software matches the respective hash value of the manifest file (42), a hash value of a corresponding separate digital signature is extracted from each of the plurality of unique separate digital signatures (46); and comparing the hash value of the software subfiles (40) with the hash value of the separated digital signatures (46), wherein all the software subfiles (40) are authenticated if the hash values of the software subfiles (40) and the corresponding separated digital signatures (46) match.The method of claim 1, comprising providing a separate digital signature file (52) including the plurality of unique separate digital signatures (46) and the separate manifest digital signature (50).The method of claim 1, wherein a hash function is used to calculate the manifest file hash value and the hash value of the manifest digital signature.The method of claim 1, wherein a hash function is used to calculate the hash value for the subfile of the software and the hash value of the separated digital signature.The method of claim 1, comprising providing a license file (62), wherein the license file (62) comprises a license signature (64), and wherein the manifest file (42) includes a license flag that is an indication that a license is needed to download the software subfiles (40).
Citation Information
Patent Citations
Method and apparatus for protecting ongoing system integrity of a software product using digital signatures
US20030056102A1
Method and system for software and data distribution
US20050240921A1
Protecting software environment in isolated execution
US20060206943A1
System and method for automated building of component based applications for visualizing complex data structures
US20060236254A1
Signed manifest for run-time verification of software program identity and integrity
US20070005992A1