Communication systems, transmitters, and receivers

Abstract

Provided is a communication system that performs security communication using a key between a transmitter and a receiver, wherein the key can be changed in the security communication, the transmitter transmits a notification related to a key change timing when a new key after a change becomes available and transmits data by an old key before the change in a first predetermined period after the new key becomes available, and the receiver performs recognition processing in reception by the old key in a second predetermined period after the new key becomes available, and performs, when receiving the notification related to the key change timing from the transmitter, recognition processing by the old key for data transmitted before the key change timing and recognition processing by the new key for data transmitted after the key change timing.

Description

Technical Field

[0001] The present invention relates to a communication system for performing secure communication.

Background Art

[0002] One of the mechanisms for preventing impersonation in computer secure communication is as follows. For example, a hash value is calculated using a key common to communication devices, and it is determined whether the received hash value matches the calculated hash value by comparing it with the calculation result of the receiver.

[0003] According to the AUTOSAR specification used for in-vehicle software of automobiles, it is possible to prevent impersonation by attaching a MAC (Message Authentication Code) calculated with a common key to a CAN message frame. In addition, by adding a freshness value, it is possible to prevent a replay attack.

[0004] In secure communication using a common key, if the timing of key change in each communication device is not simultaneous when changing the key, a communication impossible state may occur due to authentication failure of secure communication. In addition, a notification at the time of authentication failure may occur, and the communication load may increase.

[0005] The following are the background technologies related to key change. First, there is a method of sequentially executing key change in each communication device, and second, there is a method of changing to a key change mode or the like at the time of key change, completing the change of the keys of all communication devices on the network, and then returning to the normal mode.

[0006] In the first case, due to the difference in the timing when the key change is completed, a period in which the keys are different occurs between devices on the network, a period in which secure communication is impossible occurs during that period, and a failure of secure communication occurs.

[0007] In the second case, in the key change mode, at least the secure communication function used in the normal mode is restricted, so the key change process is restricted by a specific situation.

[0008] The following background technologies exist for techniques that change keys during communication. Patent Document 1 (Japanese Patent Publication No. 2012-227672) describes a vehicle-to-vehicle / vehicle-to-infrastructure communication system consisting of a key management server that manages a common key, a roadside unit, and an in-vehicle unit, characterized in that the key management server manages areas, and roadside units and in-vehicle units located in a given area share the same common key, and the shared common key is used to guarantee the confidentiality or integrity of messages, or both. [Prior art documents] [Patent Documents]

[0009] [Patent Document 1] Japanese Patent Publication No. 2012-227672 [Overview of the project] [Problems that the invention aims to solve]

[0010] In the aforementioned background technology, when changing the key used at an arbitrary time, as envisioned by the present application, or when changing to an arbitrary key that has not been predetermined, it is difficult to determine the timing of the change to an unknown new key. Furthermore, time synchronization is necessary to synchronize the key change timing between communication devices.

[0011] The present invention aims to mitigate security communication failures associated with key changes. [Means for solving the problem]

[0012] A representative example of the invention disclosed in this application is as follows: a communication system that performs secure communication between a transmitter and a receiver using a key, wherein the key can be changed during the secure communication, the transmitter sends a notification regarding the key change timing when the new key becomes available, transmits data using the old key during a first predetermined period after the new key becomes available, the receiver performs authentication processing using the old key during the period from when the new key becomes available until the key change timing, and when the receiver receives a notification regarding the key change timing from the transmitter, it authenticates data transmitted before the key change timing using the old key, and authenticates data transmitted after the key change timing using the new key. From the key management device After receiving the new key mentioned above to If you have no experience receiving data with the aforementioned new key In that case, or before the aforementioned key change timing to The system is characterized in that if authentication using the old key fails, authentication is performed using the new key. [Effects of the Invention]

[0013] According to a typical embodiment of the present invention, failures in security communication associated with key changes can be reduced. Other issues, configurations, and effects not mentioned above will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0014] [Figure 1] This is a flowchart illustrating an example of the processing of a transmitter according to an embodiment of the present invention. [Figure 2] This is a flowchart illustrating an example of receiver processing in an embodiment of the present invention. [Figure 3A] This is a flowchart illustrating an example of receiver processing in the first method. [Figure 3B] This is a flowchart illustrating an example of receiver processing in the first method. [Figure 4A] This is a flowchart illustrating an example of receiver processing in the second method. [Figure 4B]It is a flowchart of an example of the receiver's processing in the second method. [Figure 5] It is a timing chart of an operation example of this embodiment. [Figure 6] It is a timing chart of an operation example of the second method. [Figure 7] It is an explanatory diagram when the reception processing order is switched. [Figure 8] It is a diagram showing the timing of key change in this embodiment. [Figure 9] It is a diagram showing the timing of key change in this embodiment. [Figure 10] It is a diagram showing the configurations of the transmitter and receiver in an embodiment of the present invention.

Mode for Carrying Out the Invention

[0015] In an embodiment of the present invention, when a key change command is given, after the key reception is completed, the transmitter continues to transmit with the old key for a predetermined period 1, and the receiver authenticates the received message with the old key for a predetermined period 2.

[0016] Here, the timing of key reception completion may be a state where the key to be used can be switched. Also, when the next common key to be used is determined in advance, the timing of receiving a command to use the next common key or the like may be regarded as the timing of key reception completion. Further, the timing of key reception completion may be specified in advance by date and time or the like.

[0017] The old key may be deleted or locked after the end of the predetermined period 1 or the predetermined period 2 in both the transmitter and the receiver. Since the old key is used during the key mismatch period and when the transmission and reception processing orders are switched, it may be deleted or locked when it becomes impossible to receive a frame authenticated with the old key due to the switch. In the case of the transmitter, since transmission processing using the old key is not performed after the timing of switching the key to be used to the new key, it may be immediately deleted. It may be other timings than those exemplified, and the deletion timing may be various timings.

[0018] An example of a method for determining and setting predetermined periods 1 and 2 will be explained.

[0019] As the first method, we will explain how to identify the timing of key changes using the freshness value.

[0020] Figure 1 is a flowchart of an example of the transmitter's processing, and Figures 2, 3A, and 3B are flowcharts of an example of the receiver's processing. Figure 2 describes the processing up to the determination of the timing of the key change to be used, and Figures 3A and 3B describe the reception processing from the start of the key change process until the key switch is completed. Figures 1 and 2 may start when a key change command is received, respectively. Figures 3A and 3B may also represent the reception processing of security communications from the time the receiver receives the key change command until transmission using the old key ceases.

[0021] In the first method, one example of a period is the freshness value, but any value that allows timing to be measured between communication devices is acceptable, and time, number of communications, etc., can be used.

[0022] As shown in Figure 1, the transmitter receives the new key from the key management device at the key change timing, waits until the new key is usable (S101), and determines whether it has received the key ready notification 1 until a predetermined time has elapsed and a timeout occurs (S107) (S102). If the predetermined time has elapsed and a timeout occurs without receiving the key ready notification 1 (YES in S107), the timeout processing is executed (S108). The timeout processing can be arbitrary; for example, it may involve canceling the key change process or sending an error notification. Alternatively, processing may continue without a timeout. On the other hand, if the key ready notification 1 is received (S102), the key change timing is determined (S103), and the key change timing notification 2 is sent (S104). The key change timing is a future timing after the receiving side's preparation time, and can be calculated, for example, by adding a predetermined value to the current time (current freshness value). A value that can measure time or communication sequence may be used instead of the freshness value. Considering the disruption of the data arrival order, it is advisable to use a sequentially assigned freshness value. The key change timing notification 2 includes the freshness value at the time of the key change. This value represents a predetermined period 1 (time 1a in Figure 6), which is preferably a future timing, but it should be set to a period during which the receiver can sufficiently receive the key change timing notification 2. For example, the value can be set based on the communication design, based on communication conditions such as communication load, frequency, and number of recipients, or it can be set dynamically based on these factors.

[0023] Subsequently, the transmitter determines whether the key change timing 3 has been reached (S105). If the key change timing has not been reached, it repeatedly sends a key change timing notification at predetermined intervals (S109) and continues to determine whether the key change timing has been reached. On the other hand, if the key change timing has been reached, it switches the key to be used for transmission (S106). The periodic transmission in step S109 may be set at an interval such that a predetermined number of transmissions are made before the key change timing is reached.

[0024] As shown in Figure 2, the receiver waits until the new key is available (S201), and once the key reception is complete, sends a key ready notification 1 (S202). Then, it determines whether it has received a key change timing notification 2 (S203). If it has not received a key change timing notification 2, it returns to step S202 and may send key ready notification 1 until it receives a key change timing notification 2. It may also send key change timing notification 2 multiple times. On the other hand, if it has received a key change timing notification 2, it determines the key change timing 3 according to the received key change timing notification (S204). A predetermined waiting time may be added before sending step S202. By waiting for the maximum time required for the receiver to receive the new key, the number of cases where the key ready notification 1 is not received can be reduced. If the key change timing notification 2 is not received in step S203 by the predetermined time, the timeout processing may be executed. One example is the cancellation of the key change process or the notification of an error.

[0025] If there are multiple receivers, the transmitter should send the key change timing notification 2 only after receiving the key readiness notification 1 from all receivers. If the transmitter fails to receive the key readiness notification 1 from at least some receivers, it may set a timeout and continue the subsequent processing. In this case, it may ignore the receivers that did not receive the key readiness notification 1 and continue the transmission and reception process using the new key, or it may restrict communication across the entire network. Predetermined processing to be performed in such cases may be executed in step S108. If a timeout occurs, any processing that occurs at the timeout may be executed. For example, an error notification or cancellation of the key change process may be performed.

[0026] As shown in Figures 3A and 3B, after receiving the key change command, the receiver extracts the received freshness value from the received data (S301). Note that the freshness value does not need to be extracted each time; it may be estimated from the freshness value received previously. It is determined whether the key change timing notification 2 has been received (S302). If the key change timing notification 2 has been received, it is determined whether the received freshness value is after the key change timing (S303). Then, if the received freshness value is after the key change timing, the new key is used for reception (S304), and if the received freshness value is before the key change timing, the old key is used for reception (S305). This period is the predetermined period 2 (2a in Figure 6). Similarly, when the timing is defined by time or number of communications, it is good practice to use different keys depending on whether it is before or after the key change timing.

[0027] The receiver then determines whether authentication was successful (S306). For example, authentication may be determined by checking whether the transmitted data and the hash value of the freshness value match. Alternatively, if the received freshness value is received again, authentication may be determined to have failed. If authentication is successful, the success processing is executed (S307), and if authentication fails, the failure processing is executed (S308). If the receiver has received the key change timing notification 2, it can be considered that, theoretically, the cause of authentication failure is not an error in the key used during the switching process between the new and old keys. Therefore, the processing for authentication failure and success (S308, S307) during the key switching process may be omitted, and processing may be performed according to the original authentication result, or steps S307 and S308 may be processing according to the original authentication result.

[0028] If the key change timing notification 2 is not received in step S302, it is determined whether the new key has been received before and whether the received freshness value is after the key change timing (predetermined period 2 (2b in Figure 6)) (S316). If the new key has not been received before, or if the received freshness value is not after the key change timing (NO in S316), it is unclear whether it is the new key or the old key, so authentication is attempted with both the old and new keys. That is, authentication is performed with the old key (S309), and it is determined whether the authentication was successful (S310). If authentication with the old key is successful, the authentication success processing is executed (S314). If authentication with the old key fails, authentication is performed with the new key (S311), and it is determined whether the authentication was successful (S312). If authentication with the new key is successful, from now on authentication should be done with the new key, so the key change timing is changed based on the received freshness value, and that timing is set as the end of the predetermined period 2 (2b in Figure 6) (S313). If authentication with the new key fails, the authentication failure process is executed (S315).

[0029] On the other hand, if the new key has been used for reception before and the reception freshness value is after the key change timing (YES in S316), authentication is performed with the new key (S317), and it is determined whether the authentication was successful (S318). If authentication with the new key is successful, the authentication success processing is executed (S319). If authentication with the new key fails, the authentication failure processing is executed (S320). In other words, authentication is performed with the new key at any freshness value timing after the last authentication with the new key.

[0030] In step S313, if authentication with the new key is successful for multiple incoming communications, the one with the smallest freshness value is adopted, and the key change timing is changed based on that smallest freshness value. The maximum freshness value for which authentication with the old key was successful is recorded, and for incoming communications below this maximum value, it is not necessary to attempt authentication with the new key. If the key change timing notification 2 is not received, it may be treated as an error, in which case the re-authentication process with the new key after authentication failure with the old key is not performed. When security communications using the old key are no longer received, reception using the old key may be stopped, and normal security communication processing using the new key may be performed.

[0031] For freshness values ​​where it is unclear whether the key used is the old or new key—that is, values ​​between the maximum and minimum freshness values ​​received with the new key—the system may decide which key to try first, the new or old key, depending on the freshness value. For example, if the value is close to the maximum value of the old key, the system may try with the old key first, and if it is close to the minimum value of the new key, the system may try with the new key.

[0032] Note that steps S311, S312, and S313, which occur when the key change timing notification 2 is not received in S302, are optional processes that serve as countermeasures in case the key change timing notification 2 fails to be received. In S302, if the key change timing notification 2 is not received, an authentication error (e.g., S315) may be generated without attempting authentication with the new key.

[0033] Until the key change timing 2 is received (while S302 is NO), the normal authentication process using the old key may be performed.

[0034] By using the aforementioned configuration, the timing of key changes can be clearly determined by the freshness value, preventing authentication failures caused by key mismatches between the new and old keys. Therefore, the timing of actual authentication failures can be immediately identified. Furthermore, when the timing is determined by the freshness value, the key used is changed according to the freshness value, so it is not affected by changes in the order of sending or receiving processes.

[0035] As shown in Figure 7, we will explain an example of how the processing order of reception changes, using the case where freshness values ​​of 1 to 4 are sent with the old key and values ​​of 5 and above are sent with the new key.

[0036] If the freshness value is not used and the messages are processed in the order they are received, after receiving 3, 6 is received, and authentication can be performed by retrying with the new key after the old key fails. If the order of receiving is not changed, subsequent receiving processes can be authenticated using the new key. However, as shown in the example in Figure 7, if the order of receiving is changed, it is possible to receive data using the new key when the freshness value is 5, and then receive data using the old key when the freshness value is 4. If authentication fails with the new key, authentication can be performed by retrying with the old key. If the freshness value is not used, the freshness value does not need to be included in the message.

[0037] When using a freshness value, the transmitter sends security frames as a counter that sequentially increases the freshness value, and the receiver determines which key to use based on the freshness value included in the transmitted and received messages. In other words, a freshness value is set for changing from the old key to the new key, and the old and new keys are used depending on whether the freshness value is greater than or less than that value. In the key change timing notification 2, the freshness value for which the new key will be used is notified as the key change timing 3. In the example shown in Figure 7, 5 is notified. If the freshness value is less than 5, the receiver performs the authentication process with the old key, and if the freshness value is 5 or greater, it performs the authentication process with the new key.

[0038] Therefore, as shown in Figure 7, even if the receiving order changes within the range of freshness values ​​4 to 6 on the receiving side, the key for receiving security frames can be uniquely identified, eliminating the need for re-authentication. Furthermore, since the freshness value used for security communication is used, there is no need to change the message structure.

[0039] Here, the key change timing notification 2 and the key readiness notification 1 may be replaced with signals used in existing communications. For example, they can be replaced with synchronization signals. Specifically, the MAC value of the new key is added to the synchronization signal for the freshness value, which is sent periodically with a MAC value added to it. When the receiver fails to authenticate the synchronization signal with the old key but succeeds with the new key, it can determine that this is the key change timing notification 2. At this time, it may send a signal with the MAC value calculated using the old key in parallel, or it may send only a signal with the MAC value calculated using the new key.

[0040] The second method involves switching the key used to determine whether MAC authentication is successful or not.

[0041] An example of the transmitter processing flowchart in the second method is the same as in Figure 1, where step S102 is always YES, and step S104 waits for a predetermined time before sending the key change timing notification 2.

[0042] Figures 4A and 4B are flowcharts illustrating an example of receiver processing in the second method.

[0043] Here, the predetermined period 1 (1b in Figure 6) should be sufficient time for the receiver to complete preparation for using the new key. For example, the predetermined period 1 may be arbitrarily set by the designer or user based on the design of the communication system, calculated by communication equipment such as transmitters and receivers based on the bus load, or set based on conditions related to the processing of the communication equipment, such as the number of transmissions.

[0044] After receiving the key change command, the receiver starts a predetermined period 2 (2b in Figure 6) when the key is ready and determines whether it has previously successfully authenticated with the new key (S401). If it has previously successfully authenticated with the new key, it authenticates with the new key (S409) and determines whether the authentication was successful (S410). If authentication with the new key is successful, it executes the authentication success processing (S414). If authentication with the new key fails, it authenticates with the old key (S411) and determines whether the authentication was successful (S412). If authentication with the old key is successful, it executes the authentication success processing (S414). If authentication with the old key fails, it executes the authentication failure processing (S415).

[0045] If there is no prior successful authentication with the new key, authentication is performed using the old key (S402), and it is determined whether authentication was successful (S403). If authentication with the old key is successful, the authentication success processing is executed (S408). If authentication with the old key fails, authentication is performed using the new key (S404), and it is determined whether authentication was successful (S405). If authentication with the new key is successful, the timing of this success is set as the completion timing of the predetermined period 2 (2b in Figure 6), and the authentication success processing is executed (S408). If authentication with the new key fails, the authentication failure processing is executed (S407).

[0046] The receiver may use the freshness value to determine the timing and process it as in the first method, or it may switch depending on whether the timing is after the successful authentication timing with the new key. When using the freshness value as the timing, if authentication with the old key fails for a freshness value at a timing later than the switching timing, it is advisable to perform authentication with the new key. If authentication with the new key is successful for multiple receptions, the one with the smallest freshness value is adopted, and the key change timing is changed to that smallest freshness value. The maximum freshness value at which authentication with the old key was successful is recorded, and for receptions below that maximum value, it is not necessary to attempt authentication with the new key. Alternatively, authentication may be attempted with the new key first, and then with the old key.

[0047] If authentication with the new key is successful within the predetermined period 2 (2b in Figure 6), the predetermined period 2 (2b in Figure 6) may be extended. This helps to suppress authentication failures caused by a reversal of the order of transmission and reception processes. For example, even after successful authentication with the new key, reception with the old key may be allowed for a while (S411). The duration may be extended in terms of time, or the condition may be set based on the number of receptions, such as "until n receptions." Also, if authentication with the new key is successful, the predetermined period 2 may be shortened. This improves security because it reduces the period during which reception with the old key is possible after reception with the new key.

[0048] After successful authentication with the new key, unless the order of transmission and reception is reversed, communication frames authenticated with the new key will be received. Therefore, attempting authentication with the new key before attempting authentication with the old key (S409, S410, S411, S412) can reduce the number of security calculations. Alternatively, attempting authentication with the old key first (S402, S403, S404, S405) until successful authentication with the new key can also reduce the number of security calculations. However, from the perspective of establishing communication, the order in which keys are attempted for authentication does not matter.

[0049] After the predetermined period 2 (2b in Figure 6) has ended, instead of following the flowchart in Figure 4, the normal receiving process using the new key may be performed. In other words, the system may transition to a state where communication using the old key is not permitted.

[0050] If authentication with the new key is not performed within the specified period in step S401, any error handling may be performed.

[0051] The second method does not require the addition of new signals for processing control, compared to the first method. Therefore, the second method can be applied to existing communication devices without adding any new message types.

[0052] In the second method, compared to the first method, authentication with the new key is also performed if authentication with the old key fails, thus increasing the computational load. However, the re-authentication process with the new and old keys only occurs at the actual switching timing, and multiple re-authentication with the new key is only required when the order of reception changes, thus mitigating the increase in load.

[0053] The above-described embodiments are now applied to an example of a communication device to which the present invention can be applied. The communication device to which the present invention can be applied is not limited to the configuration exemplified below, and various modifications are possible, such as changing the application target or replacing components with those having similar functions.

[0054] The communication device can be a general-purpose computer or electronic circuit, such as an ECU. Alternatively, it can be virtually implemented using software. Transmission and reception can also be software-to-software data transmission, such as inter-process communication or data transmission between modules.

[0055] For the purpose of explaining this embodiment, the communication device is configured as a transmitter and a receiver. The transmitter may also function as a receiver, or the receiver may also function as a transmitter. Multiple transmitters or receivers may be connected via a network.

[0056] The transmitter and receiver are connected to enable the transmission and reception of signals and data. The communication method can be either wired or wireless, and any communication method is acceptable. Various CAN communication methods are primarily used in automotive equipment and ECUs.

[0057] Figure 10 shows the configuration of a transmitter and receiver according to an embodiment of the present invention.

[0058] In this embodiment, key-based encrypted communication takes place between ECUs 10 and 20. Key-based encrypted communication also occurs between ECUs 10 and 20 and the gateway 50. Furthermore, key-based encrypted communication also occurs between ECU 10 and the management center 100, and between the gateway 50 and the management center 100. In these cases, at certain times, one device (e.g., ECU 10) acts as the transmitter, and the other device (e.g., ECU 20) acts as the receiver. At other times, the roles of transmission and reception are reversed (for example, ECU 20 acts as the transmitter and ECU 10 as the receiver).

[0059] The ECU 10 has a microcontroller 12 inside. The microcontroller 12 has at least one processor (CPU) 13 that executes programs, RAM 14 that provides a volatile storage area, at least one communication unit 15 that controls communication with other devices, and non-volatile memory 16 that holds programs and data in a non-volatile storage area. Similarly, the ECU 20 has a microcontroller 22 inside. The microcontroller 22 has at least one processor (CPU) 23 that executes programs, RAM 24 that provides a volatile storage area, at least one communication unit 25 that controls communication with other devices, and non-volatile memory 26 that holds programs and data in a non-volatile storage area.

[0060] The gateway 50 is a device that controls communication between ECUs and has a control unit 51 that executes a program and a communication unit 52 that controls communication with other devices.

[0061] The control center 110 is a computer that provides data and programs to the ECU 10, and has an application unit 111 and a communication unit 112. The application unit 111 performs the processing of providing data and programs to the ECU 10. The communication unit 112 controls communication with the ECU 10 and the gateway 50.

[0062] In normal secure communication, the transmitter uses a shared key to calculate a hash value (primarily the MAC address) using the data to be transmitted and a freshness value as input. While the freshness value is not mandatory for the second method mentioned earlier, it is recommended to apply it to prevent retransmission attacks.

[0063] The transmitter combines the data, at least a portion of the freshness value, and at least a portion of the hash value, and transmits it as a frame.

[0064] The receiver receives the security communication frame and obtains the data, freshness value, and hash value.

[0065] If the transmitter transmits only a portion of the freshness value, the receiver calculates the entire freshness value based on the transmitter's freshness value recorded by the receiver. For example, if only the lower byte portion of the freshness value is transmitted, the upper byte portion is inferred and calculated from the transmitter's freshness value recorded by the receiver.

[0066] In this case, authentication fails if the freshness value is one that has been received before or if it is outside the range for which reception is permitted. The freshness value may be determined after the hash calculation result, which will be described later. Generally, hash calculation is computationally more demanding than freshness value determination, so it is more efficient to determine the freshness value first. If the freshness value cannot be determined without performing security calculations such as hash calculation or decryption, it is best to perform the security calculations first.

[0067] If only a portion of the hash value is being transmitted, the receiver calculates the hash value and extracts a portion of it in the same way as the transmitter for comparison.

[0068] If the received hash value matches the calculated hash value, the receiver accepts the frame, meaning authentication is successful. If it fails, the frame is not accepted, meaning authentication fails. In case of failure, the receiver may perform failure handling. For example, it may notify the receiver that it has failed.

[0069] When each communication device receives a key change command, it begins the process of switching the key used for secure communication. The key change command may be sent from a specific device on the network to a communication device, or from any communication device to any communication device on the network. The keys to be used may be prepared in advance and switched to the key used with the key change command, or the key to be used may be selected in the key change command and the series of processes, or key sharing may be used between communication devices. The key change command may also be sent by an external tool that is temporarily connected.

[0070] The case in which the first method of this embodiment is applied will be described.

[0071] The transmitter receives a command to change the key, and when the new key is ready after the switch, it enters a state of waiting for a key readiness notification 1 from the receiver. During this time, normal processing continues, and security communication continues using the old key before the change. If the configuration does not require authentication using the new key for sending and receiving notifications, it is sufficient for the new key to be ready by the key change timing notified by the key change timing notification 2.

[0072] The receiver receives a command to change the key and, when the new key after the change is ready, sends Key Ready Notification 1. The receiver may send Key Ready Notification 1 when the new key becomes available, or it may send it at a predetermined time after the transmitter becomes available, taking into account the timing difference in when the transmitter becomes available. Alternatively, Key Ready Notification 1 may be sent periodically to account for cases where the transmitter is not yet ready to use the new key at the time of sending Key Ready Notification 1. It is sufficient to send Key Ready Notification 1 before receiving Key Change Timing Notification 2 from the transmitter.

[0073] After the transmitter receives key readiness notification 1 from the receiver, it sends key change timing notification 2.

[0074] In this embodiment, the freshness value is used to determine the timing of the key change. The key change timing notification 2 includes information about the freshness value that will be used as the key change timing 3. The key change timing 3 to be notified may be the timing immediately after the notification is sent, but because the order of the sending and receiving processes may be reversed, there is a risk that the receiver may receive a security communication frame using the new key before processing the key change timing notification 2. Therefore, it is preferable to set the timing to be in the future from the timing of the notification's transmission.

[0075] When the receiver obtains the freshness value of the switching timing included in the key change timing notification 2, if the freshness value is less than the switching timing value during subsequent reception processing, the authentication process will be performed using the old key, and if it is after the switching timing value, the authentication process will be performed using the new key (S303~S305).

[0076] Here, each notification may be accompanied by the result of a hash value calculated using the new key. For example, a hash value calculated using the freshness value, a specific data sequence, or the payload of the notification to be sent may be added to the notification. The transmitter and receiver may also calculate the hash value using information and keys that they know to each other. In this way, processing can be continued only when the same new key is used, and for example, if the new key values ​​of the transmitter and receiver differ due to an error, the initiation of communication using different new keys can be suppressed. If authentication fails in each notification, error handling may be performed. For example, a notification indicating a key mismatch may be sent, or the error may be logged.

[0077] Key Ready Notification 1 may be sent using the old key or in a state that does not require authentication. In a configuration where Key Ready Notification 1 is sent using the old key or in a state that does not require authentication, it is possible to detect on the network that a key change process has started on a transmitter that has not yet prepared the new key.

[0078] Figure 5 is a timing chart of an example of operation in this embodiment, showing an example of operation when switching sequentially to key 0, key 1, and key 2.

[0079] When changing from key 0 to key 1, key 0 becomes the old key and key 1 becomes the new key. An example of operation is shown where the receiver's key preparation is completed after the transmitter's key preparation is complete. When changing from key 1 to key 2, key 1 becomes the old key and key 2 becomes the new key. An example of operation is also shown where the transmitter's key preparation is completed after the receiver's key preparation is complete.

[0080] When key 0 is in use, if a key change command is issued to change the key from 0 to 1 (t15), the transmitter prepares the key first (t16). The transmitter waits for key preparation completion notification 1, which is sent after the receiver has finished preparing the key (t21) (t22). After receiving key preparation completion notification 1 (t22), the transmitter sends key change timing notification 2 (t24). Key change timing notification 2 includes information about key change timing 3. When key change timing 3 is reached (t29), the transmitter and receiver change the key to be used for transmission from 0 to 1. The receiver authenticates security communication frames received after key change timing 3 (t29) with key 1, and authenticates security communication frames received before key change timing 3 (up to t28) with key 0. When the freshness value is used for timing determination, time t is the freshness value, and even if the order of processing changes on the receiver side, the key to be used is managed by the freshness value.

[0081] Next, when a key change command is issued to change from key 1 to key 2 (t33), the receiver is ready to use the key first (t34). The receiver sends key ready notification 1 (t35). The transmitter ignores key ready notification 1 while the key is not ready (t34 to t38) (t35, t37). After the transmitter is ready to use the key (t38), when it receives key ready notification 1 (t39), it sends key change timing notification 2 (t40). Key change timing notification 2 includes information for key change timing 3. The receiver may stop sending key ready notification 1 after receiving key change timing notification 2. The transmitter and receiver switch the key to be used at key change timing 3, similar to when changing from key 0 to key 1.

[0082] Figure 6 is a timing chart of an example of operation when a second method is adopted, which determines the predetermined period without using freshness values.

[0083] The main difference in processing from Figure 5 is that the transmitter transmits security communication frames using key 0 for a predetermined time 1a (from t16 to t24) after the preparation of new key 1 is complete (t16). The receiver performs authentication processing with key 0 from after the key preparation is complete (t19) until authentication with key 0 fails and authentication with key 1 is successful (t24). In addition, even after successful authentication with key 1 (t24), the receiver also performs authentication with key 0 for a predetermined time (see Figure 4).

[0084] Similarly, when switching from key 1 to key 2, where the receiver's key preparation is completed first, the receiver continues the authentication process with key 1 after key preparation is complete (t34), until authentication with key 1 fails and authentication with key 2 is successful (t46). After successful authentication with key 2 (t46), it also performs authentication with key 1 for a predetermined time (t47).

[0085] When communication devices communicate with each other, it is preferable to have each communication device possess the functions and processing of the transmitter and receiver described above. For example, when communication device 1 and communication device 2 communicate, communication device 1 has the functions of a receiver and a transmitter for communication device 2, and communication device 2 has the functions of a receiver and a transmitter for communication device 1. The processing of security communication from communication device 1 to communication device 2 and security communication from communication device 2 to communication device 1 is performed independently. For example, when the common key for security communication from communication device 1 to communication device 2 is changed, it is not necessary to change the common key for security communication from communication device 2 to communication device 1. In other words, it is possible to consider the processing of security communication to be independent for each communication path. In such cases, the processing of the present invention can be applied to each communication path. It is preferable that the processing of the present invention be performed independently for each communication path. Communication control information such as freshness value, key, and key change timing 3 is managed for each communication path. When the key is changed simultaneously in multiple communication paths, the new key and the old key may be shared in each communication path. Also, the same common key may be used in the transmission path and the reception path.

[0086] Furthermore, multiple receivers may be provided. In this case, in step S102 of Figure 1, the result is determined to be YES when key readiness notification 1 is received from all receivers.

[0087] Furthermore, multiple transmitters may be provided. In this case, it is preferable to perform the reception process independently for each transmitter. Communication control information such as freshness value, key, and key change timing 3 is managed for each transmitter. If the key is changed simultaneously on multiple communication paths, the new key and old key may be shared across each communication path. In this case, the predetermined period 2 of the receiver may lock or delete the old key after an arbitrary period has elapsed (for example, after it is no longer possible to receive with the old key) for all transmitters, after the key change timing notification 2 has been received and the key change timing 3 has elapsed, or after authentication with the new key has been successful. Also, if the key is changed simultaneously on all transmitters, and the key change timing notification 2 is not received from at least some transmitters, it may be treated as an error and error handling may be performed.

[0088] When using a freshness value, a count value that increases with each transmission may be used instead of the freshness value, and this count value may be a value that repeats within a predetermined range. The receiver only needs to know the sequence of transmissions during the period from when it receives the key change timing notification 2 until the key change timing 3. For example, if a value from 0 to 100 is adopted, a value corresponding to a count of minus 30 from the current value may be considered a past value. Here, if the current value is 20, subtracting 30 gives -10, and adjusting it within the range of 0 to 100 gives 90. In this case, values ​​from 20 to 89 can be treated as future values, and values ​​from 90 to 100 and from 0 to 19 can be treated as past values. Assuming that there are no swaps of 30 or more reception processes, a count value that could be received out of order, such as 91, can be determined to be a past value. If the count value is 20, by setting the key change timing to a future value such as 89, the receiver only needs to switch the key to be used at the timing when it first passes the count value of 89 after receiving the key change timing notification 2.

[0089] If an authentication failure occurs during the authentication process due to a freshness value (e.g., S310 in Figure 3), the handling of the authentication result in the key change process may be changed depending on the cause of the failure.

[0090] A communication device on the network may request a key change from a key management communication device that manages the keys, and the key management communication device, upon receiving the request, may begin the key change process. With this configuration, any communication device on the network can request a key change, and by having a specific communication device manage the timing of key changes and the key value, it is possible to prevent differences in the keys used that could occur when multiple key change requests overlap. In addition, since each communication device can detect security risks and request a key change, the load of detecting security risks can be distributed.

[0091] This invention can be used not only for communication to prevent impersonation, but also for changing keys used in encrypted communication. When applying the first method, the timing of key changes can be identified by assigning a sequence number that indicates the transmission order of encrypted communication. The sequence number may be sent in plaintext only, or it may be included in the ciphertext if it is possible to determine whether decryption is successful. In addition, the key preparation completion notification 1 and the key change timing notification 2 may be encrypted using the old key. During the key change process, at least the sequence number may be encrypted using the old key. This makes it possible to uniquely identify the sequence number even in a situation where new and old keys are mixed. If it is possible to determine whether decryption is successful or not, the new key may be used. The key preparation completion notification 1 may be encrypted with the old key, and the key change timing notification 2 may be encrypted with the new key. Instead of encryption, a hash value using the encryption / decryption key may be assigned.

[0092] The technique of changing the key of a security communication, as described above, can also be applied to applications that change the key regardless of timing. For example, if interference is detected in a security communication while a vehicle is in motion, the key can be changed immediately, improving resilience to security risks. In other words, it is advisable to change the key when the hash value of the communication is correct and the value representing the data transmission timing (e.g., freshness value) is the same.

[0093] For example, if data with the same freshness value but different communication content has the correct hash value, it's possible that security communication signals were received from both an intended and an unintended communication partner, and that the security communication key may have been leaked. In this case, if the key is changed to a different, pre-prepared new key, the unintended communication partner who does not know the new key will not be able to continue the communication, thus ensuring the security of subsequent communications.

[0094] One way to determine if a key has been leaked is to record at least a portion of the received freshness value and hash value as part of the reception history. If a received message has a correct hash value, the same freshness value exists in the reception history, and the hash value is different, then it can be determined that the key has been leaked. If the hash values ​​are the same, it may be determined that a retransmission attack has occurred. Since it is unlikely that the same hash value will be calculated for different messages, if the hash values ​​are different, it can be determined that communication was carried out using the leaked key. In addition, recording at least a portion of the hash value saves memory compared to recording and comparing all received messages. When recording a portion of the hash value, it is best to extract a portion of the received hash value in a similar manner.

[0095] Hereafter, the timing of key changes in the embodiment of the present invention will be explained using a different diagram.

[0096] Figure 8 shows the timing of the key change in this embodiment.

[0097] As shown in Figure 8, when a key is changed and a key change timing notification is sent, the transmitter continues to transmit using the old key for a predetermined period 1 after the key change. The receiver authenticates received messages using the old key for a predetermined period 2. The new key may be received each time it is changed, or it may be received in advance. In this way, even during periods when the keys do not match between the transmitter and receiver on the network, a mixture of old and new keys is allowed, and secure communication can continue.

[0098] Figure 9 shows the timing of the key change in this embodiment.

[0099] As shown in Figure 9, when a key is changed and a key change timing notification is sent, the transmitter continues to transmit using the old key for a predetermined period 1 until the receiver can use the new key. The transmitter notifies the receiver of the key change timing before the change occurs. Even after the new key becomes available, the receiver allows authentication using the old key for a predetermined period 2, taking into account the difference in key change timing. That is, if authentication with one key fails, the receiver attempts authentication with the other key.

[0100] As described above, in the communication system of the embodiment of the present invention, when the new key becomes available, the transmitter sends a notification regarding the key change timing, transmits data using the old key during a first predetermined period after the new key becomes available, and the receiver performs authentication processing using the old key during a second predetermined period after the new key becomes available. When the receiver receives the notification regarding the key change timing from the transmitter, data transmitted before the key change timing is authenticated using the old key, and data transmitted after the key change timing is authenticated using the new key, thereby reducing the failure of security communication due to key changes. Furthermore, since security communication can continue as usual even during key changes, the key can be changed at any time. By determining whether the key is correct based on the success or failure of decryption, it can be applied to various types of security communication.

[0101] Furthermore, if authentication using the old key fails during the second predetermined period, the receiver can switch to the correct key without receiving a notification by performing authentication with the new key.

[0102] Furthermore, the receiver sends a key readiness notification to the transmitter when authentication becomes possible with the new key, and the first predetermined period is set to the period until the key readiness notification is received, thereby ensuring that the correct key is reliably switched to using the notification.

[0103] Furthermore, the receiver sends a key readiness notification when authentication becomes possible with the new key, and the first predetermined period is the period from receiving the key readiness notification until a further predetermined period has elapsed or predetermined conditions have been met, thereby ensuring that the receiver can reliably switch to the correct key, taking into account the preparation period for the key change.

[0104] Furthermore, the transmitter can ensure that the key change timing is synchronized between the transmitter and the receiver by notifying the receiver of the timing when the first predetermined period ends through a key change timing notification.

[0105] Furthermore, by making the second predetermined period the period until the key change timing included in the key change timing notification, the key change timing can be reliably synchronized between the transmitter and the receiver.

[0106] Furthermore, since the first and second predetermined periods are determined by the freshness value used for secure communication, secure communication can continue even if the order of data arrival changes. Also, since an existing freshness value is used, there is no need to set up a separate counter for key management.

[0107] It should be noted that the present invention is not limited to the embodiments described above, but includes various modifications and equivalent configurations within the spirit of the attached claims. For example, the embodiments described above are described in detail for the purpose of clearly illustrating the present invention, and the present invention is not necessarily limited to having all the described configurations. Furthermore, some of the configurations of one embodiment may be replaced with those of another embodiment. Furthermore, configurations of other embodiments may be added to the configuration of one embodiment. Furthermore, some of the configurations of each embodiment may be added, deleted, or replaced with those of other embodiments.

[0108] Furthermore, each of the aforementioned configurations, functions, processing units, and processing means may be implemented in hardware, for example, by designing them as integrated circuits, or they may be implemented in software by having a processor interpret and execute programs that realize each function.

[0109] Information such as programs, tables, and files that implement each function can be stored in memory, hard disks, SSDs (Solid State Drives), or other storage media such as IC cards, SD cards, and DVDs.

[0110] Furthermore, the control lines and information lines shown are those deemed necessary for explanation purposes and do not necessarily represent all control lines and information lines required for implementation. In reality, it can be assumed that almost all components are interconnected.

Claims

1. A communication system that uses a key to perform secure communication between a transmitter and a receiver, The key can be changed during the security communication, The aforementioned transmitter is Once the new key becomes available, a notification regarding the key change will be sent. During a first predetermined period after the new key becomes available, data is transmitted using the old key before the change. The aforementioned receiver is During the period between when the new key becomes available and the key change timing, the authentication process upon receipt is performed using the old key. When the transmitter receives notification regarding the key change timing, data transmitted before the key change timing will be authenticated using the old key, and data transmitted after the key change timing will be authenticated using the new key. A communication system characterized in that, if there is no experience of receiving data with the new key after receiving the new key from the key management device, or if authentication using the old key failed before the key change timing, authentication processing is performed with the new key.

2. A communication system according to claim 1, A communication system characterized in that the first predetermined period is the period until the receiver becomes capable of authentication with the new key.

3. A communication system according to claim 1, The receiver sends a key preparation completion notification to the transmitter when authentication becomes possible with the new key. A communication system characterized in that the first predetermined period is the period until the notification of completion of key preparation is received.

4. A communication system according to claim 1, The receiver sends a key preparation completion notification when authentication becomes possible with the new key. The communication system is characterized in that the first predetermined period is the period from the time the key preparation completion notification is received until a further predetermined period has elapsed or predetermined conditions have been met.

5. A communication system according to claim 1, The communication system is characterized in that the transmitter notifies the receiver of the timing of the end of the first predetermined period by key change timing notification.

6. A communication system according to claim 1, A communication system characterized in that the first predetermined period is determined by a freshness value used for the security communication.

7. A receiver that uses a key to perform secure communication with a transmitter, If the key is changed during the security communication, the authentication process upon reception will be performed using the old key before the change during the period between when the new key becomes available and when the key change occurs. When the transmitter receives a notification regarding the key change timing, data transmitted before the key change timing will be authenticated using the old key, and data transmitted after the key change timing will be authenticated using the new key. A receiver characterized in that, if there is no experience of receiving data with the new key after receiving the new key from the key management device, or if authentication using the old key failed before the key change timing, the receiver performs authentication processing with the new key.

Images