Systems and apparatus for enhancing controller area network security
By introducing a CAN gateway and an encrypted data field into the CAN protocol, the security deficiencies of the CAN protocol are resolved, authentication and confidentiality are enhanced, and the security and efficiency of network communication are ensured.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 42DOTE CO LTD
- Filing Date
- 2025-12-30
- Publication Date
- 2026-06-30
AI Technical Summary
The existing Controller Area Network (CAN) protocol lacks security features, resulting in insufficient message authentication, confidentiality protection, and integrity verification capabilities, which increases the risk of network attacks.
By introducing a CAN gateway and multiple CAN nodes, the system is divided into multiple regions. The data field of the seed CAN message is encrypted, and a group session key is generated using a master key and key derivation function to encrypt and verify the integrity of the message.
It enhances the authentication, confidentiality, and integrity of the CAN protocol, ensuring that only authenticated CAN nodes perform network communication, significantly improving security while maintaining compatibility and network efficiency with existing CAN systems.
Smart Images

Figure CN122316673A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a system and apparatus for enhancing the security of a controller local area network (LAN). Background Technology
[0002] While the existing Controller Area Network (CAN) protocol provides effective in-vehicle communication, it suffers from numerous vulnerabilities due to a lack of basic security features.
[0003] In particular, the CAN protocol lacks mechanisms for message authentication, confidentiality protection, and integrity verification, resulting in insufficient defense against unauthorized access and data tampering. This leads to a continuous increase in the risk of various cyberattacks such as replay attacks and spoofing attacks.
[0004] To address these issues, the need for enhanced security features in the CAN protocol is becoming increasingly prominent.
[0005] The aforementioned background technology is reserved by the inventors for the purpose of deriving this invention, or is technical information learned in the process of deriving this invention, and should not be construed as publicly known technology prior to the application of this invention. Summary of the Invention
[0006] The problem the invention aims to solve
[0007] This invention aims to provide a system and apparatus for enhancing the security of a controller local area network (Controller Area Network). The problems to be solved by this invention are not limited to those mentioned above; other problems and advantages not mentioned in this invention can be understood through the following description and will become clearer through embodiments of the invention. Furthermore, it should be understood that the problems and advantages to be solved by this invention can be achieved through the apparatus and combinations thereof specified in the patent claims.
[0008] means for solving problems
[0009] As a technical means to solve the above-mentioned technical problems, the first aspect of this disclosure provides a system for enhancing the security of a controller local area network, comprising: a CAN gateway and multiple CAN nodes; the CAN gateway and the multiple CAN nodes transmit and receive CAN messages divided into multiple regions via a CAN bus; the CAN messages include secure CAN messages; the data field of the secure CAN message is an encrypted data field.
[0010] A second aspect of this disclosure provides a method for enhancing the security of a controller local area network, comprising: encrypting the data field of a seed CAN message based on a master key provided for each vehicle; and transmitting the seed CAN message, including the encrypted data field, to a plurality of CAN nodes via a CAN bus; wherein the data field of the seed CAN message includes an initial seed value, a freshness value (FV), and a message authentication code (MAC).
[0011] A third aspect of this disclosure provides a computer-readable recording medium having a program recorded thereon for executing the method according to the second aspect on a computer.
[0012] In addition, other methods, other systems for implementing the present invention, and a computer-readable recording medium storing a computer program for performing the methods may also be provided.
[0013] Invention Effects
[0014] According to the aforementioned technical solution of this disclosure, authentication, confidentiality, and integrity can be enhanced by adding security functions to the CAN protocol.
[0015] Furthermore, according to the technical solution disclosed herein, network communication can be ensured to be performed only on certified CAN nodes, and security can be significantly improved by encrypting and verifying the integrity of message data.
[0016] Furthermore, the technical solution disclosed herein can maintain compatibility with existing CAN systems, balance the efficiency of the vehicle network, and ensure security. Attached Figure Description
[0017] Figure 1 This is a block diagram of a CAN system according to an embodiment of the present invention.
[0018] Figure 2 This is a diagram illustrating the connection relationship between a CAN gateway, a CAN node, and a CAN bus according to an embodiment.
[0019] Figures 3a to 3d This is a diagram illustrating a CAN message structure according to one embodiment.
[0020] Figure 4 This is a diagram illustrating an example of transmitting CAN messages from a CAN gateway to multiple CAN nodes according to one embodiment.
[0021] Figure 5This is a diagram illustrating the process of generating a group session key according to one embodiment.
[0022] Figures 6a to 6b This is a diagram illustrating an example of a secure CAN message with its data field encrypted.
[0023] Figures 7a to 7b This is a diagram illustrating the structure of the encrypted data field within a secure CAN message according to one embodiment.
[0024] Figure 8 This is a diagram illustrating the process of generating and verifying a secure CAN message according to an embodiment.
[0025] Figures 9a to 9b This is a diagram illustrating a method of utilizing a group session key in a static or dynamic manner according to an embodiment.
[0026] Figure 10 This is a flowchart of a method for enhancing the security of a controller local area network according to an embodiment.
[0027] Figure 11 This is a block diagram of a CAN gateway device according to an embodiment. Detailed Implementation
[0028] If with appendix Figure 1 The advantages, features, and methods of implementing the present invention will become clear from the detailed description of the embodiments. However, it should be understood that the present invention is not limited to the embodiments described below, but can be implemented in many different forms and includes all modifications, equivalents, and even substitutions falling within the scope of the inventive spirit and technology. The embodiments described below are intended to complete this disclosure and fully convey the scope of the invention to those skilled in the art. In describing the invention, detailed descriptions of relevant prior art will be omitted if it is determined that such detailed descriptions would obscure the main points of the invention.
[0029] The terminology used in this application is for illustrative purposes only and is not intended to limit the scope of the invention. Unless the context clearly specifies otherwise, singular expressions include plural expressions. Terms such as "comprising" or "having" in this application are used to specify the presence of features, numbers, steps, actions, constituent elements, components, or combinations thereof described in the specification, and do not preclude the presence or additional possibilities of more than one other feature, number, step, action, constituent element, component, or combination thereof.
[0030] Some embodiments of this disclosure can also be represented by a functional modular structure and various processing steps. Some or all of such functional blocks can be implemented by various numbers of hardware and / or software configurations performing specific functions. For example, functional blocks in this disclosure can be implemented by more than one microprocessor, or by a circuit structure for implementing the specified function. Furthermore, for example, functional blocks of this disclosure can be implemented by various programming or scripting languages. Functional blocks can be implemented by algorithms executed on one or more processors. Additionally, this disclosure can utilize existing technology to implement operations such as electronic environment setting, signal processing, and / or data processing. Terms such as “mechanism,” “element,” “means,” and “construction” are used broadly and should not be limited to mechanical or physical structures.
[0031] Furthermore, the connecting lines or components between the constituent elements shown in the accompanying drawings are merely exemplary representations of functional and / or physical or electrical connections. In actual devices, the connections between the constituent elements can be achieved through various alternative or additional functional, physical, or electrical connections.
[0032] The present disclosure will now be described in detail with reference to the accompanying drawings.
[0033] Figure 1 This is a block diagram of a CAN system according to an embodiment of the present invention.
[0034] The CAN system 100 can be a system that communicates according to any of the CAN 2.0A, CAN 2.0B, CAN-FD, and extended CAN-FD protocols described later.
[0035] Reference Figure 1 The CAN system 100 may include first to third CAN nodes 110, 120, and 130 and a CAN bus 140. Three CAN nodes are shown as an example, but the number of CAN nodes is not limited to this. A CAN node may be referred to as an Electronic Control Unit (ECU). The CAN system 100 can be applied to various fields that employ the CAN protocol. For example, the CAN system 100 may be a vehicle system.
[0036] The first CAN node 110 includes a first processor 111, a first CAN controller 112, and a first transceiver 113. The second CAN node 120 includes a second processor 121, a second CAN controller 122, and a second transceiver 123. The third CAN node 130 includes a third processor 131, a third CAN controller 132, and a third transceiver 133.
[0037] The first to third CAN nodes 110, 120, and 130 are connected to and communicate with the CAN bus 140. For example, when the CAN system 100 is a vehicle system, the first to third CAN nodes 110, 120, and 130 can be devices used for electronic control of various vehicle equipment such as the engine, steering wheel, and brakes.
[0038] The first to third processors 111, 121, and 131 can execute the functions of the central processing unit (CPU) of the corresponding CAN node.
[0039] For example, when the first CAN node 110 is an ECU used to control the engine, the first processor 111 can execute the control actions and calculation actions required for engine control. The first processor 111 can provide the information generated by such control actions and calculation actions as a transmission signal to the first CAN controller 112.
[0040] Furthermore, the first processor 111 can obtain information generated by the second processor 121 or the third processor 131 from the first CAN controller 112. Therefore, the CAN node can interact with other CAN nodes and perform complex functions such as autonomous driving through this interaction.
[0041] The first to third CAN controllers 112, 122, and 132 are used to control the transmission and reception of information for their respective CAN nodes. The first to third CAN controllers 112, 122, and 132 respectively provide information including identifiers to the CAN bus 140. The first to third CAN controllers 112, 122, and 132 determine whether to receive information by analyzing the identifiers of the information provided to the CAN bus 140.
[0042] The identifier indicates the attribute of the information. The first to third CAN controllers 112, 122 and 132 can determine whether the information is required to drive the corresponding CAN node by using the identifier.
[0043] The first to third CAN controllers 112, 122, and 132 can each integrate support for various CAN protocols. Furthermore, the first to third CAN controllers 112, 122, and 132 respectively detect the load of the corresponding processor among the first to third processors 111, 121, and 131, or the load of the CAN bus 140, and can overwrite the latest transmitted or received information. Therefore, the efficiency of the CAN system 100 can be ensured, and information transmission delays caused by load can be prevented, thereby ensuring stability. Details regarding overwriting transmitted or received information will be described later.
[0044] The first to third transceivers 113, 123, and 133 receive and transmit information from the first to third CAN controllers 112, 122, and 132, respectively, and send it to the CAN bus 140. Furthermore, the first to third transceivers 113, 123, and 133 receive and transmit receive information from the CAN bus 140, respectively, and pass it to the first to third CAN controllers 112, 122, and 132.
[0045] The first to third transceivers 113, 123, and 133 can be pre-programmed with a protocol. According to the pre-programmed protocol, the first to third transceivers 113, 123, and 133 can send information to the CAN bus 140 and receive information from the CAN bus 140. The protocol can be any of CAN 2.0A, CAN 2.0B, CAN-FD, and extended CAN-FD protocols, but is not limited to these. The first to third transceivers 113, 123, and 133 can all support the CAN communication protocol and can select a specific protocol based on the vehicle system.
[0046] The CAN bus 140 provides a communication path between the first to third CAN nodes 110, 120, and 130 in the CAN system 100. The first to third CAN nodes 110, 120, and 130 can exchange information with each other via the CAN bus 140. When using the CAN bus 140, information can be exchanged without directly connecting each CAN node, thus ensuring efficiency in terms of the complexity, cost, and weight of connecting CAN nodes.
[0047] Figure 2 This is a diagram illustrating the connection relationship between a CAN gateway, a CAN node, and a CAN bus according to an embodiment.
[0048] The CAN system may include a CAN gateway 200, multiple CAN nodes, and CAN buses 215, 225, and 235. At least a portion of the multiple CAN nodes may be grouped to form CAN node groups 210, 220, and 230. (See reference...) Figure 2 Three CAN node groups 210, 220, and 230 are shown as an example, but the number of CAN node groups is unlimited.
[0049] For example, the first CAN node group 210 consists of CAN nodes related to the engine, the first CAN node in the first group can be a CAN node related to the transmission, and the second CAN node in the first group can be a CAN node related to the battery. Furthermore, the second CAN node group 220 consists of CAN nodes related to braking, the first CAN node in the second group can be a CAN node related to suspension, and the second CAN node in the second group can be a CAN node related to steering. Additionally, the third CAN node group 230 consists of CAN nodes related to lighting, the first CAN node in the third group can be a CAN node related to the seat, and the second CAN node in the third group can be a CAN node related to rear equipment.
[0050] The CAN gateway 200 can connect to multiple CAN nodes within a specific CAN node group via the CAN bus. (See reference...) Figure 2 The CAN gateway 200 can transmit and receive CAN messages with the first CAN bus 215 through the first CAN node group 210, transmit and receive CAN messages with the second CAN bus 225 through the second CAN node group 220, and transmit and receive CAN messages with the third CAN bus 235 through the third CAN node group 230.
[0051] The CAN gateway 200 can perform routing functions. Routing refers to the operation of transmitting messages and data from one communication bus to another. The CAN gateway 200 can send and receive CAN messages between buses of the same type. Furthermore, the CAN gateway 200 can send and receive CAN messages between buses of different types.
[0052] Figures 3a to 3d This is a diagram illustrating a CAN message structure according to one embodiment.
[0053] Reference Figure 3a This shows the structure of a CAN message related to the CAN 2.0A protocol.
[0054] CAN messages in the CAN 2.0A protocol are divided into a start frame, an arbitration field, a control field, a data field, a cyclic redundancy check (CRC) field, an acknowledgment field (ACK field), and an end frame.
[0055] The arbitration field may include an 11-bit identifier ID and a 1-bit Remote Transmission Request (RTR) bit. The identifier ID represents the attributes of the CAN message. The priority of the CAN message can be determined based on the identifier ID. For example, the smaller the identifier ID value, the higher the priority of the CAN message can be set. The RTR bit is used to distinguish between data frames and remote frames, and can have a bit value of 0 in data frames.
[0056] The control field may include a 1-bit Identifier Extension Bit (IDE), a 1-bit Reserved Bit, and a 4-bit Data Length Code (DLC) bit. The IDE bit is used to indicate the CAN 2.0A protocol with an 11-bit identifier ID, and its value can be 0. The DLC bit is used to indicate the length of the data field. In the CAN 2.0A protocol, the length of the data field can be more than 0 bits and less than 64 bits.
[0057] The CRC field can include 15 CRC bits and a 1 CRC delimiter bit. The CRC bits are used to detect errors via cyclic redundancy check. The CRC delimiter bit is used to distinguish the CRC field from the acknowledgment field, and its value can be 1.
[0058] The acknowledgment field may include a 1-bit acknowledgment bit and a 1-bit acknowledgment delimiter. The acknowledgment bit can be set to 1 and provided to the CAN bus during message transmission. When no errors are received during message reception, the acknowledgment bit can be set to 0. The acknowledgment delimiter can be used to distinguish the acknowledgment field from the end frame, and its value can be 1.
[0059] Reference Figure 3b This shows the structure of a CAN message related to the CAN2.0B protocol.
[0060] CAN messages in the CAN 2.0B protocol are divided into a start frame, an arbitration field, a control field, a data field, a CRC field, an acknowledgment field, and an end frame.
[0061] The arbitration field may include an 11-bit first identifier ID1, a 1-bit Substitute Remote Request (SRR) bit, a 1-bit IDE bit, an 18-bit second identifier ID2, and a 1-bit RTR bit. The functions of the first identifier ID1 and the RTR bit are... Figure 3aThe identifier ID and RTR bit function the same. The SRR bit and IDE bit can be used to distinguish it from the CAN 2.0A protocol, and their values can be 1.
[0062] The control field may include 2 reserved bits and 4 data length code (DCL) bits. The DCL bits are used to indicate the length of the data field. In the CAN 2.0B protocol, the length of the data field can be more than 0 bits and less than 64 bits.
[0063] CRC field and Figure 3a It uses the same CAN 2.0A protocol and can include 15 CRC bits and 1 CRC delimiter bit.
[0064] Confirmation domain and Figure 3a It uses the same CAN 2.0A protocol and may include a 1-bit acknowledgment bit and a 1-bit confirmation delimiter.
[0065] Reference Figure 3c This shows the structure of a CAN message related to the CAN-FD protocol.
[0066] The data frames of the CAN-FD protocol are divided into a start frame, an arbitration field, a control field, a data field, a CRC (Cyclic Redundancy Check Field), an acknowledgment field, and an end frame.
[0067] Arbitration jurisdiction and Figure 3a It uses the same CAN 2.0A protocol and can include an 11-bit identifier (ID) and a 1-bit RTR bit.
[0068] The control field may include a 1-bit IDE bit, a 1-bit Extended Data Length (EDL) bit, a 1-bit Reserved bit, a 1-bit Bit Rate Switch (BRS) bit, a 1-bit Error State Indicator (ESI) bit, and a 4-bit DLC bit. The IDE bit indicates the CAN 2.0A series protocol with an 11-bit identifier (ID), and its value can be set to 0. The EDL bit indicates the FD protocol with an extended data field length; its value can be 1 when the data field length is 8 bytes or more. The BRS bit is used to switch to a higher baud rate when transmitting data fields, and its value can be 1. The ESI bit is used to identify errors that occur when transmitting information in the CAN 2.0A FD protocol. The DLC bit indicates the length of the data field in bytes. In the CAN 2.0A FD protocol, the data field length can be 0 bytes or more and 64 bytes or less.
[0069] The CRC field may include 17 or 21 CRC bits and a 1-bit CRC delimiter. Compared to the CAN 2.0A protocol, the length of the CRC bits used for Cyclic Redundancy Check (CRC) calculation has increased due to the increased length of the data field. The CRC delimiter is used to distinguish the CRC field from the acknowledgment field, and its value can be 1. Although not illustrated, the CRC field may also include a stuff count (SC) bit used to reflect the stuffing bits during CRC calculation.
[0070] Confirmation domain and Figure 3a It uses the same CAN 2.0A protocol and may include a 1-bit acknowledgment bit and a 1-bit confirmation delimiter.
[0071] Figure 3d The structure of a CAN message for the extended CAN-FD protocol is shown.
[0072] For the extended CAN-FD protocol, the data frame is divided into a start frame, an arbitration field, a control field, a data field, a CRC (Cyclic Redundancy Check) field, an acknowledgment field, and an end frame.
[0073] Arbitration jurisdiction and Figure 3b The CAN 2.0B protocol is the same and can include an 11-bit first identifier ID1, a 1-bit SRR bit, a 1-bit IDE bit, an 18-bit second identifier ID2, and a 1-bit RTR bit.
[0074] The control field may include a 1-bit EDL bit, a 1-bit reserved bit, a 1-bit BRS bit, a 1-bit ESI bit, and a 4-bit DLC bit. The functions of the EDL bit, reserved bit, BRS bit, ESI bit, and DLC bit are... Figure 3c In the standard CAN-FD protocol, the EDL bit, reserved bit, BRS bit, ESI bit, and DLC bit have the same function. In the extended CAN-FD protocol, the data field length can be more than 8 bytes and less than 64 bytes.
[0075] CRC field and Figure 3c The CAN-FD protocol is the same and can include 17 or 21 CRC bits and a 1-bit CRC delimiter bit. The acknowledgment field is the same as... Figures 3a to 3c The protocol is the same and may include a 1-bit acknowledgment bit and a 1-bit confirmation delimiter.
[0076] on the other hand, Figures 3a to 3d The CAN 2.0A, CAN 2.0B, CAN-FD, and extended CAN-FD protocols shown all have data fields (310 to 340) included within the control domain.
[0077] This disclosure provides a data transmission and reception method that enhances the security of the CAN protocol by encrypting the data fields (310 to 340) of CAN messages. Hereinafter, CAN messages with encrypted data fields (310 to 340) are referred to as secure CAN messages, and CAN messages with unencrypted data fields (310 to 340) are referred to as normal CAN messages.
[0078] Figure 4 This is a diagram illustrating an example of transmitting CAN messages from a CAN gateway to multiple CAN nodes according to one embodiment.
[0079] The CAN gateway 410 and multiple CAN nodes 420, 430, and 440 can send and receive CAN messages via the CAN bus 415.
[0080] CAN messages can include safety CAN messages and normal CAN messages. Normal CAN messages are... Figures 3a to 3d According to the above protocol, a CAN message is a message whose data field is not encrypted, while a secure CAN message is a message whose data field is encrypted.
[0081] In one embodiment, among the multiple CAN nodes 420, 430, and 440, the first CAN node equipped with a Hardware Security Module can decrypt secure CAN messages. The second CAN node without a Hardware Security Module cannot decrypt secure CAN messages, but since the data structure of secure CAN messages is the same as that of ordinary CAN messages, no error will occur even if the second CAN node receives a secure CAN message.
[0082] The first CAN node can decrypt CAN messages using the group session key. The following steps, as preparation for generating the group session key, describe the content of the seed CAN message transmitted by the CAN gateway 410.
[0083] The CAN gateway 410 can transmit a seed CAN message to the first CAN node so that the first CAN node can generate a group session key. The seed CAN message needs to be processed with priority over other CAN messages; therefore, the identifier ID of the seed CAN message can be assigned a smaller value compared to other CAN messages.
[0084] The data field of a seed CAN message may include an initial seed value, a freshness value, and a message authentication code. The initial seed value is a value randomly generated each time the vehicle starts. In this disclosure, confidentiality can be improved by using a different initial seed value each time the vehicle starts. The FV is a value that increments sequentially and cyclically within a specific range. In this disclosure, replay attacks can be prevented by importing the FV. The MAC can be set to a MAC generated for the IS and FV values. When the data field length is limited (e.g., 8 bytes), a portion of the original MAC can be used. In this disclosure, message integrity can be verified by using the MAC.
[0085] In one embodiment, the CAN gateway 410 can use a master key to encrypt the data field of a seed CAN message, and then transmit it to multiple CAN nodes 420, 430, and 440 via the CAN bus 415. The master key is a key provided to each vehicle, and each vehicle has a unique static value. All CAN nodes within the same vehicle can use the same master key.
[0086] Figure 5 This is a diagram illustrating the process of generating a group session key according to one embodiment.
[0087] The first CAN node in a multi-CAN node configuration may be equipped with a hardware security module. This hardware security module stores the master key. Furthermore, the first CAN node can receive seed CAN messages from the CAN gateway.
[0088] The first CAN node can generate a group session key based on the master key and seed CAN message. The group session key can be generated using a key derivation function.
[0089] Reference Figure 5 Group session keys can be generated by applying key derivation functions to the master key, initial seed value, FV, and MAC. For example, a group session key can be generated using the following mathematical formula 1. In mathematical formula 1, the seed can be a value calculated from the initial seed value, FV, and MAC. KDF can use PBKDF2-HMAC-SHA2, but is not limited to it.
[0090] Mathematical formula 1:
[0091]
[0092] Figures 6a to 6b This is a diagram illustrating an example of a secure CAN message with its data field encrypted.
[0093] Reference Figure 6a It shows the relevant Figure 3a The structure of a CAN message in the CAN 2.0A protocol is shown. Figure 6a The CAN message is equivalent to an unencrypted ordinary CAN message in data field 610.
[0094] Reference Figure 6b This shows a secure CAN message including the encrypted data field 620.
[0095] A CAN gateway can generate a group session key by applying a key derivation function to the master key provided for each vehicle. The CAN gateway can generate the group session key by applying the master key, initial seed value, FV, and MAC to the key derivation function. For example, the group session key can be generated using Equation 1 above.
[0096] CAN gateway can not only Figure 3a It can operate using the CAN 2.0A protocol and can also... Figures 3b to 3d The data fields (320 to 340) of the CAN 2.0 B protocol, CAN-FD protocol and extended CAN-FD protocol shown are encrypted, and secure CAN messages including the encrypted data fields are transmitted to multiple CAN nodes.
[0097] Figures 7a to 7b This is a diagram illustrating the structure of the encrypted data region within a secure CAN message according to one embodiment.
[0098] Reference Figure 7aThis shows a secure CAN message related to the CAN 2.0A protocol. The following content also applies to the CAN 2.0B protocol.
[0099] Secure CAN messages include an encrypted data field 710. In one embodiment, the structure of the encrypted data field 710 can vary depending on the mode. In a first mode, the encrypted data field 710a can be divided into a first area for transmitting data and a second area for transmitting the message authentication code. In the CAN 2.0A protocol, the maximum length of the encrypted data field 710 can be 8 bytes. To transmit the MAC simultaneously, the encrypted data field 710a can adopt a structure consisting of a first area of 7 bytes and a second area of 1 byte.
[0100] On the other hand, to eliminate the data length limitation of secure CAN messages, although security is reduced, in the second mode, secure CAN messages can transmit only encrypted data, excluding MAC. In the second mode, the encrypted data field 710b can consist only of a first area for transmitting data, and the length of the first area can be 8 bytes.
[0101] Reference Figure 7b This illustrates a secure CAN message for the CAN-FD protocol. The following content also applies to the extended CAN-FD protocol.
[0102] Secure CAN messages include an encrypted data area 720. In one embodiment, the structure of the encrypted data area 720 can vary depending on the mode. In a first mode, the encrypted data field 720a can be divided into a first area for transmitting data and a second area for transmitting the message authentication code. In the CAN-FD protocol, the maximum length of the encrypted data field 720 can be 64 bytes. To transmit the MAC simultaneously, the encrypted data field 720a can adopt a structure consisting of a first area of 63 bytes and a second area of 1 byte.
[0103] On the other hand, to eliminate the data length limitation of secure CAN messages, although security is reduced, in the second mode, secure CAN messages can transmit only encrypted data, excluding MAC. In the second mode, the encrypted data field 720b can consist only of a first area for data transmission, and the length of the first area can be 64 bytes.
[0104] Figure 8 This is a diagram illustrating the process of generating and verifying a secure CAN message according to an embodiment.
[0105] Reference Figure 8The sender can be a CAN gateway that encrypts and transmits secure CAN messages, while the receiver can be a CAN node that receives and decrypts secure CAN messages (e.g., a CAN node equipped with a hardware security module).
[0106] The following assumes that both the sender 810 and the receiver 820 have a group session key.
[0107] The sender 810 can use the group session key to encrypt the data field of the secure CAN message and generate a MAC. The process of encrypting the data field can be represented by the following mathematical formula 2 or mathematical formula 3. In mathematical formula 2 and mathematical formula 3, M can represent the unencrypted original data, C represents the encrypted data, and Enc represents the encryption algorithm, such as the AES 128 algorithm.
[0108] Mathematical formula 2:
[0109]
[0110] Mathematical formula 3:
[0111]
[0112] If the performance load is not affected even if the group session key is encrypted twice, the sender 810 can use mathematical formula 2 to encrypt the data field. If the performance load is affected, the sender 810 can use mathematical formula 3 to encrypt the data field.
[0113] MAC is a value related to the initial seed value and FV, and can be generated, for example, by the CMAC_AES algorithm.
[0114] The encrypted data field can be divided into a first area for transmitting data and a second area for transmitting message authentication codes. The sender 810 can transmit a secure CAN message, including the encrypted data field, to the receiver 820.
[0115] The receiver 820 can first verify the integrity using the MAC. After the integrity is verified, it can use the group session key to decrypt the encrypted data field of the secure CAN message.
[0116] The process of decrypting the data field can be represented by the following mathematical formula 4 or mathematical formula 5. In mathematical formula 4 and mathematical formula 5, M can represent the unencrypted original data, C can represent the encrypted data, and Dec can represent the decryption algorithm, such as the AES 128 algorithm.
[0117] Mathematical formula 4:
[0118]
[0119] Mathematical formula 5:
[0120]
[0121] When the sender 810 encrypts the data field according to mathematical formula 2, the receiver 820 decrypts the data field using mathematical formula 4. When the sender 810 encrypts the data field according to mathematical formula 3, the receiver 820 can decrypt the data field using mathematical formula 5.
[0122] Figures 9a to 9b This is a diagram illustrating a method of utilizing a group session key in a static or dynamic manner according to an embodiment.
[0123] The period from when the vehicle is started until it is turned off will be referred to as the session period.
[0124] Reference Figure 9a The following illustrates the static group session key scenario (hereinafter, the first scenario). In the first scenario, a group session key (Key A) is generated from the master key of a specific vehicle, and only the generated group session key (Key A) is used within a session period, even as time passes. In the first scenario, a new group session key is only generated when a new session period begins after the end of one session period.
[0125] Reference Figure 9b The diagram illustrates a dynamic group session key scenario (hereinafter, the second scenario). In the second scenario, multiple group session keys (Key B, Key C, Key D...) are generated from the master key of a specific vehicle. The CAN gateway can select any one of these group session keys as the representative group session key for encrypting the data field of secure CAN messages. In this case, the representative group session key may change even within a session period. For example, by applying a time window within a session period, any one of the multiple group session keys can be reselected as the new representative group session key at predetermined intervals. When applying the second scenario, the CAN gateway and multiple CAN nodes equipped with hardware security modules can have the same number of group session keys.
[0126] In this disclosure, as in the second scenario, multiple group session keys can be used to further enhance security even within a single session period.
[0127] In addition, refer to Figure 2 Different group session keys can be applied to the first through third CAN node groups 210, 220, and 230. In this disclosure, to improve security, a different group session key is applied to each CAN node group within a session cycle.
[0128] Figure 10 This is a flowchart of a method for enhancing the security of a controller local area network according to an embodiment.
[0129] Figure 10 The method for enhancing controller area network security shown is related to the embodiments illustrated in the foregoing figures. Therefore, even if some details are omitted below, the content described in the foregoing figures is equally applicable. Figure 10 The method.
[0130] Reference Figure 10 In step 1010, the processor may encrypt the data field of the seed CAN message based on the master key provided for each vehicle.
[0131] In one embodiment, the data field of the seed CAN message may include an initial seed value, a freshness value, and a message authentication code. The initial seed value is a value randomly generated each time the vehicle is started. The FV is a value that is sequentially incremented and cycled within a specific range, and the MAC can be set to a MAC generated for the IS and FV values. When the data field length is limited (e.g., 8 bytes), a portion of the original MAC can be used.
[0132] In step 1020, the processor can transmit a seed CAN message, including an encrypted data field, to the plurality of CAN nodes via the CAN bus.
[0133] Seed CAN messages require preprocessing compared to other CAN messages; therefore, the ID value of the seed CAN message can be relatively smaller than the value assigned to other CAN messages.
[0134] In addition, the processor can apply a key derivation function to the master key provided for each vehicle to generate a group session key.
[0135] The group session key can be a value that is regenerated each time the vehicle is started. The group session key can be a value generated by applying a key derivation function to the master key, the initial seed value, the FV, and the MAC.
[0136] In addition, the processor can use a group session key to encrypt the data field of the secure CAN message.
[0137] The structure of the encrypted data field of a secure CAN message can vary depending on the mode. In the first mode, the encrypted data field of a secure CAN message can be divided into a first area for transmitting data and a second area for transmitting the message authentication code. Alternatively, in the second mode, the encrypted data field of a secure CAN message may consist only of the first area for transmitting data.
[0138] In addition, the processor can transmit secure CAN messages with encrypted data fields to multiple CAN nodes.
[0139] In one embodiment, among multiple CAN nodes, at least one first CAN node equipped with a hardware security module can generate a group session key based on a master key and a seed CAN message. Furthermore, the first CAN node can receive secure CAN messages via the CAN bus and use the generated group session key to decrypt the encrypted data field of the secure CAN message.
[0140] In one embodiment, the encrypted data field of a secure CAN message can be divided into a first area for transmitting data and a second area for transmitting message authentication codes. The first CAN node can use MAC to verify integrity, and after the integrity is verified, it can use the group session key to decrypt the data in the first area.
[0141] Figure 11 This is a block diagram of a CAN gateway device according to an embodiment.
[0142] Reference Figure 11 The CAN gateway device (hereinafter, device) 1100 may include a communication unit 1110, a processor 1120, and a database 1130. Figure 11 Only the components relevant to the embodiments are shown in the device 1100. Therefore, those skilled in the art who are familiar with this embodiment will understand that, in addition to Figure 11 In addition to the constituent elements shown, other general constituent elements may also be included.
[0143] The communication unit 1110 may include one or more components that enable wired / wireless communication with an external server or external device. For example, the communication unit 1110 may include at least one of a near-field communication unit (not shown), a mobile communication unit (not shown), and a broadcast receiving unit (not shown).
[0144] Database 1130 is hardware used for storing various data processed within storage device 1100, and can store programs for processing and control by processor 1120.
[0145] Database 1130 may include random access memory (RAM) such as dynamic random access memory (DRAM) and static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), CD-ROM, Blu-ray or other optical disc storage, hard disk drive (HDD), solid state drive (SSD), or flash memory.
[0146] The processor 1120 controls the overall operation of the device 1100. For example, the processor 1120 executes a program stored in the database 1130, thereby enabling overall control of the input unit (not shown), display (not shown), communication unit 1110, database 1130, etc. The processor 1120 can control the operation of the device 1100 through the program stored in the database 1130.
[0147] Processor 1120 can control Figures 1 to 10 At least a portion of the operation of the device described herein.
[0148] The processor 1120 may be implemented using at least one of application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, micro-controllers, microprocessors, and electrical units for performing other functions.
[0149] As one embodiment, device 1100 can be a mobile electronic device. For example, device 1100 can be a smartphone, tablet PC, personal computer (PC), smart TV, personal digital assistant (PDA), laptop, media player, navigation device, device equipped with a camera, and other mobile electronic devices. Furthermore, device 1100 can be a wearable device such as a watch, glasses, hairband, and ring with communication and data processing functions.
[0150] As another embodiment, device 1100 may be an electronic device embedded in a vehicle. For example, device 1100 may be an electronic device inserted into a vehicle after tuning following the production process.
[0151] In another embodiment, device 1100 may be a server located outside the vehicle. The server may be a computer device or multiple computer devices that provide instructions, code, files, content, services, etc., via network communication. The server may receive data required to determine the vehicle's movement path from a device mounted in the vehicle, and determine the vehicle's movement path based on the received data.
[0152] According to embodiments of the present invention, the computer program can be executed by various components of a computer and can be recorded on a computer-readable medium. In this case, the medium includes magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floppy disks; and hardware devices specifically configured to store and execute program commands, such as ROMs, RAMs, and flash memory.
[0153] On the other hand, the computer program may be specifically designed and configured for this invention, or it may be known and available to those skilled in the art of computer software. Examples of computer programs include not only machine language code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or similar means.
[0154] According to one embodiment, the methods of various embodiments of this disclosure may be provided in a computer program product. The computer program product may be traded as a commodity between a seller and a buyer. The computer program product may be in the form of a device-readable storage medium (e.g., a CD-ROM (compact disc read-only memory)) or through an application store (e.g., the Play Store). TMAlternatively, it can be distributed online directly between two user devices (e.g., download or upload). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.
[0155] For the steps constituting the method described in this invention, if their order is not explicitly stated or if there is a contrary statement, the steps may be performed in an appropriate order. This invention is not limited to the order in which the steps are described above. All examples or exemplary terms used in this invention (e.g., etc.) are for illustrative purposes only and the scope of this invention is not limited by the examples or exemplary terms unless defined by the patent claims. Furthermore, those skilled in the art will understand that configurations can be made within the scope of the claims, which may include various modifications, combinations, and variations, or their equivalents, depending on design conditions and factors.
[0156] Therefore, the concept of this invention should not be limited to the embodiments described above, and all scopes of the claims and their equivalents or variations should be included within the scope of the concept of this invention.
Claims
1. A system for enhancing the security of a controller local area network, characterized in that, include: Controller Area Network (MAN) gateway, and Multiple controller LAN nodes; The controller LAN gateway and the plurality of controller LAN nodes send and receive controller LAN messages divided into multiple regions via the controller LAN bus. The controller area network messages include secure controller area network messages; The data field of the security controller LAN message is an encrypted data field.
2. The system for enhancing the security of a controller local area network according to claim 1, characterized in that, The structure of the encrypted data field of the security controller LAN message changes according to the pattern.
3. The system for enhancing the security of a controller local area network according to claim 2, characterized in that, In the first mode, the encrypted data field of the security controller LAN message is divided into a first area for transmitting data and a second area for transmitting message authentication codes.
4. The system for enhancing the security of a controller local area network according to claim 2, characterized in that, In the second mode, the encrypted data field of the security controller LAN message includes only the first area used for data transmission.
5. The system for enhancing the security of a controller local area network according to claim 1, characterized in that, The controller area network gateway is configured as follows: The seed controller LAN message data field is encrypted based on the master key provided for each vehicle, and the seed controller LAN message including the encrypted data field is transmitted to the plurality of controller LAN nodes through the controller LAN bus. The data field of the seed controller LAN message includes the initial seed value, freshness value, and message authentication code.
6. The system for enhancing the security of a controller local area network according to claim 1, characterized in that, The controller area network gateway is configured as follows: A key derivation function is applied to the master key provided for each vehicle to generate a group session key, and the group session key is used to encrypt the data field of the security controller LAN message. The group session key is regenerated each time the vehicle is started.
7. The system for enhancing the security of a controller local area network according to claim 6, characterized in that, The group session key is generated by applying the key derivation function to the master key, initial seed value, freshness value, and message authentication code.
8. The system for enhancing the security of a controller local area network according to claim 5, characterized in that, At least one first controller area network node among multiple controller area network nodes is equipped with a hardware security module. A group session key is generated based on the master key and the seed controller LAN message.
9. The system for enhancing the security of a controller local area network according to claim 8, characterized in that, The first controller LAN node is configured as follows: The system receives the security controller LAN message via the controller LAN bus and decrypts the encrypted data field of the security controller LAN message using the group session key.
10. The system for enhancing the security of a controller local area network according to claim 9, characterized in that, The encrypted data field of the security controller LAN message is divided into a first area for transmitting data and a second area for transmitting message authentication codes. The first controller LAN node is configured as follows: The integrity is verified using the message authentication code, and after the integrity is verified, the data in the first area is decrypted using the group session key.
11. The system for enhancing the security of a controller local area network according to claim 6, characterized in that, The controller area network gateway is configured as follows: A key derivation function is applied to the master key provided for each vehicle to generate multiple group session keys, and any one of the multiple group session keys is selected as the representative group session key to encrypt the data field of the security controller LAN message; The group session key is changed at predetermined intervals even when the vehicle is still running.
12. A method for enhancing the security of a controller local area network, characterized in that, include: The steps for encrypting the data field of seed controller LAN messages based on the master key provided for each vehicle, and The step of transmitting the seed Controller Area Network message, including the encrypted data field, to multiple Controller Area Network nodes via the Controller Area Network bus; The data field of the seed controller LAN message includes the initial seed value, freshness value, and message authentication code.
13. A computer-readable recording medium having a program for performing the method of claim 12 on a computer.