MULTIPLE-STAGE SECURE VEHICLE SOFTWARE UPDATING

• US 20170060559A1
• Filed: 08/25/2015
• Published: 03/02/2017
• Est. Priority Date: 08/25/2015
• Status: Active Grant

• Current Assignee: Ford Global Technologies, LLC (Ford Motor Company)
• Original Assignee: Ford Global Technologies, LLC (Ford Motor Company)
• Inventors: YE, Xin, CAUSHI, Aldi, BIELAWSKI, John R. Jr., WESTRA, Michael Raymond
• Granted Patent: US 9,916,151 B2
• Time in Patent Office: Days
• US Class Current: 1/1
• CPC Class Codes: G06F 21/44 Program or device authentication
• CPC Class Codes: G06F 21/572 Secure firmware programming, e.g. of basic input output system [BIOS]
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57
• CPC Class Codes: G06F 9/4401 Bootstrapping security arrangements therefor G06F21/57
• CPC Class Codes: H04L 2209/84 Vehicles
• CPC Class Codes: H04L 2463/121 Timestamp cryptographic mechanisms or cryptographic arrangements involving time stamps H04L9/3297
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 63/0823 using certificates cryptographic mechanisms or cryptographic arrangements for entity authentication involving certificates H04L9/3263
• CPC Class Codes: H04L 63/12 Applying verification of the received information cryptographic mechanisms or cryptographic arrangements for data integrity or data verification H04L9/32
• CPC Class Codes: H04L 67/12 specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
• CPC Class Codes: H04L 67/34 involving the movement of software or configuration parameters network booting or remote initial program loading [RIPL] G06F9/4416
• CPC Class Codes: H04L 9/30 Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
• CPC Class Codes: H04L 9/3247 involving digital signatures
• CPC Class Codes: H04W 12/08 Access security
• CPC Class Codes: H04W 12/10 Integrity
• CPC Class Codes: H04W 12/35 Protecting application or service provisioning, e.g. securing SIM application provisioning
• CPC Class Codes: H04W 12/61 Time-dependent
• CPC Class Codes: H04W 12/71 Hardware identity
• CPC Class Codes: H04W 4/44 for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Abstract

A vehicle may receive a software update to be installed to a vehicle electronic control unit (ECU). The vehicle ECU may download a software update received from a server to a first storage; generate a nonce value associated with the software update; send to the server, a swap authorization request including the generated nonce value; receive a swap authorization including the nonce value and a command-and-control signature from the server; validate the signature and the nonce value from the swap authorization; and reboot using the first storage instead of a second storage when the recovered nonce value matches the generated nonce value.

Claims

1. A system comprising:

a first storage;

a second storage; and

a vehicle electronic control unit (ECU), programmed to

download a software update received from a server to the first storage,

generate a nonce value associated with the software update,

send, to the server, a swap authorization request including the nonce value,

receive a swap authorization including the nonce value recovered from the server, and

reboot using the first storage instead of the second storage when the nonce value generated by the ECU matches the nonce value recovered from the server.

2. The system of claim 1, wherein the vehicle ECU is further programmed to confirm the first storage as being active for booting instead of the second storage, responsive to the vehicle ECU successfully booting to the first storage.

3. The system of claim 1, wherein the swap authorization includes a signature signed using a private key of the server, and the vehicle ECU is further programmed to verify the signature using a public key installed to the vehicle ECU.

4. The system of claim 1, wherein the vehicle ECU is further programmed to:

receive a signature of the software update from the server; and

verify authenticity of the software update using the signature and a key installed to the vehicle ECU.

5. The system of claim 4, wherein the key is one of a public key corresponding to a private key with which the software update is signed, or a symmetric key with which the software update is signed.

6. The system of claim 1, wherein the vehicle ECU is further programmed to discard the software update when the nonce value recovered from the server fails to match the nonce value as generated.

7. The system of claim 1, wherein the vehicle ECU is further programmed to apply the software update to the first storage while the vehicle ECU executes a software installation to the second storage of the vehicle ECU.

8. The system of claim 1, wherein the nonce value includes at least one of a randomly-generated value, an incremented counter value, a unique-per-module serial number of the ECU, a time stamp, or a hash value of the software update.

9. The system of claim 8, wherein the nonce value includes the time stamp concatenated to the hash value of the software update.

10. A system comprising:

a nonce value; and

a server programmed to

send a software update to a vehicle,

receive, from the vehicle, a swap request including the nonce value and a hash value of the software update, and

responsive to the swap request, send a swap authorization command to the vehicle, the swap authorization command including the nonce value and indicating whether the vehicle is authorized to swap to execution of the software update.

11. The system of claim 10, further comprising a data store programmed to maintain software updates, wherein the server is further programmed to retrieve the software update from the data store.

12. The system of claim 10, wherein the server is further programmed to:

generate a signature using at least one of a private key matched to a public key stored by the vehicle or a symmetric key stored by the vehicle; and

include the signature with the swap authorization command.

13. The system of claim 10, wherein the server is further programmed to:

retrieve a hash value corresponding to the software update from a database; and

determine whether the hash value of the software update is a match by comparing the hash value of the swap request to the hash value from the database.

14. The system of claim 10, wherein the nonce value includes at least one of a randomly-generated value, an incremented counter value, a unique-per-module serial number of an electronic control unit to which the software update is to be applied, a time stamp, or a hash value of the software update.

15. The system of claim 14, wherein the nonce value includes the time stamp concatenated to the hash value of the software update.

16. A method for over-the-air software updates comprising:

generating a first nonce for a software update downloaded from a server to an electronic control unit (ECU);

sending, to the server, a swap authorization request including the first nonce;

receiving, from the server, a swap authorization including a second nonce;

recovering the second nonce; and

rebooting the ECU to utilize the software update when the first nonce matches the second nonce.

17. The method of claim 16, further comprising confirming a first storage as being active for booting instead of a second storage, responsive to the ECU successfully booting to the first storage.

18. The method of claim 16, wherein the software update includes a differential of updates to be applied to a software install of the ECU, and further comprising applying the software update to the software install responsive to rebooting the ECU when the first nonce matches the second nonce.

19. The method of claim 16, wherein the swap authorization includes a signature, and further comprising verifying the signature using a key installed to the ECU.

20. The method of claim 16, further comprising:

receiving a signature of the software update; and

verifying authenticity of the software update using the signature and a key installed to the ECU.

21. The method of claim 16, further comprising discarding the software update when the second nonce from the swap authorization fails to match the first nonce.

22. The method of claim 16, further comprising applying the software update to a first storage operating as an inactive storage while the ECU executes a software installation to a second storage acting as an active storage of the ECU.

23. The method of claim 16, further comprising generating the first nonce using at least one of a randomly-generated value, an incremented counter value, a unique-per-module serial number of the ECU, a time stamp, or a hash value of the software update.

24. The method of claim 23, wherein the first nonce includes the time stamp concatenated to the hash value of the software update.