JP7842853B2 - Communication systems, transmitters, and receivers - Google Patents

Description

This invention relates to a communication system for performing secure communication.

One of the security features of computer communications is a mechanism to prevent impersonation. For example, a hash value is calculated using a common key between the communicating devices, and the receiver's calculation result is compared with the received hash value to determine if the received hash value matches the calculated hash value.

According to the AUTOSAR specification, which is used in automotive in-vehicle software, impersonation can be prevented by adding a MAC (Message Authentication Code) calculated using a common key to the CAN message frame. Additionally, a freshness value can be added to prevent retransmission attacks.

In secure communication using a shared key, if the key change is not timely across all communication devices, authentication failure will occur, resulting in a communication failure. Furthermore, a notification of authentication failure may be generated, potentially increasing the communication load.

The following are some of the underlying technologies related to key changes. Firstly, there is a method of sequentially performing key changes on each communication device. Secondly, when changing keys, the system switches to a key change mode, completes the key change for all communication devices on the network, and then returns to normal mode.

In the first case, the difference in the timing of the key change completion results in a period during which devices on the network have different keys, making secure communication impossible and causing a security communication failure.

In the second case, since the key change mode restricts at least the security communication functions available in normal mode, the key change process is limited to specific circumstances.

The following background technologies exist for techniques that change keys during communication. Patent Document 1 (Japanese Patent Application 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.

Japanese Patent Publication No. 2012-227672

In the aforementioned background technology, when changing the key used at an arbitrary time, as envisioned by this 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.

The present invention aims to mitigate security communication failures associated with key changes.

A typical 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 before the change 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, the receiver authenticates data transmitted before the key change timing using the old key when it receives a notification regarding the key change timing from the transmitter, authenticates data transmitted after the key change timing using the new key, and performs authentication processing using the new key if there is no experience of receiving data with the new key after receiving the new key from a key management device , or if authentication using the old key fails before the key change timing.

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.

This is a flowchart illustrating an example of the processing of a transmitter according to an embodiment of the present invention. This is a flowchart illustrating an example of receiver processing in an embodiment of the present invention. This is a flowchart illustrating an example of receiver processing in the first method. This is a flowchart illustrating an example of receiver processing in the first method. This is a flowchart illustrating an example of receiver processing in the second method. This is a flowchart illustrating an example of receiver processing in the second method. This is a timing chart of an example of operation in this embodiment. This is a timing chart for an example of the operation of the second method. This is an explanatory diagram showing what happens when the order of receiving and processing data is changed. This figure shows the timing of the key change in this embodiment. This figure shows the timing of the key change in this embodiment. This diagram shows the configuration of a transmitter and receiver according to an embodiment of the present invention.

In an embodiment of the present invention, when a command to change the key is given, after the key has been received, the transmitter continues to transmit using the old key for a predetermined period 1, and the receiver authenticates the received message using the old key for a predetermined period 2.

Here, the timing of key acquisition completion may be defined as the point at which the system can switch to the key being used. Alternatively, if the next shared key to be used is predetermined, the timing of key acquisition completion may be defined as the time when a command to use the next shared key is received. Furthermore, the timing of key acquisition completion may be predetermined by date and time.

The old key may be deleted or locked after the end of a predetermined period 1 or period 2 for both the transmitter and receiver. Since the old key is used when the key mismatch period and the transmission/reception processing order are reversed, it may be deleted or locked if frames authenticated with the old key can no longer be received due to the reversal. In the case of the transmitter, since transmission processing using the old key is no longer performed after the switch to the new key, it may be deleted immediately. The timing of deletion may vary and may be other than those exemplified.

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

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

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 switching is completed. Figures 1 and 2 may start when the 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.

In the first method, one example of a period is the freshness value, but any value that allows timing between communication devices is acceptable, such as time or number of communications.

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 becomes usable (S101), and determines whether it has received the key preparation completion 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 preparation completion 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 processing or sending an error notification. Alternatively, processing may continue without a timeout. On the other hand, if the key preparation completion 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 freshness value that is assigned sequentially. The key change timing notification 2 includes a freshness value for when the key is changed. This value represents a predetermined period 1 (time 1a in Figure 6), which is preferably a future timing. However, it is best to set it so that the receiver has sufficient time to 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 parties, or it can be set dynamically based on these factors.

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.

As shown in Figure 2, the receiver waits until the new key becomes available (S201), and when the key reception is complete, it sends a key readiness 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 the key readiness notification 1 until it receives a key change timing notification 2. It may also send the 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 in which the key readiness 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 notification of an error.

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, a timeout may be set to continue the subsequent processing. In this case, the transmitter may ignore the receivers that did not receive the key readiness notification 1 and continue the transmission/reception process using the new key, or it may restrict communication across the entire network. A predetermined process to be executed in such a case may be performed in step S108. If a timeout occurs, any processing that occurs at the timeout may be performed. For example, an error notification or cancellation of the key change process may be performed.

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). Alternatively, the freshness value may be estimated from the previously received freshness value instead of being extracted each time. The receiver then determines whether the key change timing notification 2 has been received (S302). If the key change timing notification 2 has been received, it determines 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 receiver uses the new key (S304), and if the received freshness value is before the key change timing, the receiver uses the old key (S305). This period is the predetermined period 2 (2a in Figure 6). Similarly, when defining the timing by time or number of communications, it is advisable to use different keys depending on whether it is before or after the key change timing.

Subsequently, the receiver 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 a previously 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.

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 (a 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).

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.

In step S313, 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 based on that smallest freshness value. The maximum freshness value for which authentication with the old key was successful is recorded, and for receptions 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 communication using the old key is no longer received, reception using the old key may be stopped, and normal security communication processing using the new key may be performed.

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 decision of which key to use first may be made based on the freshness value. For example, if the value is close to the maximum value of the old key, the old key may be used first; if it is close to the minimum value of the new key, the new key may be used first.

Furthermore, the processing in steps S311, S312, and S313, which occur when the key change timing notification 2 is not received in S302, is an optional process that serves as a countermeasure when the reception of the key change timing notification 2 fails. In S302, if the key change timing notification 2 is not received, an authentication error (for example, S315) may be generated without attempting authentication with the new key.

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

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 timing is determined by the freshness value, the key used is changed according to the freshness value, thus unaffected by changes in the order of transmission and reception processing.

As shown in Figure 7, we will explain an example of how to handle a change in the order of receiving data, using the case where freshness values 1 to 4 are sent with the old key and values 5 and above are sent with the new key.

If processing is done in the order of reception without using freshness values, after receiving 3, then receiving 6, authentication can be achieved by retrying with the new key after the old key fails. If the order of reception processing does not change, subsequent reception processing can be authenticated using the new key. However, as shown in the example in Figure 7, if the order of reception processing changes, 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 achieved by retrying with the old key. If freshness values are not used, the freshness value does not need to be included in the message.

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.

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 employed, no changes to the message structure are required.

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 of 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.

As a second method, we will explain how to switch the key used to determine the success or failure of MAC authentication.

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.

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

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 the transmitter and receiver based on the bus load, or set based on conditions based on the processing of the communication equipment, such as the number of transmissions.

The receiver, after receiving the key change command, 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).

If there is no prior successful authentication with the new key, authentication is performed using the old key (S402), and it is determined whether the 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 the 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).

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 based on 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.

If authentication with the new key is successful during the predetermined period 2 (Figure 6, 2b), the predetermined period 2 (Figure 6, 2b) 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 permitted 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.

After successful authentication with the new key, unless the order of transmission and reception is reversed, the system will receive communication frames authenticated with the new key. 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.

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.

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

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

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, since 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, the increase in load can be suppressed.

The above-described embodiments are now being applied to examples of communication devices. The communication devices to which the present invention can be applied are not limited to the configurations exemplified below; various modifications are possible, such as changing the application target or replacing components with those having similar functions.

The communication device can be a general-purpose computer or electronic circuit, such as an ECU. It can also be virtually implemented using software. Transmission and reception can include data transmission between software programs, such as inter-process communication or data transmission between modules.

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.

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. In automotive equipment and ECUs, various CAN communications are primarily used.

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

In this embodiment, encrypted communication using keys takes place between ECUs 10 and 20. Encrypted communication using keys also occurs between ECUs 10 and 20 and the gateway 50. Furthermore, encrypted communication using keys 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 acts as the receiver).

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.

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.

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 executes the process of providing data and programs to the ECU 10. The communication unit 112 controls communication with the ECU 10 and the gateway 50.

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.

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.

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

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.

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, as 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.

If only a portion of the hash value is being transmitted, the receiver calculates the hash value, extracts a portion of it in the same way as the transmitter, and compares it.

If the received hash value matches the calculated hash value, the receiver accepts the frame, i.e., authentication is successful. If it fails, it does not accept the frame, i.e., authentication fails. In the event of failure, the receiver may perform failure handling. For example, it may notify the receiver that it has failed.

Upon receiving a key change command, each communication device 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 upon receiving the key change command, or the key to be used may be selected during the key change command and the subsequent processing, or key sharing between communication devices may be used. Furthermore, the key change command may be sent by an external tool that is temporarily connected.

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

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.

The receiver receives a command to change the key and, when the new key after the change is ready, sends a key readiness notification 1. The receiver may send the key readiness notification 1 when the new key becomes usable, or it may send it at a predetermined time after the transmitter becomes usable, taking into account the timing difference in when the transmitter becomes usable with the new key. Alternatively, the receiver may send the key readiness notification 1 periodically to account for cases where the transmitter is not yet ready to use the new key at the time of sending the key readiness notification 1. It is sufficient to send the key readiness notification 1 before receiving the key change timing notification 2 from the transmitter.

After receiving the key preparation completion notification 1 from the receiver, the transmitter sends the key change timing notification 2.

In this embodiment, the freshness value is used to determine the timing of the key change. The key change timing notification 2 includes information on 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 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 due to a change in the order of transmission and reception processing, it is desirable to set the timing to be in the future from the timing of the notification transmission.

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 receiver performs authentication processing using the old key; if it is after the switching timing value, it performs authentication processing using the new key (S303-S305).

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.

Key Readiness Notification 1 may be sent using the old key or in a state that does not require authentication. In a configuration where Key Readiness 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 the key change process has started on a transmitter that has not yet prepared the new key.

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.

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 transmitter's key preparation is complete before the receiver's key preparation. 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 receiver's key preparation is complete before the transmitter's key preparation.

When key 0 is in use, and a key change command is issued to change the key from 0 to 1 (t15), the transmitter has already prepared the key (t16). The transmitter waits for a key preparation completion notification 1 to be sent after the receiver has finished preparing the key (t21) (t22). After receiving the key preparation completion notification 1 (t22), the transmitter sends a key change timing notification 2 (t24). The 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 is changed on the receiver side, the key to be used is managed by the freshness value.

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 a key ready notification 1 (t35). The transmitter ignores the 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 the key ready notification 1 (t39), it sends a key change timing notification 2 (t40). The key change timing notification 2 includes information about the key change timing 3. The receiver may stop sending the key ready notification 1 after receiving the 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.

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.

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).

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 succeeds (t46). After successful authentication with key 2 (t46), it also performs authentication with key 1 until a predetermined time (t47).

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.

Furthermore, multiple receivers may be provided. In this case, in step S102 of Figure 1, the determination is YES when key readiness completion notifications 1 are received from all receivers.

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 be, for all transmitters, after the key change timing notification 2 has been received and the key change timing 3 has elapsed, or after successful authentication with the new key, and after an arbitrary period has elapsed (for example, after the timing at which reception with the old key is no longer possible), the old key may be locked or deleted. 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.

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 more than 30 changes in the order of reception processing, 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 89 after receiving the key change timing notification 2.

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

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. This configuration allows any communication device on the network to request a key change, and by having a single specific communication device manage the key change timing and key values, it prevents discrepancies in the keys used that could occur when multiple key change requests overlap. Furthermore, since each communication device can detect security risks and request key changes, the load of detecting security risks can be distributed.

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 the success of decryption. 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 the success or failure of decryption, 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.

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.

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, potentially resulting in the leakage of a security communication key. In this case, changing to a pre-prepared new key would prevent the unintended communication partner, who doesn't know the new key, from continuing the communication, thus ensuring the security of subsequent communications.

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. Here, if the hash values are the same, it can 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.

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

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

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 a key change occurs, 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 permitted, and secure communication can continue.

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

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 with 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.

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, thus 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.

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

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 defined as the period until the key readiness notification is received, thereby ensuring that the correct key is reliably switched to using the notification.

Furthermore, the receiver sends a key readiness notification when authentication becomes possible with the new key. The first predetermined period is defined as the period from receiving the key readiness notification until a further predetermined period has elapsed or predetermined conditions have been met, thereby ensuring a reliable switch to the correct key, taking into account the receiver's preparation period for the key change.

Furthermore, the transmitter can ensure that the key change timing is reliably 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.

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.

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, because an existing freshness value is used, there is no need to set up a separate counter for key management.

Furthermore, 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 to make the present invention easier to understand, and the present invention is not necessarily limited to having all the described configurations. Also, some of the configurations of one embodiment may be replaced with those of another embodiment. Also, some of the configurations of another embodiment may be added to the configuration of one embodiment. Also, some of the configurations of each embodiment may be added, deleted, or replaced with other configurations.

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 the processor interpret and execute programs that realize each function.

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

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 (7)

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 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 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. 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. 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. 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 notification of key preparation completion is received until a further predetermined period has elapsed or predetermined conditions have been met. 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. 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. 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.