Systems and procedures for the secure transfer of software files for vehicle control modules

Abstract

Procedure which includes: a first content file and a first instruction file (XML1) are received from a development network (14), the first instruction file (XML1) containing a first parameter set, the first parameter set comprising a part number of the first content file, a part usage value and a part type of the first content file; on the basis of the first instruction parameter set, a second parameter set is determined and a second instruction file (XML2) is generated which comprises the second parameter set; the first content file and the second parameter set are transmitted to a signature server (18); a signature file is received from the signature server (18), the signature file containing a signature (SIG 166), and the signature server (18) generating the signature file based on the second instruction file (XML2); the signature (SIG 166) is integrated into the first content file to create a second content file; the second content file is downloaded to a service server (20), a manufacturing server (22) and / or a supplier network; determining whether a target vehicle control module allows the server to select a signing key based on the parts usage value; determining whether the first content file is a calibration file, a software file, a firmware file, a boot file, a key exchange file, or a license file based on the part type; and the second instruction file (XML2) is generated based on the part number, part usage value and part type.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 61 / 621,238, filed April 6, 2012. The disclosure of the above application is incorporated herein by reference in its entirety. AREA

[0002] The present disclosure relates to secure file transfer systems for transferring vehicle files. BACKGROUND

[0003] Vehicles contain various vehicle control modules, such as an engine control module, a transmission control module, an air conditioning control module, an infotainment control module, a body control module, etc. The vehicle control modules execute software and / or firmware files to perform respective functions.

[0004] The automotive industry is continually adding features with enhanced amenities to vehicles and, in turn, to vehicle control modules. Mobile devices are connected to vehicle systems to transmit various types of audio and video data, as well as vehicle diagnostic and status data. Features within the vehicle can be remotely controlled using the mobile devices. As a result, there is an increased risk of malware being downloaded into the vehicle control modules. As vehicles become increasingly digitally connected to external computing devices, the vulnerability to attack increases. Examples of attack types may include attacks that infiltrate the vehicle's electronic and / or software systems, reprogram vehicle control modules, involve unauthorized exfiltration of vehicle data, and / or involve unauthorized vehicle tracking.

[0005] Authentication of a file may be performed to validate a source and / or content of the file prior to execution. Authentication is performed to prevent the downloading and / or execution of a malicious file and / or to prevent malicious and / or unauthorized modification of a file. Consequences of executing an unvalidated file may include unintended vehicle system behavior, reduced lifespan of vehicle components, loss of vehicle anti-theft features, potential tampering with vehicle components, modification of vehicle files, and / or loss of vehicle features and / or functionality. Executing an unvalidated file may also void a vehicle warranty.

[0006] A secure technique for preventing the execution of unvalidated files is called asymmetric key cryptography. Asymmetric key cryptography involves the use of digital signatures to authenticate files to be programmed into a control module. A key pair comprising a private key and a public key is used to encrypt and decrypt a digital signature. The private key is available only to a source of the file being transmitted. The source of a file can encrypt the digital signature using the private key. The encrypted digital signature can be transmitted from the source to a control module. The control module can then decrypt the encrypted digital signature using the public key.The control module can verify the signature and, based on this verification, download, save and / or execute the file, for example.

[0007] US 2005 / 0 187 674 A1 discloses a program distribution system with an on-board gateway that receives a program along with a signature and an access right identifier. If the gateway determines that the received signature is valid, it sets an access right for the received program to an ECU of the vehicle based on the access right identifier.

[0008] US 2004 / 0 054 779 A1 discloses a network system comprising a client, a server, application servers, and a proxy server. The server receives an access request from the client and distributes content, the application servers process received content and return the processed content, and the proxy server forwards data to be transmitted between the client and the server. The proxy server receives the access request from the client, forwards it to the server, and receives content from the server. The proxy server sends the received content to the application servers for processing and sends the processed content to the client.

[0009] US Pat. No. 7,529,775 B2 discloses a method for collecting information about applications in a computer system, in which a directory of applications and services installed on the computer system is generated as an XML file. For a subset of attributes stored in the directory file, a calculation can be performed to generate a signature representing the subset. The signature can be stored together with the directory file and be suitable for fast search access.

[0010] The object of the invention is to reduce the vulnerability of vehicles, which are increasingly digitally connected to external computing devices, to attack. SUMMARY

[0011] A server is provided that includes an import module that receives a first content file and a first instruction file from a development network. The first instruction file includes a first parameter set. Based on the first instruction parameter set, a job request module determines a second parameter set and generates a second instruction file including the second parameter set. The job request module transmits the first content file and the second parameter set to a signature server. An export module receives a signature file from the signature server. The signature server generates the signature file based on the second instruction file. The export module integrates the signature into the first content file to generate a second content file and downloads the second content file to a service server, a manufacturing server, and / or a supplier network.

[0012] In other features, a method is provided, comprising receiving a first content file and a first instruction file from a development network. The first instruction file includes a first parameter set. Based on the first instruction parameter set, a second parameter set is determined and a second instruction file is generated that includes the second parameter set. The first content file and the second parameter set are transmitted to a signature server. A signature file is received from the signature server. The signature server generates the signature file based on the second instruction file. The signature is incorporated into the first content file to generate a second content file. The second content file is downloaded to a service server, a manufacturing server, and / or a supplier network.

[0013] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The present disclosure will be more fully understood from the detailed description and the accompanying drawings in which: Fig. 1 is a functional block diagram of a file download system including an original equipment manufacturer (OEM) download network according to the present disclosure; Fig. 2 a functional block diagram of the OEM download network of Fig. 1 is; Fig.3 is a functional block diagram of a portion of the file download system illustrating an exemplary content file download procedure according to the present disclosure; and Fig. 4 illustrates a method of operating a file download system according to the present disclosure. DETAILED DESCRIPTION

[0015] A server may generate a signature to secure a content file transferred between network devices of an OEM network, between a network device of the OEM network and a network device outside the OEM network, and / or between network devices outside the OEM network. The signature may be a digital signature used to ensure message or file integrity and / or the identity of the source. A network device may refer to, for example, servers, computers, control modules outside or inside a vehicle, stations, ports, etc. An OEM network may be a network of, for example, a vehicle manufacturer.Techniques are disclosed herein to address: how signatures are created, embedded, and used; how users exchange and / or download information, content, files, and / or programs with devices on and off an OEM network; and how devices on the OEM network exchange and / or download information, content, files, and / or programs.

[0016] In Fig.1, a file download system 10 is shown that provides a file exchange topology for the transfer, creation, and / or integration of information, content files, and / or signatures. The file download system 10 includes an OEM download network 12. The OEM download network 12 includes an OEM development network (or engineering network) 14, a soft part (or content file) server 16, a signature server 18, a services server 20, and a manufacturing server 22. The OEM development network 14 includes network devices 24, and each of the servers 16-22 includes respective content, signature, services, and manufacturing repositories 26-32.

[0017] The OEM development network 14 may include a network device where data is entered by a user. The user may create a soft part (or content file) on the network device and download that soft part to the soft part server 16. The soft part may include, for example, a software and / or firmware program, calibration information, a boot program, key exchange information, a manifest (i.e., a record, table, or list), a license file, etc. The soft part server 16 stores soft parts in the content store 26 and instructs the signature server 18 how to generate a signature. The signature server 18 generates the signature based on instructions from the soft part server 16. The soft part server 16 may then download a signed content file to the service server 20 and / or the manufacturing server 22.

[0018] The file download system 10 may further include a supplier development network 34 and a supplier manufacturing network 36. The supplier development network 34 may generate a soft part similar to the OEM development network 14 and download the soft part to the soft part server 16. The supplier manufacturing network 36 may receive a signed content file from the soft part server 16. The soft part may have been originally generated by the OEM development network 14 and / or the supplier development network 34.

[0019] The file download system 10 may further include an OEM service network 40, a third-party service network 42, and an OEM manufacturing network 44. The OEM service network 40 may include, for example, service centers and / or vehicle dealers, each having respective service control modules (referred to as tools). A single service control module (tool 1) 46 is shown. The service control modules may be, for example, computers used to program and / or download information for a vehicle control module 48. The OEM service network 40 may download signed content files to vehicle control modules in a vehicle using the tools. The tools may obtain signed content files from the service server 20.For example, a tool can query a vehicle for soft part numbers in one or more of the vehicle's vehicle control modules. The tool can then determine which soft parts should be in each vehicle control module and then reprogram, update, and / or download the appropriate signed content files to the selected vehicle control modules.

[0020] For example, the third-party service network 42 may include one or more service centers, each having respective service control modules. A single service control module (Tool 2) 50 is shown. The service control module 50 includes a vehicle control module 54. The third-party service network 42 may download signed content files to vehicle control modules in a vehicle using the tools. The tools may obtain signed content files from the service server 20 and download the files to the vehicle control modules.

[0021] The OEM service manufacturing network 44 may include one or more manufacturing facilities where, for example, a system of a vehicle and / or the vehicle are manufactured. Each facility may also include tools for downloading signed content files. An example manufacturing control module (Tool 3) 52 is shown. The manufacturing control module 52 includes a vehicle control module 56. The facilities may download signed content files from the manufacturing server 22. The signed content files may be downloaded, for example, based on production orders. The tools may then download the signed content files to vehicle control modules in systems and / or vehicles.The vehicle control modules 48, 50, 52 may include respective security control modules 60, 62, 64 that authorize and verify signatures, contents, and / or sources of content files received from the service server 20 and the manufacturing server 22.

[0022] Following receipt of the signed content files, the vehicle control modules 60-64 may perform authorization and verification procedures to verify signatures, contents, and / or sources of the signed content files. Various authorization and verification procedures may be used. As an example, the vehicle control modules may detach the signatures from the content files, decrypt the signatures using public keys to generate first hash values, generate second hash values ​​based on the soft parts of the signed content files, and compare the first hash values ​​to the second hash values. If a first hash value matches a second hash value, the associated signed content file may be considered valid; otherwise, the signed content file may be considered invalid.The public keys may correspond to private keys used by a development network to encrypt data in the soft parts during generation.

[0023] With reference now also to Fig. 2, the OEM download network 12 is shown. The OEM download network 12 includes the development network 14, the soft part server 16, and the signature server 18. The development network 14 includes a development control module 100 and a development memory 102. The development memory 102 can store soft parts 104 and corresponding first parameter sets 106. The development control module 100 can generate the soft parts 104 and the first parameter sets 106. Example parameters that may be provided in each of the first parameter sets 106 are listed in Table 1. Table 1 - Example parameters in first instruction files parameter Description Address of the content memory 26 where a signature is stored in a soft part. Is the address of the signature that is embedded in the soft part 16 by the soft part server. Address of the content memory 26 at which a description of a signature algorithm for a soft part is stored. Is the address of the signature algorithm used by the soft part server 16 to embed the signature into the soft part. The address describes where the signature algorithm is stored as part of the soft part. Address of the content memory 26, where the description of the signature algorithm is also stored. Is the address of the signature algorithm used by the soft part server 16 to embed the signature into the soft part. The address describes where the signature algorithm is stored as part of a bootloader file (or boot part). The bootloader file is executed by a vehicle control module to validate the signature of a content file. Address of the content memory 26 where a key identifier (ID) is stored that is used to sign a soft part. Is the address used by the soft part server 16 to embed the key ID in the soft part. ren. Address of content store 26, where the key ID is also stored with a bootloader file. Is the address used by the soft part server 16 to embed the key ID in the bootloader file. The key ID is used when the bootloader file is executed to check the compatibility of a vehicle control module with a soft part. Address of content store 26 where a key with the bootloader file is stored. Is the address used by Softpartserver 16 to embed the key in the bootloader file. Address of the content store 26 at which a signature bypass mark is stored. Is the address used by Softpartserver 16 to embed the signature bypass marker in a bootloader file. Number of bytes. Length of a soft part downloaded from a development network to the soft part server 16. Security level Soft part security level. The security level can be used when executing a bootloader file to prevent soft parts with invalid security levels from being programmed into a vehicle control module. The security level can be, for example, a software content file. Control module ID Information to uniquely identify a vehicle control module. This allows a program package provided as one or more soft parts to be assigned to an individual vehicle control module. Description and value of the integrity check Identify an integrity scheme used to check the validity of a soft part downloaded from a development network to the soft part server 16. Can be used to prevent processing of the soft part if the integrity check fails. Part number Part number of the soft part. Part type For example, specifies whether the soft part is a software file, a firmware file, a calibration file, a bootloader file, a key exchange file, a manifest, a license file, etc. Parts usage value For example, indicates whether a target vehicle control module for a soft part allows the soft part server 16 to select an appropriate key to sign the soft part. Producer ID Identifies a creator (person and / or network device) of the soft part. certificate Can indicate whether a signing certificate must be delivered to a target vehicle control module as part of a reprogramming package. The certificate can be used to verify websites and can provide information related to the permitted use of a soft part. The certificate can indicate a key to be used to validate a signature, in which products (e.g., vehicles) the soft part should be used, and / or in which vehicle control modules the soft part should be used.

[0024] The first parameter sets 106 may contain parameters not included in Table 1, for example, a signature version. The signature version may identify a cryptography version. Different cryptography versions may be used based on a security level. Cryptography versions with larger resulting encrypted files may be used for higher security levels, while cryptography versions with shorter encrypted files may be used for lower security levels. The first parameter sets 106 may also contain signature integration parameters that specify where a signature should be embedded in a soft part.

[0025] One of the first parameter sets 106 may be provided in a first instruction file XML1 and accompany a soft part (or a first content file) PART, together signal 108. The soft part PART and the first instruction file XML1 may be downloaded from the development network 14 to the soft part server 16. The soft part PART and the first instruction file XML1 may alternatively be downloaded, for example, from the supplier development network 34 of Fig. 1 can be received.

[0026] The soft part server 16 includes the content store 26, an import module 110, a job request module 112, and an export module 114. The import module 110 receives pairs of soft parts and instruction files (e.g., the signal 108) from one or more development networks and corresponding network devices. The import module 110 can store the soft parts 109 and the instruction files 111 in the content store 26. The instruction files 111 can be, for example, files with an extensible markup language (XML files) and / or files with another markup, programming, and / or content language.

[0027] The job request module 112 generates job requests based on the soft parts 109 and the instruction files 111 received from the development networks. A job request may include one of the received soft parts PART and a second instruction file XML2, collectively called signal 116. Each of the second instruction files 113 provides information in the form of a second parameter set for use by the signature server 18 when generating a signature for a soft part. Second parameter sets 118 are stored in the content store 26. Example parameters that may be included in each of the second parameter sets 118 are listed in Table 2. Table 2 - Example parameters in second instruction files. parameter Description Job ID Is a unique job or transaction identifier assigned by the soft part server 16 to identify a job (or signature) request so that the appropriate soft part and signature are combined by the soft part server 16. This occurs following information containing the signature being transferred from the signature server 18 to the soft part server 16. Key ID Is an identification of a key used by the signature server 18 to generate a signature used to sign a soft part. Signature algorithm ID Identifies a selected one of several signature algorithms to be used when generating the signature.

[0028] The second parameter sets 118 may contain parameters not included in Table 2. For example, the second parameter sets 118 may contain the signature version. The second parameter sets 118 may contain signature integration parameters that specify where a signature should be embedded in a soft part.

[0029] The job request module 112 can store the second instruction files 113 in the content store 26. The second instruction files 113 can be, for example, XML files and / or files with another markup, programming, and / or content language. The job request module 112 transmits the soft parts 109 and associated second instruction files 113 to the signature server 18 for generating signatures.

[0030] The export module 114 receives the signatures in third instruction files 119 from the signature server 18. The third instruction files 119 may contain a third parameter set, which may include, for example, the signatures, the job ID (described in Table 2), or other parameters. Third parameter sets 120 are stored in the content store 26. The export module 114 may embed the signatures in the appropriate ones of the soft parts 109 to generate second content files. The second content files may be sent to the service server 20, the manufacturing server 22, or the supplier manufacturing network 36 in Fig. 1 be transferred.

[0031] The signature server 18 may include the signature memory 28 and a signature control module 130. The signature control module 130 may receive the soft parts 109 and the accompanying second instruction files and generate the third instruction files 119 based thereon. The third instruction files 119 may be sent to the soft part server 16 as XML3 signals 132. The soft parts 109, the second instruction files 113, the third instruction files 119, and the third parameter sets 120 may be stored in the signature memory 28.

[0032] The export module 114 may also embed a key and / or a key ID for decrypting a content file and / or certain contents of the content file into a bootloader file. The key and / or the key ID may be provided as parameters of the first parameter sets, the second parameter sets, and / or the third parameter sets. The bootloader file may be downloaded from the export module 114 to a vehicle control module, for example, via the servers 20, 22 and the networks 40, 42, 44. The bootloader file may contain instructions that, when executed by the vehicle control module, verify a signature, a soft part, and / or a source of the signature and / or soft part based on the key and / or the key ID. The bootloader file may also contain instructions for booting the vehicle control module.

[0033] In Fig.3, a portion 150 of the file download system 10 is shown, illustrating an exemplary content file download procedure. The portion 150 includes the soft part server 16, the signature server 18, the service server 20, a service control module 152 (e.g., one of the control modules 46, 50), and a vehicle control module 154. The soft part server 16 includes the content store 26, the import module 110, the job request module 112, and the export module 114. The job request module 112 transmits each soft part and every second instruction signal (e.g., 116) to the signature server 18. The content store 26 stores the soft parts 109, the instruction files 111, 113, 119, and the second parameter sets 118.

[0034] The signature server 18 includes the signature control module 130 and the signature memory 28. The signature memory 28 stores the soft parts 109, the instruction files 113, 119, and the third parameter sets 118. The signature control module 130 may include a first cryptography module 156, an encryption module 158, and an instruction module 160. The cryptography module 156 may receive a soft part PART 162 and generate a first hash value HASH1 164. The encryption module 158 may encrypt the first hash value HASH1 164 using a private key to generate a signature SIG 166. The instruction module 160 may generate the third instruction signal XML3 132 based on the signature 166.The operation of the first cryptography module 156, the encryption module 158, the instruction module 160 and / or the generation of the first hash value HASH1 164, the signature SIG 166 and / or the third instruction signal XML3 132 may be based on one or more of the parameters in the second instruction file of the signal 116.

[0035] The export module 114 receives the third instruction signal 132 from the signature server 18 and embeds the SIG signature 166 of the third instruction signal 132 into the corresponding soft part to generate a second content file. The export module downloads the second content file to the service server 20. The service server 20 can then download the second content file to the service control module 152 upon request. The service control module 152 can then flash, reprogram, update, and / or store the second content file into a memory 170 of the vehicle control module 154.

[0036] The vehicle control module 154 may include a security module 172. The security module 172 may include a decryption module 174, a second cryptography module 176, and a hash comparison module 178. The decryption module 174 decrypts the signature SIG 166 using a public key PUB 180 corresponding to the private key to generate a second hash value HASH2 182. The second cryptography module 176 generates a third hash value HASH3 184 based on the soft part PART 162. The hash comparison module 178 compares the second hash value HASH2 to the third hash value HASH3 184. If the second hash value HASH2 182 matches the third hash value HASH3 184, then the signature is valid; otherwise, the signature is invalid. This can be indicated using a validation signal VAL 186.

[0037] The file download system 110 may be operated using numerous methods, with an exemplary method being the method of Fig. 4 is provided. In Fig. 4 shows a method for operating a file download system. Although the following tasks are primarily related to the implementations of Fig. 1-3, the tasks may be easily modified to apply to other implementations of the present disclosure. The tasks may be performed iteratively. The method may begin at 200.

[0038] At 202, a soft part (or first content file) is generated using a development control module of a development network (e.g., the OEM development network 14 or the supplier development network 54). At 204, the development control module may determine a first set of parameters (example parameters are listed in Table 1 above) and generate the first instruction file XML1. The first instruction file XML1 is used by the soft part server 16 to correctly sign and store the soft part, as further described with reference to the following tasks. By way of example only, the first content file may be encrypted using a private key, as described above.

[0039] At 206, the import module 110 receives the soft part and the first instruction file from the development network. At 208, the job request module 112 determines a second parameter set (example parameters are listed in Table 2 above) and generates the second instruction file XML2 based on the first instruction file. The second parameter set may be a subset of the first parameter set and / or may include different parameters than the first parameter set.

[0040] At 210, the job request module 112 transmits a job (or signature) request containing the soft part and the second instruction file XML2 to the signature server 18. The second instruction file XML2 accompanies the soft part to the signature server 18 and may inform the signature server 18 how to generate a signature. At 212, the signature control module 130 determines a third parameter set and generates a signature file based on the second parameter set in the second instruction file. The signature file may be an XML file and / or a file in another markup, programming, and / or content language. The third parameter set may be a subset of the second parameter set and / or may include different parameters than the second parameter set. Example parameters that may be included in the third parameter set are described above with reference to Fig.2. The signature module 18 transfers the signature file containing the third parameter set to the soft part server 16.

[0041] At 214, the export module 114 receives the signature file. At 216, the export module 114 integrates a signature in the signature file into the soft part to generate a signed (or second) content file. At 218, the export module 114 downloads the second content file to the supplier, service, and / or manufacturing networks 36, 40, 42 and / or to control modules and / or network devices in the supplier, service, and manufacturing networks 36, 40, 42.

[0042] At 220, one or more of the control modules of the supplier, service, and manufacturing networks 36, 40, 42 may download the second content file to a vehicle control module in a vehicle.

[0043] The following tasks 222-234 are provided as an example and may not be performed. Alternative authorization and verification tasks may be performed instead of tasks 222-234.

[0044] At 222, one of the vehicle control modules may detach the signature in the second content file from the second content file. At 224, the signature may be decrypted with a public key to generate a first hash value. At 226, the soft part of the second content file may be stored in or flashed into a memory of the vehicle. At 227, the vehicle control module may calculate a second hash value based on the soft part.

[0045] At 228, the vehicle control module may compare the first hash value to the second hash value to determine if the signature, the soft part, and / or sources of the soft part and / or the signature are valid. If at 230, the first hash value matches the second hash value, then at 232, the signature, the soft part, and / or the sources are determined to be valid. If the first hash value does not match the second hash value, then at 234, the signature, the soft part, and / or the sources are determined to be invalid. At 232, the vehicle control module may execute the soft part and / or use information in the soft part to perform tasks within the vehicle. At 234, the vehicle control module may refrain from executing the soft part, not use information in the soft part, and / or delete the soft part. At 236, the method may end.

[0046] The tasks described above are intended as illustrative examples; the tasks may be executed sequentially, synchronously, concurrently, continuously, during overlapping time periods, or in a different order depending on the application. Furthermore, depending on the implementation and / or the sequence of events, any of the tasks may not be executed or may be skipped.

[0047] The implementations described above include the transfer of instruction files and signature files, which can be XML files. The XML files enable the generation of signatures. The use of XML files allows servers, tools, and / or other network devices to read information in a predictable, automated manner, eliminating manual parameter entry. The described file transfer also supports secure flash programming of vehicle control modules to prevent malicious content files from being programmed into vehicle control modules.

[0048] As used herein, the term module may refer to, be a part of, or include an application-specific integrated circuit (ASIC), a discrete circuit, an integrated circuit, a combinational logic circuit, a field-programmable gate array (FPGA), a processor (shared, dedicated, or group) that executes code, other suitable hardware components that provide the described functionality, or a combination of some or all of the foregoing, such as in a system-on-chip. The term module may include memory (shared, dedicated, or group) that stores code executed by the processor.

[0049] The term code, as used above, can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, and / or objects. The term shared, as used above, means that some or all of the code can be executed by multiple modules using a single (shared) processor. In addition, some or all of the code from multiple modules can be stored in a single (shared) memory. The term group, as used above, means that some or all of the code can be executed by a single module using a group of processors. In addition, some or all of the code can be stored in a single module using a group of memories.

[0050] The devices and methods described herein may be implemented in part or in whole by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer programs may also include and / or rely on stored data. Examples, without limitation, of the non-transitory tangible computer-readable medium include non-transitory memory, volatile memory, magnetic mass storage, and optical mass storage.

Claims

[1] Procedure which includes: a first content file and a first instruction file (XML1) are received from a development network (14), the first instruction file (XML1) containing a first parameter set, the first parameter set comprising a part number of the first content file, a part usage value, and a part type of the first content file; on the basis of the first instruction parameter set, a second parameter set is determined and a second instruction file (XML2) is generated which comprises the second parameter set; the first content file and the second parameter set are transmitted to a signature server (18); a signature file is received from the signature server (18), the signature file containing a signature (SIG 166), and the signature server (18) generating the signature file based on the second instruction file (XML2); the signature (SIG 166) is integrated into the first content file to create a second content file; the second content file is downloaded to a service server (20), a manufacturing server (22) and / or a supplier network; determining whether a target vehicle control module allows the server to select a signing key based on the part usage value; determining whether the first content file is a calibration file, a software file, a firmware file, a boot file, a key exchange file, or a license file based on the part type; and the second instruction file (XML2) is generated based on the part number, part usage value and part type. [2] The method of claim 1, further comprising generating the signature (SIG 166) based on the key identifier (ID), wherein: the first parameter set contains the key identifier (ID); and the second parameter set contains the key identifier (ID). [3] The method of claim 1, wherein the first instruction file (XML1), the second instruction file (XML2) and the second content file are extensible markup language (XML) files. [4] The method of claim 1, further comprising storing the signature (SIG 166) upon creating the second content file based on a first address and a second address, wherein the first set of parameters comprises: the first address of the signature; and the second address of a signature algorithm. [5] The method of claim 1, further comprising: a key is embedded in a boot file based on an address; and the boot file is exported for use by a vehicle control module, where the first set of parameters includes the address of the key, and wherein the boot file contains instructions which, when executed by the vehicle control module, verify the signature (SIG 166) based on the key. [6] The method of claim 1, further comprising: the second instruction file (XML2) is generated based on a producer ID and a certificate; and the second content file is generated based on the certificate, where the first set of parameters includes: the creator identifier, which indicates a person who created the first content file, and the certificate, which specifies a key to be used to validate the signature (SIG 166) and vehicle control modules that should use the second content file. [7] The method of claim 1, wherein: the second set of parameters includes: a job identifier that specifies a number of a job request containing the first content file and the second instruction set, a key identifier that specifies a key that the signature server (18) should use to generate the signature (SIG 166), and a signature algorithm identifier that specifies a signature algorithm that the signature server (18) should use to generate the signature (SIG 166); and the third set of parameters includes: a job identifier that specifies a number of a job request that contains the first content file and the second instruction set, and the signature.

Images