Secure programming of vehicle modules

Abstract

Method (200) for programming a vehicle module (60) comprising the steps that: (a) a credential medium (30) is provided which contains multiple secure credentials; (b) the authorization medium (30) is used in an authorization programming device (40; 140) to program multiple vehicle modules (60); (c) the status of the vehicle module programming is recorded in the authorization medium (30); and (d) in the event of a programming failure, the authorization medium (30) is used in a secondary authorization programming device (70; 170) to program a vehicle module (60).

Description

TECHNICAL FIELD

[0001] The present invention relates generally to vehicle module programming and in particular to methods for the safe programming of vehicle modules. BACKGROUND

[0002] When programming a large number of vehicle modules (e.g., thousands or millions of such modules) with uniquely identifying parameters, there is always the possibility of one or more modules being programmed with the same parameters. For example, after a programming system stop due to a system failure, a programming device might unintentionally restart the programming of the next vehicle module with previously programmed module parameters, or at least fail to recognize at which stage the programming system stopped. Furthermore, it is always necessary to minimize or prevent fraudulent programming of vehicle modules.

[0003] Document US 2008 / 0320471A1 discloses a download system for system programs in which a portable storage medium with a device identifier is provided for each control device to be programmed. A download module containing a verification code is loaded onto this medium. Software contained in the download module is installed only if the verification code matches the device identifier of the control device.

[0004] Publication WO 2007 / 079 110 A2 discloses a method for programming a vehicle module and for correcting errors that may occur during the process. This method includes a programming device containing a program intended for installation in the vehicle module. During installation, restore points are used to first back up critical data from the vehicle module, then the program is installed, and finally the critical data is restored. In case of installation errors, the installation process is restarted from the last restore point used.

[0005] The object of the invention is to program a large number of vehicle modules without the risk of omitting or duplicating any particular set of credentials for the vehicle modules.

[0006] This problem is solved by a method for programming a vehicle module according to claim 1. SUMMARY OF THE INVENTION

[0007] According to one aspect of the invention, a method for programming a vehicle module is provided. The method comprises the steps of: (a) providing an authorization medium containing multiple secure authorizations; (b) using the authorization medium in an authorization programming device to program multiple vehicle modules; (c) recording the status of the vehicle module programming in the authorization medium; and (d) in the event of a programming failure, using the authorization medium in a secondary authorization programming device to program a vehicle module.

[0008] According to a further aspect of the invention, a method for programming a vehicle module is provided. The method comprises the steps of: (a) providing an authorization medium containing multiple secure authorization credentials; (b) using the authorization medium in an authorization programming device to program multiple vehicle modules; (c) updating the status of a vehicle module programming each time a vehicle module is programmed using one of the authorization credentials; and (d) in the event of a programming failure, using the authorization medium in a secondary authorization programming device to program a vehicle module. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Preferred exemplary embodiments of the invention are described below in conjunction with the accompanying drawings, in which the same reference numerals denote the same elements, and wherein: Fig. 1 is a block diagram showing an exemplary embodiment of a programming system that can use the method disclosed herein; Fig. 2 is a block diagram showing a second exemplary embodiment of a programming system that can use the method disclosed herein; and Fig. 3 is a flowchart showing an embodiment of a method for safely programming a vehicle module. DETAILED DESCRIPTION OF PREFERRED EXECUTION FORMS

[0010] The systems and methods described below address various embodiments of an approach for programming a vehicle module. The disclosed methods provide a programming mechanism consisting of providing an authorization medium containing multiple secure credentials. Subsequently, an authorization programming device programs multiple vehicle modules using the authorization medium. During each stage of vehicle module programming, the programming status in the authorization medium is securely updated. In the event of a programming failure, the authorization medium is used in a secondary authorization programming device to program the vehicle modules.This approach allows the system to securely track the status of the vehicle module programming, so that if there is a failure requiring the use of a different programming computer, the credential medium can be easily moved to another computer to continue programming without the risk of omitting or duplicating any particular set of credentials from the medium.

[0011] Referring to Fig. Figure 1 shows an exemplary programming system 10 that can be used to implement the methods disclosed herein. The programming system 10 generally comprises an authorization certificate generator 20, an authorization certificate medium 30, an authorization certificate programming device 40, one or more additional programming devices 50, one or more vehicle modules 60, and a secondary programming device 70. It should be noted that the disclosed method can be used with any number of different systems and is not specifically limited to the operating environment shown here. Furthermore, the architecture, design, construction, and operation of the system 10 and its individual components are widely known in the art.Thus, the following paragraphs provide only a brief overview of such an exemplary system 10; however, other systems not shown here could also employ the disclosed methods.

[0012] The credential generator 20 can be one of several computers accessible via a private or public network, such as the Internet. It can be used for one or more purposes, such as generating the credential medium 30. It can be implemented using any suitable type of computer (e.g., a desktop or laptop computer) and include any cryptographic tool, including a programming interface for a cryptographic application. Besides a computer, other types of credential generators 20 can be used. For example, a third-party credential authority can be used to generate the credential medium 30.

[0013] The authentication medium 30 is a computer-readable medium and can be any of a number of different storage media. Its main uses are storage and the ability to be updated by the authentication programming device 40 or other devices. A list of possible authentication media 30 includes Digital Versatile Disc (DVD) (e.g., DVD-RW, DVD+RW, DVD-RAM), high-definition media (e.g., Blu-ray, HD DVD), Compact Disc (CD) (e.g., CD-RW), Universal Serial Bus (USB) (e.g., USB flash drive), memory card (e.g., security card), external hard drive, data tape, floppy disk, etc. The above list is by no means a complete list of all possible authentication media 30, but merely provides some examples, as others will be obvious to experts.

[0014] The credential programming device 40 can be any type of device capable of reading and updating the medium 30 and processing electronic instructions, including computers, microprocessors, microcontrollers, host processors, controllers, and application-specific integrated circuits (ASICs). It can also be referred to as an injector, in the sense that it is used to inject or feed credentials into the system for use in programming a vehicle module. It can be a dedicated programming device used only for vehicle modules 60, or it can be used with other vehicle systems.The authorization programming device 40 executes various types of digitally stored instructions, such as software or firmware programs stored within it, which enable the programming of vehicle modules 60. For example, the authorization programming device 40 can communicate with the additional programming device 50 and can execute programs or process data to perform at least part of the procedure described herein.

[0015] The additional programming device 50 can be any type of device capable of programming the vehicle module 60. It can be operated automatically by the authorization-based programming device 40, by digitally stored instructions within the programming device 50, etc. It can also be operated manually and, in this case, can take the form of a computer terminal or an interface that executes a programming application. The additional programming device 50 can be connected to the module 60 via a connection cable (e.g., serial, USB, Ethernet, etc.) or wirelessly. Other options are possible; for example, in one embodiment, the module 60 can be housed within the additional programming device 50 while being programmed.

[0016] Vehicle module 60 encompasses any vehicle module located within a vehicle. For example, a vehicle module could be a telematics unit that enables wireless voice and / or data transmission over a wireless carrier system and a wireless network, allowing the vehicle to communicate with a call center, other telematics-enabled vehicles, or any other entity or facility. Another vehicle module could be an engine control module (ECM), which controls various aspects of engine operation, such as fuel injection and ignition timing.Another vehicle module could be a powertrain control module, which regulates the operation of one or more components of the vehicle's powertrain, and another could be a body control module, which monitors various electrical components located on the vehicle, such as the central locking system and the vehicle's headlights. As experts will recognize, the vehicle modules mentioned above are merely examples of some of the modules that can be used in System 10 or 100, as numerous others are possible. Furthermore, it should be noted that at least some of the aforementioned modules could be implemented as software instructions stored in a vehicle (not shown), or they could be hardware components located in the vehicle or a vehicle module (e.g., chip, EEPROM, flash memory, PAL, etc.), to name just a few possibilities.

[0017] Fig. Figure 2 shows a second exemplary programming system 100 that can be used to implement the methods disclosed herein. The programming system 100 generally comprises the authorization certificate generator 20, the authorization certificate medium 30, an authorization certificate programming device 140, one or more vehicle modules 60, and a secondary programming device 170. System 100 is similar to system 10 except that the programming device 140 of system 10 combines both programming devices 40 and 50 of system 10. Similarly, the secondary programming device 170 of system 100 combines both programming devices 50 and 70 of system 10. Thus, in system 100, the module 60 is programmed directly via either the programming device 140 or 170.

[0018] Now on Fig. 3. With reference to this, a method 200 for programming a vehicle module is shown. The method 200 begins at step 202 and starts by generating the medium 30 of secure credentials. There are several ways to generate the credential medium 30, including internal generation, generation by a third party, or any combination thereof. In one embodiment, the medium 30 is generated internally by an original equipment manufacturer (OEM) or an OEM supplier using any suitable cryptographic tool that includes a programming interface of a cryptographic application. In a second embodiment, the medium 30 is generated by a third party, which includes an application service provider, a managed service provider, etc.In any case, one or more cryptographic techniques can be used, including public-key cryptography (e.g., asymmetric public-private key, symmetric private key, etc.), strong authentication, and one- or multi-factor authentication (i.e., at least one factor or a combination of "something you know," "something you have," and "something you are") (e.g., one-factor authentication, two-factor authentication (T-FA), etc.). A list of factors that can be used includes tokens (e.g., virtual and / or physical tokens), smart cards, USB drives, biometrics, magnetic stripe cards, phones, SMS messages, passwords, etc. Therefore, in addition to generating the medium 30 with or without its own embedded security factors, one or more additional factors can also be generated.In one embodiment, the medium 30 is generated with software or firmware that prompts a user to enter a password or provide biometric data. In another embodiment, the medium 30 is generated in conjunction with a USB drive, which is necessary to operate the medium 30. Those skilled in the art will recognize that other techniques can be used. The generated credentials include a digital certificate, one or more keys (e.g., private key, public key, etc.), telephone numbers (e.g., mobile phone numbers), identifiers (e.g., module serial number, vehicle identification number (VIN)), etc.This collection of credentials can be logically related and grouped in one or more tables or any other format contained in one or more files and aggregated in one or more databases. For example, in one embodiment, the data can be related as a separate set of credentials for each separate module (e.g., digital certificate, security key, phone number, VIN, etc.). In a second embodiment, the data can be related as sets of a similar data type (e.g., Set 1 - List of digital certificates, Set 2 - List of security keys, Set 3 - List of phone numbers, Set 4 - List of VINs, etc.).

[0019] After generation, the credential medium 30 is inserted into the primary injector 40 as specified in step 203. Next, in step 204, the primary injector 40 reads a (next) selected set of credentials from the credential medium 30. The set of credentials includes any data to be programmed into a vehicle module 60. It may also include the necessary security data to maintain the security aspect of the process. In one embodiment, the set of credentials includes a key certificate (e.g., X.509), a private key, a shared key, a telephone number, and a serial number. In procedure 200, the next time the process loops back to step 204, the next set of credentials is read from the credential medium 204.

[0020] In step 206, the validity of the selected credentials is verified. In one embodiment, the primary injector 40 can verify the validity of the credentials. One or more checks can be performed here, including verification of completeness (i.e., does the set include all credentials?), accuracy (e.g., is each credential complete and does it contain all its alphanumeric characters?), uniqueness (e.g., is the corresponding credential unique and has it not been used previously?), and / or other checks. This can involve the use of one or more digital certificates to ensure the confidentiality and / or authenticity of the credentials. If the credentials are valid, procedure 200 proceeds to step 208. However, if the credentials are not valid, procedure 200 proceeds to step 216.Both steps are explained below.

[0021] If the selected credentials are valid (step 208), the primary injector 40 updates the credential medium 30. In this step, the procedure 200 tracks which set of credentials is being used. Thus, if the process stops in this step, a user can efficiently and promptly identify which set of credentials to use next. Furthermore, tracking which set of credentials is being used provides transparency into the process and its performance. This tracking of the current credentials can be done via a receipt written to the credential medium 30; for example, by writing the set of selected credentials currently in use (or a unique identifier thereof) to the medium 30 (e.g., in a separate file).This receipt can also include a list of all credentials used to date. The primary injector 40 can also digitally sign the receipt using a message authentication code (MAC), which may include, among others, a keyed-hashed message authentication code (HMAC or KHMAC), such as HMAC-MD (e.g., MD4, MD5, etc.) or HMAC-SHA (e.g., SHA-0, SHA-1, SHA-2, SHA-3, etc.). In one embodiment, the primary injector 40 digitally signs the receipt confirming that the selected set of credentials is being used, employing HMAC-SHA-256. A person skilled in the art will recognize that other message authentication codes can be used.

[0022] Later, the primary injector 40 sends the selected credentials to the additional programming device 50 (step 210). The credentials can be sent automatically from the injector 40 to the additional programming device 50 over a network, or an operator can perform this task by issuing a command via the injector 40 to send the credentials to the additional programming device 50. The additional programming device 50 then programs the module 60 in step 212 with the selected credentials. However, during this step and any other steps, even though the explanation only covers one module and one additional programming device, multiple modules and additional modules can be used.In one embodiment, several additional programming devices are used, but each additional programming device programs only one module at a time. In a second embodiment, one additional programming device programs several modules at a time. These are just a few options, as others are possible. There are various programming strategies that can be employed. In one embodiment, the additional programming device 50 attempts to program module 60 once, and this does not depend on the result of the programming status of module 60, with the method 200 then later proceeding to the next step 214. In another embodiment, the additional programming device 50 can attempt to program module 60 several times if it detects a programming failure (e.g.,one or more unprogrammed credentials) before the procedure 200 proceeds to the next step 214. The programming period may be limited by a time period during which, in the event of a programming failure, several attempts are made until a certain time period has elapsed. In another embodiment, the programming period in the event of a programming failure is limited by the number of programming attempts. These are only a few examples, as others are possible, for instance, using a combination of a number of attempts and a maximum programming time period.

[0023] Next, in step 214, the additional programming device 50 sends a programming status to the primary injector 40. The status can be either a pass or a fail status. The pass status can be set if the programming of module 60 is successful. The fail status can be set if it is determined that the programming of module 60 is unsuccessful. Among other things, this step provides process transparency for procedure 200, enabling a user or third party to easily monitor, evaluate, correct, and / or improve system 10.

[0024] In step 216, the primary injector 40 records and captures the programming status of module 60. In this stage, the injector 40 also records and captures the programming status of module 60 received from the additional programming device 50 (e.g., number passed, number failed, etc.). Furthermore, it records and captures the invalid authorization credential status from step 206. Recording successful programming (pass status) can be achieved by securely writing to the authorization medium 30, either with the actual authorization credentials that were just successfully programmed, or with a unique indicator indicating this, and / or with a list of all authorization credentials that have been successfully programmed to date. This confirmation can be digitally signed for authentication purposes.

[0025] In step 218, the failure status of the primary injector 40 is checked. The status can be either a failure or no failure (success). A failure can be determined by one or more factors, including a count of invalidly selected credentials returned by the primary injector 40, a predetermined number of invalidly selected credentials returned by the primary injector 40, an inability of the primary injector 40 to communicate with the programming device 50, the medium 30, or other devices, etc. The failure status can also include a failure status of one or more additional programming devices 50, as described previously.In the event of a failure, procedure 200 continues with step 220, in which the credential medium 30 is used in another injector, such as injector 70, which becomes the primary injector. Procedure 200 then loops back to step 204, where injector 70 reads the next selected set of credentials from credential medium 30. However, if there is no failure status, injector 40 updates the credential medium to indicate that module 60 has been successfully programmed and securely signs the communication. Procedure 200 then loops back to step 204, where injector 40 reads the next selected set of credentials from credential medium 30.

[0026] When the system switches to the secondary programming device 70 in step 220, this secondary injector accesses the credential medium 30 and determines the point at which successful programming by the primary injector ended. The secondary injector can then proceed with the first set of credentials that were not successfully programmed by the primary injector. This process can be automated through appropriate programming of the secondary injector 70. For example, the secondary injector can read the digitally signed file from medium 30 that identifies the most recently used credentials and, based on this, proceed to step 204 using the first set of unused credentials from medium 30.

[0027] Method 200 can be used with a few modifications in System 100, which is in Fig.Figure 2 shows a second exemplary embodiment of a programming system that can program a vehicle module. In this case, the primary injector 140 programs the vehicle module 60 in addition to reading and updating the authorization credentials 30. Thus, steps 210 and 214 are omitted, and step 212 is performed by the primary injector 140. In case of failure, the secondary injector 170 replaces the injector 140.

[0028] It should be noted that the foregoing description is not a definition of the invention, but rather a description of one or more preferred exemplary embodiments of the invention. The invention is not limited to the specific embodiment(s) disclosed herein, but is instead defined only by the claims below. Furthermore, the statements contained in the foregoing description refer to specific embodiments and should not be considered as limitations on the scope of protection of the invention or on the definition of terms used in the claims, unless a term or phrase is expressly defined above. Various other embodiments and various modifications and variations of the disclosed embodiment(s) will be apparent to those skilled in the art.All other embodiments, modifications and adaptations shall be within the scope of protection of the attached claims.

[0029] As used in this description and in the claims, the terms "for example," "such as," "like," and "as," and the verbs "comprise," "exhibit," "include," and their other verb forms, when used in conjunction with a list of one or more components or one or more other elements, shall each be considered to have an open end, meaning that the list shall not be considered to exclude other, additional components or elements. Other terms shall be considered to encompass their broadest reasonable meaning unless used in a context requiring a different interpretation.

Claims

[1] A method (200) for programming a vehicle module (60), comprising the steps of: (a) providing a credential medium (30) containing a plurality of secure credentials; (b) the credential medium (30) is used in a credential programming device (40; 140) to program a plurality of vehicle modules (60); (c) the status of the vehicle module programming is recorded in the credential medium (30); and (d) in the event of a programming failure, the credential medium (30) is used in a secondary credential programming device (70; 170) to program a vehicle module (60). [2] The method (200) of claim 1, wherein the secure credentials comprise a unique serial number. [3] The method (200) of claim 1, wherein the secure credentials comprise a mobile phone number. [4] The method (200) of claim 1, wherein the credential medium (30) is an optical disk storage medium comprising a digital versatile disc (DVD), a compact disc (CD), or a high-definition disc. [5] The method (200) of claim 1, wherein the credential medium (30) is a Universal Serial Bus (USB) storage medium comprising either a flash drive or a hard drive. [6] The method (200) of claim 1, wherein the credential programming device (40; 140) is a computer programmed to perform at least steps (b) and (c). [7] The method (200) of claim 1, wherein steps (b) and (c) together further comprise the steps of: i) reading some selected credentials from the credential medium (30) by the credential programming device (40; 140), ii) validating the selected credentials, iii) updating the credential medium (30) with an acknowledgment that the selected credentials are being used, iv) sending the selected credentials to an additional programming device (50), v) programming the vehicle module (60) with the selected credentials using the additional programming device (50), vi) sending the status of the vehicle module programming to the credential programming device (40;140) is sent, and vii) the status is recorded by updating the credential medium (30) with a confirmation indicating whether the selected credentials have been successfully programmed or not.; [8] The method (200) of claim 7, wherein step (iii) further comprises the step of securely signing the receipt update for the credential medium (30), and wherein step (vii) further comprises the step of securely signing the confirmation update for the credential medium (30). [9] The method (200) of claim 1, wherein step (d) further comprises determining whether a number of programming failures exceeds a preselected value and, if so, using the secondary credential programming device (70; 170). [10] The method (200) of claim 1, wherein step (b) further comprises using an additional programming device (50) to program the vehicle modules (60).

Images