Key configuration apparatus and key configuration method

Abstract

The present disclosure relates to a key configuration apparatus and a key configuration method. The key configuration apparatus includes a communication circuit configured to receive, from a server, first key configuration data including a plurality of key values and a usage value of a key. The key configuration apparatus also includes a control circuit configured to arbitrarily select at least one key value from the plurality of key values based on a usage of the key required by a key data reception apparatus. The control circuit is further configured to generate second key configuration data including the at least one key value. The control circuit is additionally configured to transmit the second key configuration data to the key data reception apparatus via the communication circuit.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit and priority of Korean Patent Application No. 10-2024-0177215, filed on December 3, 2024, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to key configuration technology. Background Technology

[0004] In early approaches to vehicle development and production, it was typical that the vehicle's functionality remained unchanged after mass production. In such an environment, security keys suitable for a specific purpose could be embedded during the production phase of the electronic control unit (ECU), or security keys could be injected during mass production of the vehicle and then used for the entire lifespan of the vehicle. Because the initially configured security keys were maintained throughout the vehicle's lifecycle, subsequent updates or modifications to the program were typically unnecessary.

[0005] At this point, security keys are configured based on the assumption that the vehicle's functions will remain fixed throughout operation. Since it is common for vehicles to operate without software or functional changes after mass production, the system may be designed to eliminate the need for additional security key management. This initial design and implementation approach establishes a framework in which the same security key can be used without modification throughout the vehicle's entire lifecycle, thereby effectively protecting the vehicle's control system.

[0006] However, as vehicle technology continues to evolve, particularly with the rapid development of complex features such as autonomous driving, and as these technologies become increasingly likely to be practically deployed on roads, the traditional approach using fixed security keys may no longer be suitable for current and future automotive security environments. In addition to autonomous driving, a wide variety of services and features requiring connectivity between vehicles and external networks are being developed, further enhancing the security levels required by vehicles.

[0007] Recently, the concept of software-defined vehicles (SDV) has become increasingly important. In SDV, vehicle functionality is defined by software, allowing for the continuous addition and improvement of various features through software updates. With the emergence of the SDV concept, more and more new technologies and services requiring security are appearing. Therefore, the number of security keys required within a vehicle can increase significantly compared to the past, leading to greater complexity in security key management.

[0008] In SDV, each time a new feature is added or updated, new security keys may need to be generated and managed. This means that both the number and variety of security keys required within the overall security framework of a vehicle may continue to grow. While traditional methods (such as using fixed security keys based on electronic control units (ECUs) or managing security keys) are sufficient when vehicle functions remain fixed, they may no longer be effective in the case of SDV.

[0009] Furthermore, assuming that the vehicle's functionality will remain unchanged, the traditional method of managing security keys via wired injection is flawed. In environments where functionality is frequently updated and modified through software, such a method can lead to unnecessary costs. For example, physically accessing the vehicle and injecting the security key via a wired connection each time a new security key is needed is both time-consuming and expensive. In the context of Software-Defined Vehicles (SDV), such a method may be limiting. Summary of the Invention

[0010] According to one aspect of this disclosure, a flexible and efficient technique for key configuration is provided. According to another aspect of this disclosure, a technique is provided to facilitate the distribution of security keys for new features or for updated features in a manner suitable for SDV. According to yet another aspect of this disclosure, a technique is provided to ensure that security is not compromised even during multiple key configuration processes.

[0011] According to one embodiment of this disclosure, a key configuration apparatus is provided. The key configuration apparatus includes a communication circuit configured to receive first key configuration data from a server, comprising a plurality of key values ​​and a usage value for the keys. The key configuration apparatus also includes a control circuit configured to arbitrarily select at least one key value from the plurality of key values ​​based on the usage of the keys required by a key data receiving device. The control circuit is further configured to generate second key configuration data comprising at least one key value. The control circuit is further configured to transmit the second key configuration data to the key data receiving device via the communication circuit.

[0012] The control circuit can be configured to identify one or more key values ​​from a plurality of key values ​​that correspond to the purpose of the key required by the key data receiving device, based on the purpose value in the first key configuration data, and to arbitrarily select at least one key value from the one or more key values.

[0013] The control circuitry can be configured to delete unused key values ​​after sending the second key configuration data.

[0014] The control circuit can be configured to receive first key configuration data from a server via wireless communication and to send second key configuration data to a key data receiving device using an in-vehicle communication network configured via wired or wireless means.

[0015] The key data receiving device can be configured to update an existing key value using at least one key value included in the second key configuration data.

[0016] The control circuit can be configured to select at least one key value from a plurality of key values ​​based on the purpose value of the key included in the request message received from the key data receiving device.

[0017] The first key configuration data may include usage values ​​indicating the types of at least two devices, and the second key configuration data may include usage values ​​indicating unique identifiers of at least two devices.

[0018] The control circuit can be configured to specify a unique identifier for the key configuration device and a unique identifier for the key data receiving device received from the key data receiving device in the second key configuration data.

[0019] One of a number of key values ​​can be matched with multiple use values.

[0020] The first key configuration data can further include multiple certificates and their usage values.

[0021] According to another embodiment of this disclosure, a key configuration apparatus is provided. The key configuration apparatus includes a computing circuit configured to generate first key configuration data, comprising a plurality of key values ​​and a key usage value, for a purpose-specific and device-specific key required within a vehicle. The key configuration apparatus also includes a server communication circuit configured to transmit the first key configuration data to a device installed on the vehicle.

[0022] The computing circuitry can be configured to delete multiple key values ​​after the first key configuration data is sent to the device.

[0023] Before deleting multiple key values, the computation circuit can store the hash operation values ​​of multiple key values.

[0024] According to another embodiment of this disclosure, a key configuration method is provided. The key configuration method includes receiving first key configuration data from a server, comprising a plurality of key values ​​and a purpose value for the keys. The key configuration method further includes arbitrarily selecting at least one key value from the plurality of key values ​​based on the purpose of the keys required by a key data receiving device. The key configuration method further includes generating second key configuration data comprising at least one key value. The key configuration method further includes sending the second key configuration data to a key data receiving device.

[0025] The key configuration method may further include: notifying a key data receiving device of the start of key configuration; and receiving a request message from the key data receiving device including at least one usage value, wherein, when arbitrarily selecting at least one key value, at least one key value may be selected from a plurality of key values ​​based on at least one usage value received from the key data receiving device.

[0026] The request message may include a unique identifier of the key data receiving device, and when generating the second key configuration data, the unique identifier of the key data receiving device may be included in the second key configuration data.

[0027] The key configuration method may further include: when at least one usage value received from the key data receiving device includes a usage intended for use only within the key data receiving device, after sending second key configuration data, deleting the key value corresponding to the usage intended for use only within the key data receiving device.

[0028] One of a number of key values ​​can be matched with multiple use values.

[0029] The key configuration method may further include: receiving a first key configuration completion message from a key data receiving device; and sending a second key configuration completion message to a server after receiving the first key configuration completion message.

[0030] After sending the second key configuration complete message, multiple key values ​​can be deleted from the server.

[0031] Embodiments of this disclosure provide a flexible and efficient technique for key configuration. Embodiments of this disclosure also facilitate the distribution of security keys for new features or for updated features in a manner suitable for SDV. Embodiments of this disclosure also provide a technique that ensures security is not compromised even during multiple key configuration processes. Attached Figure Description

[0032] Figure 1 This is a diagram illustrating the configuration of a key configuration system according to one embodiment of the present disclosure.

[0033] Figure 2 This is a diagram showing the configuration of the main device according to one embodiment.

[0034] Figure 3 This is a flowchart illustrating a key configuration method according to one implementation.

[0035] Figure 4 This is a first example of a device system according to one embodiment.

[0036] Figure 5 This is a first example of first key configuration data according to one implementation method.

[0037] Figure 6 This is a first example of a second key configuration information table according to one implementation method.

[0038] Figure 7 This is a first example of second key configuration data according to one implementation method.

[0039] Figure 8 This is a second example of second key configuration data according to one implementation method.

[0040] Figure 9 This is a third example of second key configuration data according to one implementation method. Detailed Implementation

[0041] In the following, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. It should be noted that when assigning reference numerals to components in the drawings, the same components are given the same reference numerals as much as possible, even if the components are shown in different drawings. Furthermore, in describing the present disclosure, detailed descriptions of well-known components or functions are omitted where such detailed descriptions would obscure the essential points of the disclosure.

[0042] In describing the components of this disclosure, terms such as first, second, A, B, (a), (b), etc., may be used. These terms are intended only to distinguish one component from another, and the nature, sequence, or order of these components is not limited by these terms. Furthermore, when a component is described as being “connected,” “coupled,” or “accessed” to another component, it should be understood that the component may be directly “connected,” “coupled,” or “accessed” to the other component, or that the component may also be “connected,” “coupled,” or “accessed” to the other component via yet another component disposed therein.

[0043] When a component, controller, device, element, equipment, circuit, unit, etc., of this disclosure is described as having a purpose or performing an operation or function, it shall be considered herein to be "configured" to satisfy that purpose or perform that operation or function. Each component, controller, device, element, equipment, circuit, unit, etc., may individually embody or include a processor and memory (such as a non-transitory computer-readable medium) as part of that device.

[0044] Figure 1 This is a diagram illustrating the configuration of a key provisioning system according to one embodiment of the present disclosure.

[0045] refer to Figure 1 The key provisioning system 100 may include a device system 110, a key provisioning server 120, etc. The device system 110 may be installed inside a vehicle.

[0046] As used herein, the term "vehicle" refers to any type of transportation means used to move people or objects. For example, a vehicle can include land-based transportation devices such as cars, trucks, buses, or motorcycles, as well as a variety of other vehicles such as aircraft, advanced air vehicles (AAM), urban air vehicles (UAM), drones, ships, or rail vehicles. For ease of illustration, the following description focuses on automobiles as vehicles. However, the scope of this disclosure is not limited thereto.

[0047] The device system 110 may include a master device (PD) 112 and a terminal device (ED) 114. The master device 112 plays a leading role in key distribution within the device system 110 and is therefore also referred to as a key provisioning device.

[0048] The main device 112 and the terminal device 114 can be connected via an in-vehicle communication network, which can be configured via wired or wireless means.

[0049] The vehicle-mounted communication network can form a network environment in which the main device 112 and the terminal device 114 can be interconnected. This communication network can support communication between various electronic control units within the vehicle, thereby achieving efficient data transmission.

[0050] In-vehicle communication networks can include various protocols and physical connection methods. Representative protocols include Controller Area Network (CAN), Local Interconnect Network (LIN), Ethernet, and FlexRay. These protocols can be implemented with different data transmission speeds and processing methods, and can be used depending on the specific purpose within the vehicle. For example, the CAN protocol can be used for communication between systems requiring real-time control, such as the engine and transmission. LIN can be applied to accessory control that requires low-speed communication. Ethernet can be used for vehicle multimedia systems that require high-speed data transmission capable of carrying more data.

[0051] The master device 112 and the terminal device 114 can send and receive messages via an in-vehicle communication network. The master device 112 can function as a central data controller or repeater on the network, while the terminal device 114 can be configured as a device performing specific functions, such as a sensor or actuator. The in-vehicle communication network facilitates smooth communication between the various nodes, thereby supporting the operation of various vehicle functions through this communication process.

[0052] In-vehicle communication networks can use wired transmission media capable of transmitting data via electrical signals. The transmission media can include unshielded twisted-pair (UTP) cables, shielded twisted-pair (STP) cables, or fiber optic cables, and can be selected according to network requirements. Such physical connections can be designed to ensure stable data transmission.

[0053] The main device 112 can be connected to the key configuration server 120 via wireless communication.

[0054] The main device 112 installed in the vehicle can be connected to the key configuration server 120 wirelessly. Wireless communication methods can include various technologies such as cellular networks, Wi-Fi, Bluetooth, and satellite communication. This communication enables the vehicle to connect to other systems outside the vehicle to send or receive data.

[0055] Over-the-air (OTA) downloads are an exemplary method for a vehicle to wirelessly send and receive data from an external server. OTAs can be used to remotely perform software updates, configuration changes, and certificate transfers. The master device 112 can receive key configuration data (including security keys or certificates) from the key configuration server 120 via OTA and store it in a security module within the vehicle. Through this process, cellular networks or Wi-Fi can be used to transmit data, thereby keeping security updates and settings up-to-date.

[0056] Wireless communication methods may include cellular networks, through which technologies such as Long Term Evolution (LTE) or 5G New Radio (NR) can be used to send and receive data. In this case, a telematics device installed in the vehicle can serve as a communication module, thereby enabling connectivity to networks outside the vehicle. Furthermore, when the vehicle connects to an external network in a parking lot or service center, Wi-Fi-based communication can be used. Through Wi-Fi, the vehicle can connect to the key configuration server 120 and exchange data.

[0057] In wireless communication, data security is often a critical consideration, and data can be transmitted in encrypted form. The master device 112 can use a security protocol to send and receive data from the key configuration server 120, thereby preventing unauthorized access or data leakage.

[0058] A secure communication channel can be configured between the host device 112 and the key configuration server 120, and within the vehicle communication network. This secure communication channel can be configured using encryption techniques and authentication mechanisms to ensure secure data transmission. This secure communication channel helps prevent unauthorized viewing or tampering of data during communication.

[0059] To configure secure communication channels in an in-vehicle communication network, protocols such as Transport Layer Security (TLS) can be used. TLS ensures that data is encrypted and transmitted during communication and provides the ability to verify the trustworthiness of the communicating party by authenticating the other party. Such a TLS protocol allows secure data transmission and reception between the master device 112 and the key configuration server 120. When transmitting data, both symmetric key encryption and public key encryption can be used to protect the data from unauthorized access and ensure data integrity.

[0060] To configure secure communication channels within an in-vehicle communication network, techniques such as Message Authentication Code (MAC) or Hash-based Message Authentication Code (HMAC) can be employed. These techniques provide the ability to authenticate the origin of messages transmitted over the communication network and verify data integrity. For example, when using the Controller Area Network (CAN) protocol (which essentially does not include security features), additional MAC or HMAC algorithms can be applied to verify and authenticate data integrity.

[0061] Furthermore, in secure communication channels, a security key may be required to enable encrypted communication between communication nodes within the vehicle. This key can be provided from the key configuration server 120. When provided, the key can be sent in encrypted form to maintain security. The master device 112 can use the received key to encrypt and decrypt data within the vehicular communication network.

[0062] In one implementation, to maintain a secure communication channel, an authentication mechanism can be used to verify the identity of the other party. Certificate-based authentication methods can be used, allowing both communicating parties to mutually confirm that they are trusted entities. Public Key Infrastructure (PKI) can be used to manage certificates, and the master device 112 and key configuration server 120 can establish a secure communication channel based on these certificates.

[0063] The master device 112 can receive first key configuration data KPDT1 (key configuration data 1) from the key configuration server 120. The first key configuration data KPDT1 includes the key values ​​required by the device system 110, and may include usage values ​​of the keys. For example, if the usage values ​​are represented as U1 and U2, then the first key KEY1 may match U1 and be included in the first key configuration data KPDT1, and the second key KEY2 may match U2 and be included in the key configuration data KPDT1.

[0064] In addition, the master device 112 can identify the use of the key requested by the terminal device 114, select a key value based on the use of the key, include the key value in the second key configuration data KPDT2, and send it to the terminal device 114.

[0065] In this method, only key-related data is sent, allowing the key to be distributed without affecting the software installed on each device. Furthermore, since server 120 organizes and distributes key values ​​based on each vehicle, the key can be distributed in a manner suitable for the conditions of each vehicle. Key distribution can be automated because the entire process requires no human intervention. Moreover, when server 120 sends the key value to master device 112, it does not specify which device will use the key value. Instead, master device 112 determines which device will use the key value, thus eliminating the key's dependence on the controller. Even if the key is leaked, its intended use cannot be identified, thereby increasing security.

[0066] In one implementation, the key configuration server 120 can delete the key value after the generated key value has been distributed. If the master device 112 does not use the key value after distribution, the master device 112 can delete the key value. This can help reduce the risk of key leakage. Before deleting the key value, the key configuration server 120 can retain the hash operation values ​​of the key. These hash operation values ​​can be used to verify whether a correct key has been distributed to a vehicle under incorrect circumstances.

[0067] Figure 2This is a diagram showing the configuration of the main device according to one embodiment.

[0068] refer to Figure 2 The key configuration server 120 may include a communication circuit 222 and a computing circuit 224. The main device 112 may include a communication circuit 211 and a control circuit 213. For ease of understanding, the communication circuit 222 included in the key configuration server 120 is referred to as the server communication circuit 222, and the communication circuit 211 included in the main device 112 is referred to as the device communication circuit 211.

[0069] The server's computing circuit 224 can generate multiple key values ​​for usage-specific and device-specific keys required within a vehicle. For example, the computing circuit 224 can generate two key values ​​for usage U1 and one key value for usage U2. The computing circuit 224 can discover the multiple key values ​​required for each vehicle and generate the key values ​​accordingly.

[0070] Additionally, the computing circuit 224 can generate usage values ​​for the keys. The computing circuit 224 can identify the key value required for each vehicle and the purpose of the key. The computing circuit 224 can generate key values ​​accordingly and match each key value with its corresponding usage value.

[0071] The computing circuit 224 can then generate first key configuration data KPDT1, which includes the generated key value and the purpose value of the key.

[0072] Server communication circuit 222 can send the first key configuration data KPDT1 to a device installed in the vehicle, such as device communication circuit 211, via communication.

[0073] After the first key configuration data KPDT1 has been sent to a device, such as the master device 112, the computing circuit 224 can delete the generated multiple key values. The key configuration server 120 can receive a key configuration completion message from the master device 112, and the computing circuit 224 can delete the multiple key values ​​after receiving the key configuration completion message. Once the key configuration is complete, the master device 112 can send a key configuration completion message to the key configuration server 120.

[0074] Before deleting multiple key values, computation circuit 224 can store hash operation values ​​of the multiple key values. These stored hash operation values ​​can be used to verify whether the distributed key matches the vehicle in case of errors.

[0075] The device communication circuit 211 can receive first key configuration data KPDT1, which includes multiple key values ​​and the purpose of the keys, from the server 120. Then, once the control circuit 213 generates second key configuration data KPDT2, it can send the second key configuration data KPDT2 to the terminal device 114.

[0076] The device communication circuit 211 can receive the first key configuration data KPDT1 from the server 120 via wireless communication, and can send the second key configuration data KPDT2 to the terminal device 114 via a vehicle communication network configured via wired or wireless means.

[0077] The control circuit 213 can arbitrarily select at least one key value from a plurality of key values ​​based on the intended use of the key required by the terminal device 114. Then, the control circuit 213 can generate second key configuration data KPDT2 including at least one key value and send the second key configuration data KPDT2 to the terminal device 114 through the device communication circuit 211.

[0078] The control circuit 213 can identify one or more key values ​​from a plurality of key values ​​that correspond to the purpose of the key required by the terminal device 114, based on the purpose value in the first key configuration data KPDT1, and can arbitrarily select at least one of the aforementioned key values ​​from the one or more key values. For example, the first key configuration data KPDT1 may include a first key value KEY1, a second key value KEY2, and a third key value KEY3, and the first key value KEY1 can match U1, the second key value KEY2 can match U2, and the third key value KEY3 can match U1. In this case, when the terminal device 114 requests a key value for purpose U1, the control circuit 213 can arbitrarily select a key value from the first key value KEY1 and the second key value KEY3 corresponding to U1.

[0079] After sending the second key configuration data KPDT2, the control circuit 213 can delete any unused key values. For example, if U2 is a key value used only within the terminal device 114, the control circuit 213 can include the second key value KEY2 in the second key configuration data KPDT2 and transmit it, and then delete the remaining second key value KEY2 from the master device 112.

[0080] Terminal device 114 can update an existing key value using the key value included in the second key configuration data KPDT2, and can use it for newly created functions. For example, terminal device 114 can update an existing key value using a third key value KEY3 received for purpose U1, and can use a second key value KEY2 received for purpose U2 for a new function.

[0081] Terminal device 114 can receive second key configuration data KPDT2 from master device 112 upon request.

[0082] The master device 112 may select at least one key value from a plurality of key values ​​included in the first key configuration data KPDT1 based on the use value of the key included in the request message received from the terminal device 114, and send it to the terminal device 114.

[0083] The request message may include the usage value required by the terminal device 114, as well as the unique identifier of the terminal device 114.

[0084] U1 can be a purpose value for communication between at least two devices. For purpose U1, the first key configuration data KPDT1 can contain only the types of the at least two devices communicating with each other. For example, the first key configuration data KPDT1 can specify a third key value KEY3 intended for communication between a first type controller and a second type controller.

[0085] The master device 112 can identify the unique identifier of the terminal device 114 received from the terminal device 114 and specify that unique identifier in the second key configuration data KPDT2. For example, the master device 112 can replace the second type controller specified in the first key configuration data KPDT1 with the unique identifier of the terminal device 114 in the second key configuration data KPDT2, and replace the first type controller specified in the first key configuration data KPDT1 with the unique identifier of its own device unique identifier in the second key configuration data KPDT2.

[0086] Figure 3 This is a flowchart illustrating a key configuration method according to one implementation.

[0087] refer to Figure 3 In operation S302, key configuration server 120 can generate first key configuration data including multiple key values ​​and key usage values. Key configuration server 220 can generate first key configuration data according to the usage and number of keys required for each vehicle.

[0088] In operation S304, the master device 112 can receive first key configuration data from the key configuration server 120, which includes multiple key values ​​and key usage values.

[0089] In operation S306, the master device 112 can generate pre-configuration data. The master device 112 can identify the number and purpose of keys from the first key configuration data. Furthermore, the master device 112 can check the key configuration information table according to its purpose. This key configuration information table can be included in the first key configuration data.

[0090] In operation S308, the master device 112 can notify the terminal device 114 of the start of key configuration.

[0091] In operation S310, the master device 112 may receive a request message from the terminal device 114 that includes at least one usage value.

[0092] Based on the purpose of the key required by the terminal device 114, the master device 112 can arbitrarily select at least one key value from a plurality of key values. In one embodiment, the master device 112 can select at least one key value from a plurality of key values ​​based on at least one purpose value included in a request message received from the terminal device 114.

[0093] In operation S312, the master device 112 may generate second key configuration data including at least one key value selected therefrom.

[0094] The request message received from terminal device 114 may include the unique identifier of the terminal device. When generating the second key configuration data, master device 112 may include the unique identifier of the terminal device in the second key configuration data.

[0095] In operation S314, the master device 112 can send the second key configuration data to the endpoint device 114.

[0096] In operation S316, terminal device 114 can store the received key configuration data and use the key value contained therein.

[0097] Terminal device 114 may use key values ​​to communicate with another device (key data receiving device) (e.g., master device 112), or may use them only internally. Values ​​indicating these uses may be included in a request message and sent to master device 112.

[0098] After sending the second key configuration data to the terminal device 114, the master device 112 can delete the key value corresponding to the purpose intended for use only within the terminal device 114.

[0099] For example, in operation S318, the master device 112 can receive a message indicating key configuration completion—a first key configuration completion message—from the terminal device 114, and can delete unused key values—for example, key values ​​intended to be used only within the terminal device 114—from its memory.

[0100] In operation S320, when the master device 112 receives a first key configuration completion message from all terminal devices managed by the master device 112, the master device 112 may store key configuration data related to the key value used.

[0101] In operation S322, the master device 112 can send a message indicating that the configuration of all keys has been completed (second key configuration completion message) to the key configuration server 120.

[0102] In operation S324, upon receiving the second key configuration complete message, the key configuration server 120 can delete multiple key values ​​from the server. Before deletion, the key configuration server 120 can store the hash operation values ​​of the multiple key values.

[0103] The implementation method is described in more detail below with specific examples.

[0104] Figure 4 This is a first example of a device system according to one embodiment; Figure 5 This is a first example of first key configuration data according to one implementation method; Figure 6 This is a first example of a second key configuration information table according to one implementation method; Figure 7 This is a first example of second key configuration data according to one implementation method; Figure 8 This is a second example of second key configuration data according to one implementation method; and Figure 9 This is a third example of second key configuration data according to one implementation method.

[0105] exist Figures 4 to 9 In the example shown, device system 110 may include a first controller 410, a second controller 420, and a third controller 430. The first controller 410 may be a type A controller, the second controller 420 may be a type B controller, and the third controller 430 may be a type C controller.

[0106] Communication between the first controller 410 and the second controller 420 may require one key value, communication between the first controller 410 and the third controller 430 may require another key value, and the internal function X of the second controller 420 may require yet another key value.

[0107] In this example, the first controller 410 operates as a master device, and the second controller 420 and the third controller 430 can operate as terminal devices.

[0108] The key configuration server knows the requirements for these key values ​​and also the type of each controller. Based on this information, the key configuration server can generate the first key configuration data KPDT1.

[0109] The first key configuration data KPDT1 may include key data KDT and the first key configuration information table KPIT1 (key configuration information table 1).

[0110] The key data KDT may include a data number 502, a key value 504, and a purpose value 506. For example, the key data KDT may include a first key value KEY1 and a first purpose value U1 corresponding to a first data number N1, a second key value KEY2 and a second purpose value U2 corresponding to a second data number N2, and a third key value KEY3 and a first purpose value U1 corresponding to a third data number N3.

[0111] The first key configuration information table KPIT1 can be formed differently for different usage values. For example, the first key configuration data KPDT1 may include the first key configuration information table KPIT1 corresponding to the first usage value U1. The key configuration information table KPIT1 can also be formed for the second usage value U2. However, if the second usage value U2 is only for a single device, such a table may not need to be created.

[0112] The first key configuration information table KPIT1 may include a data number 512, a first device unique identifier 514, a second device unique identifier 516, and a key value 518. In this case, the first key configuration information table KPIT1, created and sent by the key configuration server, can be configured with a data number 512 and a key value 518 that are kept empty. Furthermore, the first device unique identifier 514 and the second device unique identifier 516 may not contain device unique identifiers, but only controller type values.

[0113] After receiving the first key configuration data KPDT1, the master device can modify the first key configuration information table KPIT1 to construct the second key configuration information table KPIT2. This second key configuration information table KPIT2 can then be used as pre-configuration data.

[0114] The second key configuration information table KPIT2 may include data number 512, first device unique identifier 514, second device unique identifier 516, key value 518, and usage value 520.

[0115] The master device can check the controller type specified in the first device unique identifier 514 and the second device unique identifier 516 from the first key configuration information table KPIT1 for each application, and arbitrarily select the key values ​​required for those types. For example, the master device can arbitrarily select the key values ​​required for type A and type B from the key values ​​KEY1 and KEY3 corresponding to the first application value U1. Furthermore, the master device can arbitrarily select the key values ​​required for type A and type C from the key values ​​KEY1 and KEY3 corresponding to the first application value U1.

[0116] The master device can specify the selected key value and the key value's data number in the second key configuration information table KPIT2. Additionally, the master device can further specify usage values ​​to generate pre-configured data.

[0117] In addition, the master device can receive the purpose value and unique identifier from the terminal device and use the information to generate the second key configuration data KPDT2a, KPDT2b and KPDT2c.

[0118] The master device can separate different rows 602 and 604 of the second key configuration information table KPIT2 according to the controller, specify the unique identifier received from each controller in the position of the first device unique identifier 514, and specify the unique identifier of the master device in the second device unique identifier 516.

[0119] For key values ​​used only by the terminal device, the second device unique identifier 516 can be marked as N / A (unavailable).

[0120] After creating the second key configuration data KPDT2a and KPDT2b for the terminal device, the master device can generate the second key configuration data KPDT2c by using the information in the request message received from the terminal device and its own information.

[0121] The master device can then send the second key configuration data to the terminal device or store it therein.

[0122] Although not shown in the accompanying drawings, one or more of the multiple key values ​​included in the first key configuration data may be matched with multiple utility values.

[0123] In one implementation, the first key configuration data has been described as including multiple key values ​​and key usage values. However, it may include multiple certificates instead of multiple key values. Alternatively, in addition to multiple key values ​​and key usage values, the first key configuration data may also include multiple certificates and certificate usage values.

[0124] As described above, embodiments of this disclosure provide a flexible and efficient technique for key configuration. Furthermore, embodiments of this disclosure facilitate the distribution of security keys for new features and security keys for updated features in a manner suitable for SDV. Additionally, embodiments of this disclosure provide a technique that does not compromise security even during multiple key configuration processes.

[0125] As used herein, unless otherwise expressly stated, terms such as “include,” “comprise,” or “have” should be interpreted as indicating the possibility of inclusion and therefore should not be interpreted as excluding other components but rather allowing the inclusion of additional components. Unless otherwise defined, all terms (including technical and scientific terms) will be interpreted as having the meaning commonly understood by one of ordinary skill in the art to which this disclosure pertains. Commonly used terms, such as those defined in dictionaries, should be interpreted according to their meaning in the context of the relevant technical field and should not be interpreted in an idealized or overly formal sense unless explicitly defined in this disclosure.

[0126] The foregoing description is merely an illustration of the technical concept of this disclosure, and those skilled in the art should understand that various modifications and alterations can be made without departing from the essential characteristics of this disclosure. Therefore, the embodiments disclosed herein are intended to illustrate, not limit, the technical concept of this disclosure, and the scope of the technical concept should not be construed as limited to these embodiments. The scope of protection of this disclosure should be interpreted based on the appended claims, and all technical concepts falling within the equivalent scope should be considered to be included within the scope of the rights of this disclosure.

Claims

1. A key configuration device, comprising: The communication circuit is configured to receive first key configuration data from the server, which includes multiple key values ​​and the purpose of the keys. as well as The control circuit is configured as follows: Based on the intended use of the key required by the key data receiving device, at least one key value is arbitrarily selected from the plurality of key values. Generate second key configuration data including the at least one key value, and The second key configuration data is sent to the key data receiving device via the communication circuit.

2. The key configuration device according to claim 1, wherein, The control circuit is configured as follows: Based on the purpose value in the first key configuration data, one or more key values ​​among the plurality of key values ​​are identified that correspond to the purpose of the key required by the key data receiving device, and The at least one key value may be selected arbitrarily from the one or more key values.

3. The key configuration device according to claim 1, wherein, The control circuit is configured to delete unused key values ​​after sending the second key configuration data.

4. The key configuration device according to claim 1, wherein, The control circuit is configured as follows: The first key configuration data is received from the server via wireless communication, and The second key configuration data is sent to the key data receiving device using an in-vehicle communication network configured via wired or wireless means.

5. The key configuration device according to claim 1, wherein, The key data receiving device is configured to update an existing key value using at least one key value included in the second key configuration data.

6. The key configuration device according to claim 1, wherein, The control circuit is configured to select at least one key value from a plurality of key values ​​based on the purpose value of the key included in the request message received from the key data receiving device.

7. The key configuration device according to claim 1, wherein, The first key configuration data includes usage values ​​indicating the types of at least two devices, and The second key configuration data includes a usage value indicating a unique identifier for the at least two devices.

8. The key configuration device according to claim 7, wherein, The control circuit is configured to specify a unique identifier for the key configuration device and a unique identifier for the key data receiving device received from the key data receiving device in the second key configuration data.

9. The key configuration device according to claim 1, wherein, One of the multiple key values ​​matches one of the multiple usage values.

10. The key configuration device according to claim 1, wherein, The first key configuration data further includes multiple certificates and the purpose values ​​of the certificates.

11. A key configuration device, comprising: The computing circuit is configured as follows: Generate multiple key values, and For purpose-specific and device-specific keys required within a vehicle, generate first key configuration data including the plurality of key values ​​and the purpose value of the key; as well as The server communication circuit is configured to send the first key configuration data to a device installed on the vehicle.

12. The key configuration apparatus according to claim 11, wherein, The computing circuit is configured to delete the plurality of key values ​​after the first key configuration data is sent to the device.

13. The key configuration apparatus according to claim 12, wherein, Before deleting the plurality of key values, the computing circuit is configured to store the hash operation values ​​of the plurality of key values.

14. A key configuration method, comprising: Receive first key configuration data from the server, which includes multiple key values ​​and the purpose of each key. as well as Based on the intended use of the key required by the key data receiving device, at least one key value is arbitrarily selected from the plurality of key values; Generate second key configuration data including the at least one key value; as well as The second key configuration data is sent to the key data receiving device.

15. The key configuration method according to claim 14, further comprising: The key data receiving device is notified of the start of key configuration; as well as Receive a request message including at least one usage value from the key data receiving device. The arbitrary selection of the at least one key value includes: selecting the at least one key value from the plurality of key values ​​based on at least one usage value received from the key data receiving device.

16. The key configuration method according to claim 15, wherein: The request message includes a unique identifier for the key data receiving device; and Generating the second key configuration data includes including the unique identifier of the key data receiving device in the second key configuration data.

17. The key configuration method according to claim 15, further comprising: When the at least one usage value received from the key data receiving device includes a usage intended for use only within the key data receiving device, the key value corresponding to the usage intended for use only within the key data receiving device is deleted after the second key configuration data is sent.

18. The key configuration method according to claim 14, wherein, One of the multiple key values ​​matches one of the multiple usage values.

19. The key configuration method according to claim 14, further comprising: Receive a first key configuration completion message from the key data receiving device; as well as After receiving the first key configuration complete message, a second key configuration complete message is sent to the server.

20. The key configuration method according to claim 19, wherein, After sending the second key configuration complete message, the plurality of key values ​​are deleted from the server.

Images