Secure key distribution

Abstract

The present disclosure provides "secure key distribution". Communication between computing devices connected via a network may be protected with a digital key (e.g., a cryptographic key). The key may be updated based on the state of the state machine. The computing device may receive a key update command to update the key value. In response to the key update command, the computing device may update the key value when it is determined based on state data defining a first state that the computing device is in the first state, the state data includes the key value, a machine mode specifying a current operating environment, and a lock value specifying that a memory storing the key value is one of locked or unlocked.

Description

Technical Field

[0001] The present disclosure relates to techniques for managing, distributing, and / or updating security keys to computing devices via a network. Background Art

[0002] Communications between computing devices connected via a network can be protected using digital keys (e.g., encryption keys). For example, a device can use an encryption key to encrypt communications sent to another device over the network, and / or can use the encryption key or a specific encryption key to decrypt communications received from another device over the network. Security keys can be initially installed or deployed (e.g., security keys in a device can be updated from a default or initial security key). Alternatively or additionally, security keys can be updated from time to time. Summary of the Invention

[0003] In the non-limiting examples discussed herein, the computing device is an electronic control unit (ECU) connected to a network in a vehicle. The computing devices can communicate with each other based on stored security keys. For example, communications encrypted with the security keys can be sent via a vehicle communication bus. As described herein, a corresponding device such as an ECU can manage security keys, including the installation and / or updating of security keys, by maintaining a state machine that determines whether the state of the device allows and / or warrants updating the security keys (e.g., from a default security key and / or from a previously installed or updated security key). As described in more detail below, the state machine can track properties of the computing device, including whether it is in a locked state or an unlocked state, whether it is in an initial mode or an in-service mode, and / or whether the security key value is a default value or a previously assigned or installed value, to determine whether the device is in a state to update the security key, install the security key, and / or restore the security key to the default value.

[0004] Accordingly, the present disclosure includes a system comprising a computing device including a processor and a memory storing instructions executable by the processor, the instructions including instructions for receiving a key update command to update a key value, and in response to the key update command, updating the key value upon determining that the computing device is in a first state based on state data defining the first state, the state data including the key value, a machine mode specifying a current operating environment, and a lock value specifying whether a memory storing the key value is one of locked or unlocked.

[0005] After the key value is updated, a transition to the second state may be made.

[0006] The computing device may be permitted to authenticate communications using the key value based on the second state.

[0007] The machine mode may be changed from a first state to a second state.

[0008] The first state may be a default state, and the key value in the default state may be a default value.

[0009] The computing device may be configured to communicate with a second computing device via a network.

[0010] The gateway computing device may be configured to provide a key update command to the computing device via the network.

[0011] The gateway may be further configured to provide the key update command based on determining that the computing device is in the first state.

[0012] The computing device may be an electronic control unit (ECU) of the vehicle.

[0013] A transition may be made from the error state to the first state.

[0014] A method includes receiving a key update command to update a key value, and in response to the key update command, updating the key value when a computing device is determined to be in a first state based on state data defining the first state, the state data including the key value, a machine mode specifying a current operating environment, and a lock value specifying whether a memory storing the key value is one of locked or unlocked.

[0015] After the key value is updated, a transition to the second state may be made.

[0016] The computing device may be permitted to authenticate communications using the key value based on the second state.

[0017] The machine mode may be changed from a first state to a second state.

[0018] The first state may be a default state, and the key value in the default state may be a default value.

[0019] The computing device may be configured to communicate with a second computing device via a network.

[0020] The gateway computing device may be configured to provide a key update command to the computing device via the network.

[0021] The gateway may be further configured to provide the key update command based on determining that the computing device is in the first state.

[0022] The computing device may be an electronic control unit (ECU) of the vehicle.

[0023] A transition may be made from the error state to the first state. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a block diagram of an exemplary vehicle.

[0025] Figure 2 An exemplary device network is shown.

[0026] Figure 3 is a state diagram illustrating a state machine for key distribution.

[0027] Figure 4 is a process flow diagram of an exemplary process for a computing device to operate over a network according to a state machine.

[0028] Figure 5 is a process flow diagram illustrating an exemplary process for managing key distribution according to a state machine. DETAILED DESCRIPTION

[0029] Figure 1 1 is a block diagram of a vehicle system 100. Vehicle 102 includes computing devices 104, 106, 108, including a security manager 104, one or more control devices 106, and / or a gateway 108. For example, control device 106 may be an electronic control unit (ECU). Each computing device 104, 106, 108 may have a memory containing instructions executable by computing device 104, 106, 108 to implement processes and operations, including those described herein. Computing devices 104, 106 may be communicatively coupled to gateway 108, sensors 110, and vehicle subsystems 112 (such as a powertrain controller, steering controller, etc.) via a communication network (such as a vehicle network 114). Vehicle 102 may be any passenger or commercial vehicle, such as a sedan, truck, sport utility vehicle, crossover, van, minivan, taxi, bus, etc.

[0030] Each computing device 104, 106, 108 includes a processor and memory. The memory includes one or more forms of computer-readable media and stores instructions that are executable by the processor to perform various operations, including those disclosed herein. For example, the control device 106 may be a general-purpose computer having a processor and memory as described above, and / or may include an electronic control unit (ECU) or controller for a specific function or set of functions, and / or dedicated electronic circuitry, including an ASIC (application-specific integrated circuit) manufactured for a specific operation (e.g., an ASIC for processing and / or transmitting sensor data). In another example, the computing devices 104, 106, 108 may include an FPGA (field programmable gate array), which is an integrated circuit manufactured to be user-configurable. Typically, hardware description languages ​​such as VHDL (Very High Speed ​​Integrated Circuit Hardware Description Language) are used in electronic design automation to describe digital and mixed-signal systems such as FPGAs and ASICs. For example, an ASIC is manufactured based on VHDL programming provided before manufacturing, while the logic components within the FPGA can be configured based on VHDL programming (e.g., stored in a memory electrically connected to the FPGA circuitry). In some examples, a combination of processors, ASICs, and / or FPGA circuits may be included in computing devices 104 , 106 , 108 .

[0031] The memory includes any suitable type of memory known in the art. The memory may be a hard drive, a solid-state drive, a server, or any volatile or non-volatile medium. The memory may include a device separate from the computing devices 104, 106, 108, and the computing devices 104, 106, 108 may retrieve information stored by the memory via a network 114 in the vehicle 102 (e.g., via a CAN bus, a wireless network, etc.). Alternatively or in addition, the memory may be part of the computing devices 104, 106, 108 (e.g., as memory of the computing devices 104, 106, 108).

[0032] The computing devices 104 , 106 , 108 may include one or more processors (e.g., included in components (such as sensors 110 , control devices 106 , such as electronic control units (ECUs), etc.) included in the vehicle 102 for monitoring and / or controlling various vehicle components or subsystems 112 (e.g., powertrain controller, steering controller, etc.)), or be communicatively coupled to the one or more processors (e.g., via a vehicle network 114 , such as a communication bus, as further described below). The computing devices 104 , 106 , 108 are typically arranged to communicate over the vehicle communication network 114 , which may include a bus in the vehicle 102 , such as a controller area network (CAN), etc., and / or other wired and / or wireless mechanisms. Alternatively or additionally, where the computing devices 104 , 106 , 108 actually include multiple devices, the vehicle communication network 114 may be used for communication between the devices represented in this disclosure as computing devices 104 , 106 , 108 . Additionally, as mentioned below, various controllers and / or sensors 110 may provide data to the computing devices 104 , 106 , 108 via the vehicle communication network 114 .

[0033] Computing devices 104, 106, 108 may transmit messages to and / or receive messages from various devices in vehicle 102 (including sensors 110; actuators; other computing devices 104, 106, 108; and the like) via vehicle network 114. Various controllers and / or sensors 110 may provide data to computing devices 104, 106, 108 via vehicle network 114. Vehicle network 114 may be one or more of a combination of wired and / or wireless networks, such as a CAN (Controller Area Network) bus and / or may also include Ethernet, Wi-Fi, and the like.

[0034] Vehicle 102 may include a security manager 104 for monitoring communications between control devices 106 and remote access devices 116 and for controlling the operation of vehicle subsystems 112. Security manager 104 may include a processor and a memory storing instructions executable by security manager 104, and may be communicatively coupled to control devices 106 and vehicle subsystems 112 via vehicle network 114. Security manager 104 may communicate (e.g., exchange messages) with control devices 106. That is, security manager 104 may forward instructions to control devices 106 to, for example, activate vehicle subsystems 112. Security manager 104 may require control devices 106 to authenticate themselves to security manager 104. When authentication of at least one of control devices 106 fails, security manager 104 may "immobilize" vehicle 102 by disabling operation of vehicle subsystems 112. For example, when authentication of some control devices 106 fails, security manager 104 may prevent activation of the ignition system in vehicle 102.

[0035] As described above, the security manager 104 can be configured to communicate wirelessly with the remote access device 116. For example, the security manager 104 and the remote access device 116 can communicate wirelessly using a wireless protocol such as WiFi or Bluetooth. An exemplary communication from the remote access device 116 to the security manager 104 is a request to activate a vehicle subsystem 112, such as activating the vehicle ignition or propulsion, unlocking the doors, etc. The security manager 104 can forward the request to the control device 106 so that the control device 106 can activate the vehicle subsystem 112 based on the request.

[0036] As described above, the security manager 104 can communicate with the computing devices 106 and 108. Communications between the security manager 104 and the computing devices 106 and 108 can be encrypted using a security key. That is, the security key value can be used to encrypt the communications according to a stored algorithm, such that the communications cannot be deciphered without access to the security key. The security manager 104 and the computing devices 106 and 108 can store the security key to encrypt or decrypt communications.

[0037] Authentication of messages in computing devices 104, 106, 108 (such as control device 106) can employ various suitable mechanisms, such as a message authentication code (MAC) (sometimes also referred to as a message integrity code or MIC). MAC authentication can include inputting a security key and a message into a signature algorithm to output a tag; a verification algorithm can then use the tag and the security key as input to verify that the message is authentic (or be rejected). MAC authentication can be used with a cipher-based message authentication code (CMAC). As will be appreciated, CMAC authentication can include a block cipher.

[0038] The security manager 104 can communicate with a remote access device 116. The remote access device 116 is a device that can be configured to communicate wirelessly with the security manager 104 (e.g., via Bluetooth). The remote access device 116 can be any device suitable for wireless communication with the security manager 104. The remote access device 116 can be a dedicated device (e.g., a key fob, such as an RFID device). Additionally or alternatively, the remote access device 116 can be a portable computing device, such as a smartphone. The remote access device 116 can be actuated by the vehicle operator to send commands to the security manager 104 to actuate the vehicle subsystems 112. As an example, the remote access device 116 can send a command via the security manager 104 instructing the control device 106 to unlock the vehicle doors. The remote access device 116 can store a security key shared between the control devices 106, enabling the security manager 104 to authenticate the remote access device 116 when the remote access device 116 sends communications to the security manager 104. The remote access device 116 can be detected by sensors 110 within the vehicle 102. Based on detecting the remote access device 116 inside the vehicle 102 , the security manager 104 may actuate the vehicle subsystems 112 .

[0039] The control device 106 can receive wired or wireless communications from the remote device 120 via the gateway 108. The remote device 120 Figure 1 108 via the wide area network 118 and the vehicle network 114, but in many examples can be connected directly (e.g., via a wired connection) to the vehicle network 114. As an example communication, the remote device 120 can command a security key update to the computing devices 104, 106, 108 via the gateway 108.

[0040] The vehicle may include a gateway 108. The gateway 108 may be connected to multiple control devices 106, such as ECUs, via one or more vehicle buses. The gateway 108 may be configured to transmit signals between different vehicle buses connected to the gateway 108. The gateway 108 may include a processor and a memory storing instructions executable by the processor. The gateway 108 may receive communications from remote devices 120 and forward the communications to the control devices 106.

[0041] Vehicle 102 typically includes a variety of sensors 110. Sensors 110 are devices that can obtain one or more measurements of one or more physical phenomena. Some sensors 110 detect internal states of vehicle 102, such as wheel speed, wheel orientation, and engine and transmission variables. Some sensors 110 (e.g., Global Positioning System (GPS) sensors) detect the location or orientation of vehicle 102. Some sensors 110 detect objects, such as radar sensors, scanning laser rangefinders, light detection and ranging (LIDAR) devices, and image processing sensors (such as cameras). Other sensors 110 detect sound, such as dynamic or capacitive microphones, piezoelectric transducers, ultrasonic sensors, acoustic emission sensors, and the like.

[0042] The wide area network 118 represents one or more mechanisms by which the computing devices 104, 106, 108 can communicate with remote computing devices (e.g., remote device 120, another vehicle computer, etc.). Thus, the wide area network 118 can be one or more of a variety of wired or wireless communication mechanisms, including any desired combination of wired (e.g., cable and fiber optic) and / or wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or multiple topologies when multiple communication mechanisms are used). Exemplary communication networks include wireless communication networks that provide data communication services (e.g., using Low Energy (BLE), IEEE 802.11, Vehicle-to-Vehicle (V2V) such as Dedicated Short Range Communications (DSRC), Local Area Networks (LANs) and / or Wide Area Networks (WANs), including the Internet.

[0043] Now refer to Figure 2 as well as Figure 1 , shows a communication system 200 including a vehicle network 114 and a wide area network 118, wherein devices 104, 106, 108, 116, and 120 are arranged to communicate via one or both of the networks 114, 118. The computing devices 104, 106, 108 may receive communications from a remote device 120 via the wide area network 118 and the gateway 108. The remote device 120 may transmit a security key to be assigned to the devices 104, 106 to the gateway 108.

[0044] The system 200 generally includes a plurality of control devices 106-1, 106-2, 106-3, 106-4, and 106-5. Each of the control devices 106 can be programmed or configured to provide commands to actuate or control vehicle components in a vehicle subsystem 112, such as propulsion, ignition, etc. The computing devices 104, 106, and 108 can exchange communications with other computing devices 104, 106, and 108 and a remote access device 116 via a vehicle network 114.

[0045] As an exemplary security key distribution, the remote device 120 may send a message including an updated security key (i.e., to replace the default security key and / or the previously updated security key) to the control device 106 via the gateway 108 via Wi-Fi over the wide area network 118. In other words, the remote device 120 may send a message intended for at least one of the control devices 106. The message is first received by the gateway 108 and then broadcast and / or forwarded over the vehicle network 114 to be received by one or more of the control devices 106.

[0046] The control device 106 may determine whether to allow or deny an update of the security key accessible to the control device 106 based on whether the control device 106 is in a state that allows updates. For example, the control device 106 may store instructions for denying a key update when the vehicle 102 in which the control device 106 is installed is in service mode and the value of the security key is a specified default value. Alternatively or in addition, the control device 106 may allow a security key update when the vehicle 102 is in vehicle operation mode and the key is a non-default value.

[0047] The control device 106 may implement a finite state machine to determine whether to update the security key. The finite state machine may be implemented according to programming in the control device 106, and the finite state machine transitions the control device 106 from a first state (or starting state) to a second state based on changes in one or more variables or values, and generally considers the first state (e.g., the same value may transition the first state to the second state, and may transition the third state to the fourth state without transitioning to the second state). For example, one or more changing values ​​in the state machine may cause the state machine to determine a state transition of the control device 106 from the first state to the second state. Therefore, a finite state machine in this document refers to a model that includes a finite number of states and can transition between states (i.e., from a first state to a second state), wherein the second state is determined or selected from a plurality of states based on one or more values ​​received when the finite state machine is in the first state. It should be noted that in this context, the modifiers "first," "second," etc. are for convenience and do not necessarily imply an order of priority or an order in which states are selected or accessed in a state machine.

[0048] Implementations of finite state machines as described herein can enhance the security of communications between networked devices (e.g., devices 106 on network 114 in vehicle 102). Furthermore, the security of machines that include or utilize networked devices can be enhanced. For example, providing secure key updates for control devices 106 in vehicle 102 can enhance the security of vehicle 102. In one example, if a bad actor attempts to steal or misappropriate vehicle 102 by replacing control devices 106 in vehicle 102 with unauthorized or malicious control devices 106, implementing secure key updates can help prevent or hinder the bad actor's attempt to misappropriate vehicle 102.

[0049] exist Figure 3 In, now with Figures 1 to 2 , an exemplary state diagram is shown, which includes various states and values ​​for transitions between states. The control device 106 can determine that the state machine executed in the device 106 is in the first state based on state data defining the first state. The state data shown in this example includes:

[0050]

[0051] The following table (Table 1) (which may be referred to as a "state table") lists the Figure 3 The state values ​​corresponding to the state diagram shown in are:

[0052]

[0053]

[0054] Table 1

[0055] Table 1 provides Figure 3 The value of the state value in the corresponding state in the exemplary state machine of (i.e., the value of the state data). In the example described herein, the computing devices 104, 106, 108 can determine the current state by determining the value of the mode, key value, key lock, and state data that allows CMAC. Then, by determining the current state, the computing devices 104, 106, 108 can determine whether to allow (i.e., allow or deny) updates to the key value. For example, the state data in state 1 can have the following values: the mode is initial, the key state is default (i.e., the key is the specified default value), the key lock is unlocked (i.e., the key value can be updated), and updates to the key value are allowed. Therefore, in state 1, the control device 106 can receive and execute a key update command (e.g., from the remote device 120 via the gateway 108) to update the key value.

[0056] The following Boolean equation (Equation 1) can be used to determine the "allow CMAC" state value (i.e., if the equation evaluates to "true", CMAC authentication of communications between computing devices 104, 106, 108 is allowed, and if not true or "false", CMAC authentication of communications is denied (not allowed)). Generally, allowing CMAC means that computing devices 104, 106, 108 have non-default security keys, and other state values ​​indicate that CMAC authentication is allowed, and therefore communications can occur between computing devices 104, 106, 108. Denying CMAC can occur when a non-default security key value is present (see State 8), and also occurs when computing devices 104, 106, 108 have default security keys. With respect to the equation, initial mode is "true" when in initial mode and false otherwise, key status is "true" if it is the default value and false otherwise, and key lock is true if "unlocked".

[0057] Equation 1:

[0058] Allow CMAC communication = initial mode or (key status non-default) and non-error status

[0059] The state machine can transition from a first state (or initial or entry condition) to a second state based on one or more "transition events." A transition event in this document refers to an occurrence or occurrence that changes the state value of the state machine, such as the receipt of data or a change in the physical state of the computing device 104, 106, 108. The control device 106 can transition the state machine from the first state to the second state upon detecting one or more transition events. The transition event can be the receipt of a command or data from a remote device 120 connected to the vehicle 102. For example, a transition event can include updating a security key value from a default value to a non-default value, or updating or resetting a non-default value to a default value, or a command to update a non-default value. As an example, a transition event including a command to assign a key update (a "key update" command) transitions the state machine from state 3 to state 4 and from state 1 to state 6. In another example, referring to Figure 3 , the state machine transitions from state 5 to state 2 based on an event. In this example, the events may be "key reset" and "lock key" commands sent by remote device 120 to control device 106. Depending on which state is the first state when the event occurs, the same event may transition the state machine to a different second state. For example, if the state machine is in state 3, a "device reset" event transitions to state 2, but if the state machine is in state 8, it transitions to state 4.

[0060] The transition event including the command may be sent by the remote device 120 to the control device 106 based on user input to the remote device 120 (eg, by a technician, etc.).

[0061] Figure 3 The transition events in are indicated by marked arrows. Table 2 below provides an explanation of the corresponding transition events.

[0062]

[0063] Table 2

[0064] When the control device 106 is first activated, the state machine may enter State 1 or State 2, depending on whether the transition event involves a new installation or a replacement installation.

[0065] When the control device 106 is newly installed in the vehicle 102, state 1 is reached from a starting or entry condition. State 1 includes the following state values: the current machine mode is initial; the key value of the stored key is the default value; and the key is unlocked. The "Allow CMAC" value is "Allow". In addition, the update value is "Allow". Therefore, when in state 1, the control device 106 can allow security keys to be updated and perform CMAC communications with other control devices 106. When the remote device 120 sends a key update command and there is a mode change, the state machine 300 transitions from state 1 to state 4. When a key update command is received but there is no mode change, the state machine 300 transitions from state 1 to state 6. Because the key value is unlocked in state 1, the key is updated to the non-default value provided by the key update command, as reflected by the key value shown as "non-default" in each of state 4 and state 6.

[0066] When the control device 106 is replaced and installed in a vehicle, it enters State 2 from the initial or entry state. State 2 includes the following values: the current machine mode is "Service," the key value of the stored key is the default value, and the key is locked. Furthermore, the update value is "Reject." Upon receiving an unlock command, State 2 transitions to State 3, thereby changing the key lock value to "Unlock."

[0067] State 3 includes the following values: the current machine mode is service, the key value of the stored key is the default value, and the key is unlocked. The "Allow CMAC" value is "deny" (see Equation 1). In addition, the update value is "allow". When an event occurs including a reset of the control device 106 (which changes the key lock value to locked), state 3 transitions to state 2. When an event occurs including receiving a command to update the key and lock the key in the memory, state 3 transitions to state 4. Because the key value is unlocked in state 3, the key is updated to the non-default value provided by the key update command, as reflected by the key value shown as "non-default" in state 4; in addition, due to the lock command, the "lock" state value in state 4 is "locked".

[0068] Thus, state 4 includes the following values: the key is locked, the mode is "service", and the key is non-default. The "allow CMAC" value is "allow". Additionally, the update value is "reject". State 4 can represent a situation in which the control device 106 has been maliciously or improperly installed in the vehicle 102, and then the bad actor attempts to update the security key to a key that would allow improper access to the vehicle 102 and / or network 114 in which the control device 106 is updating the key. Therefore, the control device 106 rejects CMAC authenticated communications and rejects the key update. State 4 transitions to state 5 when a command from the device 120 causes the key lock value to change from "locked" to "unlocked" so that the key can be updated.

[0069] State 5 includes the following values: the key is unlocked, the mode is "Service", and the key is non-default. The "Allow CMAC" value is "Allow". In addition, the update value is "Allow". When a command is received to update the key to the default value and lock the key, state 5 transitions to state 2. When a command from the remote device 120 updates the key value from the non-default value to a new non-default value and locks the key, state 5 also transitions to state 4. The control device 106 can also transition from state 5 to state 4 based on a transition event including an ECU reset. According to Table 2, the ECU resets the locked key because the mode is service.

[0070] State 6 includes the following values: the key is unlocked, the mode is "initial", and the key is non-default. The "Allow CMAC" value is "allowed". In addition, the update value is "allowed". When a command to unlock the key and change the mode to "service" is received, state 6 transitions to state 4. In one example, the command is a "forced counter-sync" (FCS) command. The FCS command may occur when the vehicle 102 in initial mode has all control devices 106 installed and the control devices 106 are to be set or forced into service mode. Therefore, the FCS command locks the key and changes the mode from initial to service. When a command to reset the key value to the default value is received, state 6 transitions to state 1. When a command to update the key to the default value and lock the key is received from the device 120, state 6 transitions to state 2.

[0071] State 7 represents an error state with the following values: key is "locked", mode is "initial", and key is default. The value of "allow CMAC" is "reject". In addition, the update value is "reject". The control device 106 may enter state 7 due to some error in the operation of the control device 106, such as may be caused by an unexpected fluctuation in power (or what can be called a "glitch"). After a device reset command, the control device 106 transitions from state 7 to state 2.

[0072] State 8 represents a second error state. The state data in state 8 is the same as in state 7, except that the security key has a non-default key value in state 8. After a device reset command, the control device 106 transitions from state 8 to state 4.

[0073] Example Process

[0074] Refer to the above description Figures 1 to 3 The elements are described Figure 4 A process flow diagram is shown of an exemplary process 400 for computing devices 104, 106, 108 to operate, including receiving commands (such as a command to update a security key) and sending and / or receiving messages via networks 114, 118 according to a state machine. The process can be performed according to program instructions executed by computing devices 104, 106, 108 (such as control device 106), which can be controllers or ECUs communicating via vehicle network 114, for example (i.e., program instructions for a state machine such as the state machine can be implemented in computing devices 104, 106, 108 (such as control device 106)). Therefore, process 400 is explained with reference to control device 106.

[0075] The process 400 begins in block 410 when the state machine executing in the control device 106 enters the initial state from a starting condition. Figure 3 In the state machine of FIG, the starting condition is the installation of a new device 106. For a new or first installation (e.g., when a vehicle is being manufactured and components including the control device 106 are initially installed), the initial state may be State 1. Additionally, for a replacement installation (e.g., when a vehicle has been previously manufactured and placed in service and components including the device 106 are initially installed), the initial state may be State 2.

[0076] Next, in decision block 415, control device 106, executing the state machine, determines whether authentication of the message received in control device 106 is permitted in the current state, which may be the initial state or a second or subsequent state. In the example state machine, determining whether authentication of the message is permitted involves checking whether the CMAC is "allowed" or "rejected." If control device 106 determines that authentication of the message is permitted in the current state, block 415 is followed by block 420. If authentication of the message is not permitted, block 425 is executed next.

[0077] In block 420, the control device may begin authenticating messages received or detected via the vehicle network 114. For example, a stored key value (in Figure 3 key_val in the example of may be the value of a security key that may be used to perform authentication, such as CMAC authentication.

[0078] In decision block 425, which may follow either of blocks 415 and 420, the control device 106 determines whether a transition event has been detected. If a transition event has been detected, the process continues to block 430. Otherwise, the process continues to block 435.

[0079] In block 430 , the state machine transitions from the initial state to a second or subsequent state in response to the transition event. The transitioned state may also be referred to as a “new” state because it is a state in addition to the current state of block 425 .

[0080] At block 440 , control device 106 determines whether to continue the process. Process 400 can be terminated by external input or action. For example, when implemented in vehicle 102 , control device 106 can execute process 400 whenever the ignition of vehicle 102 is on. If process 400 continues, process 400 returns to block 415 . Otherwise, process 400 ends after block 435 .

[0081] Refer to the above Figures 1 to 3 Component description Figure 5 is a process flow diagram illustrating an exemplary process 500 for managing key distribution based on a state machine. Process 500 may be implemented and executed, for example, by control device 106 of vehicle 102. For example, process 500 may be executed in the context of process 400 described above. For example, when device 106 receives or determines a transition event in block 425, the transition event may include a key update command.

[0082] The process 500 begins in block 510 , where the control device 106 receives a key update command.

[0083] Next, in decision block 515, the control device 106 determines whether the update is allowed in the current state. As explained above, the control device 106 may determine the current state based on the state data value. For example, upon receiving the key update command, the control device 106 may determine that the current state is a state where the update permission value is "allowed". Figure 3 In the example of , this may be any of states 1, 3, 5, or 6. The control device 106 may alternatively determine that the current state is a state in which the update permission value is "rejected." Figure 3 In the example of , this may be any of states 2, 4, 7, or 8. If the current state does not allow key updates, the process 500 continues to decision block 520. Otherwise, the process 500 continues to block 525.

[0084] In decision block 520, the control device 106 determines whether a transition event (i.e., an event that transitions the state machine in the control device 106 to a new state (i.e., a second state subsequent to the first or current state evaluated in block 515)) has occurred. If a transition event has occurred, the process 500 returns to block 515. Otherwise, the process 500 continues to block 530.

[0085] In block 525, which may follow block 515, the control device 106 has transitioned to or is in a state that allows key updates. The control device 106 performs the key update accordingly. The key update may reset the key value to a default value, update the key value from a default value to a non-default value, or update a non-default value (e.g., as described above). The process 500 then ends after block 525.

[0086] Following decision block 520, control device 106 determines in block 530 whether to continue process 500. For example, process 500 may be terminated by an external input or action. For example, when implemented in vehicle 102, control device 106 may execute process 500 whenever vehicle 102 is in the ignition-on state. Thus, process 500 may terminate when vehicle 102 transitions to the ignition-off state. If process 500 continues, process 500 returns to block 520. Otherwise, process 500 ends after block 530.

[0087] Computing devices 104, 106, 108, such as those discussed herein, typically each include commands that are executable by one or more computing devices 104, 106, 108, such as those identified above, and used to implement the blocks or steps of the processes described above. For example, the process blocks discussed above may be embodied as computer-executable commands.

[0088] The computer executable instructions may be compiled or interpreted by a computer program created using a variety of programming languages ​​and / or technologies, including but not limited to the following, either singly or in combination: Java TM , C, C++, Python, Julia, SCALA, Visual Basic, Java Script, Perl, HTML, etc. In general, the processor 116 (i.e., microprocessor) receives commands (i.e., commands from memory, computer-readable media, etc.) and executes these commands, thereby performing one or more processes including one or more of the processes described herein. Such commands and other data can be stored in files and transmitted using a variety of computer-readable media. A file in a computing device is typically a collection of data stored on a computer-readable medium such as a storage medium, random access memory, etc.

[0089] Computer-readable media (also known as processor-readable media) include any non-transitory (i.e., tangible) media that participate in providing data (i.e., instructions) that can be read by a computer (i.e., by the processor of a computer). Such media can take many forms, including but not limited to non-volatile media and volatile media. Instructions can be transmitted over one or more transmission media, including optical fiber, wires, wireless communications, including internal components that make up a system bus coupled to the processor of a computer. Common forms of computer-readable media include, for example, RAM, PROM, EPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.

[0090] Unless otherwise expressly indicated herein, all terms used in the claims are intended to be given their ordinary and customary meanings as understood by those skilled in the art. In particular, use of singular articles such as "a," "an," "the," and "said" should be construed to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.

[0091] In the accompanying drawings, the same reference numerals indicate the same elements. In addition, some or all of these elements may be changed. With respect to the media, processes, systems, methods, etc. described herein, it should be understood that although the steps or blocks of such processes, etc. have been described as occurring according to a sequence in a specific order, such processes can be practiced by performing the described steps in an order other than the order described herein. It should also be understood that certain steps may be performed simultaneously, other steps may be added, or certain steps described herein may be omitted. In other words, the description of the process herein is provided for the purpose of illustrating certain embodiments and should in no way be interpreted as limiting the claimed invention.

[0092] The use of "in response to," "based on," and "after determining..." herein indicates a causal relationship, not just a temporal relationship. Unless expressly stated otherwise, "based on" or "in response to" can mean at least partially based on or at least partially in response to.

[0093] Examples are contemplated herein. Any example embodiment or feature described herein is not necessarily to be construed as preferred or advantageous over other embodiments or features. Furthermore, the example embodiments described herein are not meant to be limiting. It will be readily understood that certain aspects of the disclosed systems and methods may be arranged and combined in a variety of different configurations, all of which are contemplated herein. Additionally, the specific arrangements shown in the figures should not be considered limiting. It should be understood that other embodiments may include more or fewer of each element shown in a given figure. Additionally, some of the elements shown may be combined or omitted. Furthermore, example embodiments may include elements not shown in the figures. The present disclosure has been described in an illustrative manner, and it should be understood that the terms that have been used are intended to be descriptive in nature, not restrictive. In view of the above teachings, many modifications and variations of the present disclosure are possible, and the present disclosure may be practiced in other ways than specifically described. It should be understood that the use of the terms "first" and "second" merely identifies a priority and does not necessarily indicate a priority.

[0094] According to the present invention, a system is provided, which has a computing device, the computing device including a processor and a memory, the memory storing instructions executable by the processor, the instructions including instructions for performing the following operations: receiving a key update command to update a key value; and in response to the key update command, updating the key value when it is determined that the computing device is in a first state based on state data defining the first state, the state data including the key value, a machine mode specifying a current operating environment, and a lock value specifying whether the memory storing the key value is locked or unlocked.

[0095] According to an embodiment, the instructions further comprise instructions for transitioning to the second state after updating the key value.

[0096] According to an embodiment, the instructions further include instructions for allowing the computing device to authenticate communications with the key value based on the second state.

[0097] According to an embodiment, the machine mode is changed from a first state to a second state.

[0098] According to an embodiment, the first state is a default state, and the key value in the default state is a default value.

[0099] According to an embodiment, the computing device is configured to communicate with a second computing device via a network.

[0100] According to an embodiment, the invention also features a gateway computing device configured to provide a key update command to the computing device via the network.

[0101] According to an embodiment, the gateway is further configured to provide the key update command based on determining that the computing device is in the first state.

[0102] According to an embodiment, the computing device is an electronic control unit (ECU) of a vehicle.

[0103] According to an embodiment, the present invention is also characterized in that the instructions further include instructions for transitioning from an error state to the first state.

[0104] According to the present invention, a method includes: receiving a key update command to update a key value; and in response to the key update command, updating the key value when a computing device is determined to be in a first state based on state data defining the first state, the state data including the key value, a machine mode specifying a current operating environment, and a lock value specifying whether a memory storing the key value is locked or unlocked.

[0105] In one aspect of the invention, the method comprises transitioning to a second state after updating the key value.

[0106] In one aspect of the invention, the method includes allowing the computing device to authenticate communications with the key value based on the second state.

[0107] In one aspect of the invention, the machine mode is changed from the first state to the second state.

[0108] In one aspect of the present invention, the first state is a default state, and the key value in the default state is a default value.

[0109] In one aspect of the invention, the computing device is configured to communicate with a second computing device via a network.

[0110] In one aspect of the invention, the method includes a gateway computing device configured to provide a command to update the key value to the computing device via the network.

[0111] In one aspect of the present invention, the gateway is further configured to provide the key update command based on determining that the computing device is in the first state.

[0112] In one aspect of the invention, the computing device is an electronic control unit (ECU) of a vehicle.

[0113] In one aspect of the invention, the method includes transitioning from an error state to a first state.

Claims

1. A method comprising: receiving a key update command to update a key value; as well as In response to the key update command, the key value is updated when it is determined that the computing device is in the first state based on state data defining the first state, the state data including the key value, a machine mode specifying a current operating environment, and a lock value specifying whether a memory storing the key value is locked or unlocked.

2. The method of claim 1, further comprising transitioning to a second state after updating the key value.

3. The method of claim 2, further comprising allowing the computing device to authenticate communications with the key value based on the second state. The method of claim 2 , wherein the machine mode is changed from the first state to the second state. The method of claim 1 , wherein the first state is a default state, and the key value in the default state is a default value. The method of claim 1 , wherein the computing device is configured to communicate with a second computing device via a network.

7. The method of claim 1, further comprising a gateway computing device configured to provide a command to update the key value to the computing device via the network.

8. The method of claim 7, wherein the gateway is further configured to provide the key update command based on determining that the computing device is in the first state.

9. The method of claim 1, wherein the computing device is an electronic control unit (ECU) of a vehicle.

10. The method of claim 1, further comprising transitioning from an error state to the first state.

11. The method of claim 1, further comprising, upon determining based on the state data that the computing device is in a second state, the computing device rejecting the key update command.

12. The method of claim 1, wherein the key update command is sent from a remote device.

13. The method of claim 1, further comprising a vehicle subsystem configured to receive commands from the computing device.

14. A computer comprising a processor and a memory, the memory storing instructions executable by the processor to perform the method of any one of claims 1 to 13.

15. A vehicle comprising the computer according to claim 14.

Images