WO2023187896A1 - 通信システム、送信機、及び受信機 - Google Patents

通信システム、送信機、及び受信機 Download PDF

Info

Publication number
WO2023187896A1
WO2023187896A1 PCT/JP2022/014982 JP2022014982W WO2023187896A1 WO 2023187896 A1 WO2023187896 A1 WO 2023187896A1 JP 2022014982 W JP2022014982 W JP 2022014982W WO 2023187896 A1 WO2023187896 A1 WO 2023187896A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
authentication
communication system
receiver
predetermined period
Prior art date
Application number
PCT/JP2022/014982
Other languages
English (en)
French (fr)
Inventor
玲於奈 望月
Original Assignee
日立Astemo株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日立Astemo株式会社 filed Critical 日立Astemo株式会社
Priority to PCT/JP2022/014982 priority Critical patent/WO2023187896A1/ja
Publication of WO2023187896A1 publication Critical patent/WO2023187896A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation

Definitions

  • the present invention relates to a communication system that performs secure communication.
  • One type of computer security communication is a mechanism to prevent spoofing. For example, a hash value is calculated using a common key between communication devices, and compared with the calculation result of the receiver to determine whether the received hash value and the calculated hash value match.
  • spoofing can be prevented by adding a MAC (Message Authentication Code) calculated using a common key to CAN message frames. Additionally, a freshness value can be added to prevent retransmission attacks.
  • MAC Message Authentication Code
  • the first method is to change the key on each communication device one after another.
  • the second method is to change the key by switching to a key change mode etc., complete changing the keys of all communication devices on the network, and then switch back to normal mode. There is a way to come back.
  • Patent Document 1 Japanese Unexamined Patent Publication No. 2012-227672 discloses that in a vehicle/road-to-vehicle communication system composed of a key management server that manages a common key, a roadside device, and an on-vehicle device, the key management server manages an area. , a roadside device and a vehicle-mounted device existing in a certain area share the same common key, and the shared common key is used to guarantee message confidentiality, integrity, or both. Communication systems are described.
  • the present invention aims to reduce security communication failures due to key changes.
  • a typical example of the invention disclosed in this application is as follows. That is, the communication system performs secure communication using a key between a transmitter and a receiver, the key can be changed during the secure communication, and the transmitter uses a new key after the change. If possible, the receiver sends a notification regarding the key change timing and transmits data with the old key before the change in a first predetermined period after the new key becomes available; If the old key is used to perform authentication processing upon reception during a second predetermined period after the key becomes available for use, and a notification regarding the key change timing is received from the transmitter, the transmission is performed before the key change timing. The data transmitted after the key change timing is authenticated using the old key, and the data transmitted after the key change timing is authenticated using the new key.
  • FIG. 3 is a flowchart of an example of processing of a transmitter according to an embodiment of the present invention.
  • 3 is a flowchart of an example of processing of a receiver according to an embodiment of the present invention.
  • 3 is a flowchart of an example of receiver processing in a first method;
  • 3 is a flowchart of an example of receiver processing in a first method;
  • 7 is a flowchart of an example of receiver processing in a second method.
  • 7 is a flowchart of an example of receiver processing in a second method.
  • 3 is a timing chart of an operation example of the present embodiment.
  • 12 is a timing chart of an operation example of the second method.
  • FIG. 6 is an explanatory diagram when the reception processing order is changed.
  • FIG. 6 is a diagram showing the timing of key change in this embodiment.
  • FIG. 6 is a diagram showing the timing of key change in this embodiment.
  • 1 is a diagram showing the configuration of a transmitter and a receiver according to an embodiment of the present
  • the transmitter when a key change command is issued, after completion of key reception, the transmitter continues transmission using the old key for a predetermined period 1, and the receiver authenticates the received message using the old key. is performed for a predetermined period 2.
  • the timing of completion of key reception may be a state in which the key to be used can be switched. Furthermore, if the common key to be used next is determined in advance, the timing at which a command to use the next common key is received may be the timing at which the key reception is completed. Furthermore, the timing of completion of key reception may be specified in advance by date and time.
  • the old key may be deleted or locked after the end of the predetermined period 1 or the predetermined period 2 for both the transmitter and the receiver.
  • the old key is used when the key mismatch period and the transmission and reception processing order are swapped, so it may be deleted or locked if it becomes impossible to receive frames authenticated with the old key due to the swap.
  • transmission processing using the old key will not be performed, so it may be deleted immediately.
  • the deletion timing may be a timing other than the one illustrated, and the deletion timing may be various timings.
  • FIG. 1 is a flowchart of an example of processing by a transmitter
  • FIGS. 2, 3A, and 3B are flowcharts of an example of processing by a receiver.
  • FIG. 2 describes the process until the key change timing to be used is determined
  • FIGS. 3A and 3B describe the reception process from the start of the key change process until the key switch is completed. 1 and 2 may each be initiated upon receiving a key change command.
  • 3A and 3B may be a security communication reception process from when the receiver receives a key change command until transmission using the old key is no longer performed.
  • an example of the period is a freshness value, but any value that can measure timing between communication devices may be used, such as time or number of communications.
  • the transmitter receives a new key from the key management device at the key change timing, waits until the new key becomes usable (S101), and waits until a predetermined period of time elapses and times out (S101). S107), it is determined whether key preparation completion notification 1 has been received (S102). If a predetermined period of time elapses without receiving the key preparation completion notification 1 and the timeout occurs (YES in S107), the processing at the time of timeout is executed (S108). Any process may be performed upon timeout, such as canceling the key change process or notifying an error. Alternatively, the processing may be continued without providing a timeout.
  • the key change timing is determined (S103), and the key change timing notification 2 is transmitted (S104).
  • the key change timing is a future timing after the preparation time on the receiving side, and can be calculated, for example, by adding a predetermined value to the current time (current freshness value). Instead of the freshness value, a value that can measure time or communication sequence may be used. Considering the disorder in the order of data arrival, it is preferable to use freshness values that are assigned sequentially.
  • the key change timing notification 2 includes a freshness value when changing the key. The period up to this value is the predetermined period 1 (time 1a in FIG.
  • the value may be set based on the communication design, the value may be set based on the communication status such as the communication load, frequency, and number of parties, or the value may be set dynamically based on these.
  • the transmitter determines whether key change timing 3 has been reached (S105). If the key change timing has not been reached, a key change timing notification is repeatedly transmitted at a predetermined timing (S109), and determination as to whether the key change timing has been reached is continued. On the other hand, if the key change timing has been reached, the key used during transmission is switched (S106). For the periodic transmission in step S109, the transmission interval may be set so that the periodic transmission is transmitted a predetermined number of times before the key change arrival timing.
  • the receiver waits until the new key becomes available for use (S201), and when it has completed receiving the key, transmits key preparation completion notification 1 (S202). Then, it is determined whether key change timing notification 2 has been received (S203). If the key change timing notification 2 is not received, the process may return to step S202 and the key preparation completion notification 1 may be transmitted until the key change timing notification 2 is received. The key change timing notification 2 may be transmitted multiple times. On the other hand, when key change timing notification 2 is received, key change timing 3 is determined according to the received key change timing notification (S204). A predetermined period of waiting may be added before the transmission in step S202.
  • a timeout process may be executed. An example is cancellation of a key change process or notification of an error.
  • the transmitter should transmit the key change timing notification 2 after receiving the key preparation completion notification 1 from all the receivers. If the key preparation completion notification 1 cannot be received from at least some of the receivers, a timeout may be set and subsequent processing may be continued. In this case, the receiver that has not been able to receive the key preparation completion notification 1 may be ignored and the transmission/reception process using the new key may be continued, or communication throughout the network may be restricted. A predetermined process executed in such a case may be executed in step S108. When a timeout occurs, any timeout processing may be executed. For example, an error notification or a cancellation of key change processing may be performed.
  • the receiver extracts the reception freshness value from the reception data (S301).
  • the freshness value may be estimated from the previously received freshness value without extracting the freshness value each time.
  • the key change timing notification 2 it is determined whether the received freshness value is after the key change timing (S303).
  • reception is performed using the new key (S304), and at the timing of the reception freshness value before the key change timing, reception is performed using the old key (S305).
  • the period up to this timing becomes a predetermined period 2 (2a in FIG. 6).
  • the receiver determines whether the authentication was successful (S306).
  • the authentication may be performed by determining whether the transmitted data and the hash value of the freshness value match. Further, it is preferable to determine that authentication has failed when the received freshness value is received again. If the authentication is successful, the authentication success process is executed (S307), and if the authentication is unsuccessful, the authentication failure process is executed (S308). If the receiver has received the key change timing notification 2, it can be considered theoretically that the cause of the authentication failure is the wrong key used in the switching process between the new key and the old key.
  • processing in accordance with the original authentication result may be performed without performing the processing in the case of authentication failure or the processing in the case of success (S308, S307) in the key switching process, or steps S307 and S308 may be performed based on the original authentication result. It is also possible to perform processing according to the following.
  • step S302 it is determined whether the new key has been received and the reception freshness value is after the key change timing (predetermined period 2 (2b in FIG. 6)) (S316 ). If the new key has not been received or the received freshness value is not after the key change timing (NO in S316), it is unknown whether the new key or the old key is used, so authentication using both the old key and the new key is attempted. That is, authentication is performed using the old key (S309), and it is determined whether the authentication was successful (S310). If the authentication using the old key is successful, the authentication success process 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).
  • step S313 if the new keys are successfully authenticated for multiple receptions, the one with the smaller freshness value is adopted, and the key change timing is changed using the smaller freshness value.
  • the maximum value of the freshness value that resulted in successful authentication using the old key is recorded, and if the freshness value is less than the maximum value, it is not necessary to attempt authentication using the new key.
  • Failure to receive the key change timing notification 2 may be treated as an error, and in that case, there is no need to perform re-authentication processing using the new key after authentication failure using the old key.
  • reception using the old key may be stopped and normal security communication processing using the new key may be executed.
  • the old key or the new key For freshness values for which it is not clear whether the old key or the new key is used, that is, the value between the maximum freshness value received with the new key and the minimum freshness value received with the new key, first determine whether the new key or the old key is used. Whether or not to try a key may be determined depending on its freshness value. For example, if the value is close to the maximum value of the old key, the old key may be tried first, and if the value is close to the minimum value of the new key, the new key may be tried.
  • steps S311, S312, and S313 when the key change timing notification 2 is not received in S302 is an optional process that serves as a countermeasure in the case where the key change timing notification 2 fails to be received. If the timing notification 2 is not received, an authentication error may be determined (for example, S315) without attempting authentication using the new key.
  • the timing of changing the key to be used can be clearly determined by the freshness value, so authentication failures due to key mismatch between the new key and the old key will not occur. Therefore, the actual timing of the occurrence of authentication failure can be immediately grasped. Furthermore, when specifying the timing using the freshness value, the key used is changed depending on the freshness value, so it is not affected by changes in the transmission processing order or the reception processing order.
  • the freshness value is not used and processing is performed according to the order of reception processing, authentication can be performed by receiving 3, then 6, and retrying with the new key after failing with the old key. If there is no change in the order of reception processing, subsequent reception processing can be authenticated using a new key. However, when the reception processing order is switched as in the example shown in FIG. 7, data may be received using the new key at a freshness value of 5, and then data using the old key may be received at a freshness value of 4. If authentication fails with the new key, authentication can be performed by retrying with the old key. If a freshness value is not used, the freshness value does not need to be included in the message.
  • the transmitter transmits the security frame as a counter that sequentially increases the freshness value, and the receiver determines the key to be used based on the freshness value included in the transmitted/received message. That is, a freshness value for changing from an old key to a new key is set, and the old and new keys are used depending on whether the freshness value is greater or smaller than the freshness value.
  • key change timing notification 2 the freshness value using the new key is notified as key change timing 3. In the example shown in FIG. 7, 5 is notified.
  • the receiver performs authentication processing using the old key when the freshness value is less than 5, and performs authentication processing using the new key when the freshness value is 5 or more.
  • the key for receiving the security frame can be uniquely identified, and re-authentication is not necessary. Furthermore, since the freshness value used for security communication is used, there is no need to change the message structure.
  • the key change timing notification 2 and the key preparation completion notification 1 may be replaced with signals used for existing communication.
  • a synchronization signal can be used instead.
  • the MAC value of the new key is added to the freshness value synchronization signal, which is sent with a MAC value added periodically, and then sent.
  • the receiver fails to authenticate the synchronization signal with the old key and succeeds with the new key, the receiver can determine that this is the key change timing notification 2.
  • the MAC calculated using the old key may be sent in parallel, or only the MAC calculated using the new key may be sent.
  • step S104 The example of the flowchart of the process of the transmitter in the second method is the same as the case where the answer is always YES in step S102 of FIG. 1 and the key change timing notification 2 is transmitted after waiting for a predetermined time in step S104.
  • FIGS. 4A and 4B are flowcharts of an example of receiver processing in the second method.
  • the predetermined period 1 (1b in FIG. 6) be a sufficient time for the receiver to be ready to use the new key.
  • the predetermined period 1 may be arbitrarily set by a designer or user based on the design of the communication system, or may be calculated by a communication device such as a transmitter or receiver based on the bus load, etc. The conditions may be set based on the processing of the communication device, such as the number of times of transmission.
  • the receiver After receiving the key change command, the receiver starts a predetermined period 2 (2b in FIG. 6) when the key preparation is completed, and determines whether there is a successful authentication experience with the new key (S401). If there is a successful authentication experience using the new key, authentication is performed using the new key (S409), and it is determined whether the authentication was successful (S410). If the authentication with the new key is successful, processing upon successful authentication is executed (S414). If authentication with the new key fails, authentication is performed with the old key (S411), and it is determined whether the authentication was successful (S412). If the authentication using the old key is successful, the authentication success process is executed (S414). If the authentication using the old key fails, an authentication failure process is executed (S415).
  • authentication is performed with the old key (S402), and it is determined whether the authentication was successful (S403). If the authentication using the old key is successful, the authentication success process is executed (S408). If authentication using the old key fails, authentication is performed using the new key (S404), and it is determined whether the authentication was successful (S405). If the authentication with the new key is successful, the timing is set as the completion timing of the predetermined period 2 (2b in FIG. 6), and the authentication success process is executed (S408). If the authentication using the new key fails, an authentication failure process is executed (S407).
  • the receiver may use the freshness value to determine the timing and process as in the first method, or may switch depending on whether the timing is after the timing of successful authentication with the new key.
  • the freshness value as a timing
  • the new keys are successfully authenticated for multiple receptions, the one with the smaller freshness value is adopted, and the key change timing is changed using the smaller freshness value.
  • the maximum value of the freshness value that resulted in successful authentication using the old key is recorded, and if the freshness value is less than the maximum value, it is not necessary to attempt authentication using the new key.
  • authentication may be attempted using a new key, and then authentication may be attempted using an old key.
  • the predetermined period 2 (2b in FIG. 6) may be extended. By doing so, it is possible to suppress authentication failure due to the order of transmission processing and reception processing being switched. For example, even after successful authentication using the new key, reception using the old key is allowed for a while (S411). The continuing period may be extended in time, or a condition may be set based on the number of receptions, such as "until n times of reception". Further, if the authentication using the new key is successful, the predetermined period 2 may be shortened. Security is improved because the period during which reception can be performed using the old key after receiving the new key can be reduced.
  • step S401 If authentication using the new key is not performed within a predetermined period in step S401, arbitrary error processing may be performed.
  • the second method compared to the first method, there is no need to add a new signal for controlling the process. Therefore, the second method can be applied to existing communication devices without adding message types.
  • the second method if authentication fails with the old key, authentication is also performed with the new key, which increases the computational load. However, because the re-authentication process using the new key and old key only occurs at the actual switching timing, and because multiple re-authentications using the new key are required only when the order of reception is switched, the increase in load can be suppressed. .
  • the communication device to which the present invention is applicable is not limited to the configuration exemplified below, and various modifications such as changing the application destination and replacing with components having similar functions are possible.
  • the communication device may be composed of a general computer or electronic circuit such as an ECU. Alternatively, it may be realized virtually by software or the like.
  • the transmission/reception may be data transmission/reception between software, such as inter-process communication or data transmission/reception between modules.
  • the communication device will be configured separately into a transmitter and a receiver.
  • the transmitter may have the function of a receiver, or the receiver may have the function of a transmitter.
  • a configuration in which a plurality of transmitters or receivers are connected via a network may also be used.
  • the transmitter and receiver are connected to enable transmission and reception of signals and data.
  • the communication method may be wired or wireless, and any communication method may be used.
  • Various CAN communications are mainly used in in-vehicle equipment and ECUs.
  • FIG. 10 is a diagram showing the configuration of a transmitter and a receiver according to an embodiment of the present invention.
  • Encrypted communication using a key in this embodiment is performed between the ECUs 10 and 20. Encrypted communication using a key is also performed between the ECUs 10 and 20 and the gateway 50. Furthermore, encrypted communication using keys is also performed between the ECU 10 and the management center 100 and between the gateway 50 and the management center 100. In these cases, at a certain timing, one device (eg, ECU 10) becomes a transmitter, and the other opposing device (eg, ECU 20) becomes a receiver. At other timings, communication is performed by switching transmission and reception (for example, the ECU 20 serves as a transmitter and the ECU 10 serves as a receiver).
  • a microcomputer 12 is installed inside the ECU 10.
  • the microcomputer 12 includes at least one processor (CPU) 13 that executes programs, a RAM 14 that provides a volatile storage area, at least one communication unit 15 that controls communication with other devices, and a non-volatile memory that stores programs and data. It has a non-volatile memory 16 for holding data in a static storage area.
  • a microcomputer 22 is mounted inside the ECU 20.
  • the microcomputer 22 includes at least one processor (CPU) 23 that executes programs, a RAM 24 that provides a volatile storage area, at least one communication unit 25 that controls communication with other devices, and a nonvolatile memory that stores programs and data. It has a non-volatile memory 26 for holding data in a permanent storage area.
  • the gateway 50 is a device that controls communication between ECUs, and includes a control section 51 that executes a program, and a communication section 52 that controls communication with other devices.
  • the control center 110 is a computer that provides data and programs to the ECU 10, and includes an application section 111 and a communication section 112.
  • the application unit 111 executes a process of providing data and programs to the ECU 10.
  • the communication unit 112 controls communication with the ECU 10 and the gateway 50.
  • the transmitter uses a common key to calculate a hash value (here mainly deals with MAC) using the data to be transmitted and the freshness value as input.
  • a hash value here mainly deals with MAC
  • the freshness value is not essential, it may be applied 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 the combined data as a frame.
  • the receiver receives the security communication frame and obtains the data, freshness value, and hash value.
  • the receiver calculates the entire freshness value based on the freshness value of the transmitter recorded. For example, if only the lower byte portion of the freshness value is being transmitted, the upper byte portion is inferred and calculated by the receiver from the transmitter's freshness value recorded.
  • the freshness value is a value that has been received before, or if it is outside the range in which reception is permitted, the authentication is deemed to have failed.
  • the freshness value may be determined after determining the hash calculation result, which will be described later.
  • hash calculation has a larger computational load than freshness value determination, so it is more efficient to perform freshness value determination first. If the freshness value cannot be determined without performing security calculations such as hash calculations and decryption, it is recommended to perform security calculations first.
  • a part of the hash value calculated by the receiver is extracted and compared in the same way as the transmitter.
  • the receiver accepts the frame. In other words, the authentication is successful. If the application fails, it will not be accepted. In other words, authentication is failed. If it fails, you may perform failure processing. For example, a notification may be sent to the effect that it has failed.
  • each communication device Upon receiving the key change command, each communication device starts the process of switching the key used for secure communication.
  • the key change command may be sent by a specific device on the network to the communication device, or may be sent by any communication device to the communication device on the network. You can prepare the key to be used in advance and switch the key to be used in the key change command, or select the key to be used in the key change command or the series of processes, or you can change the key between communication devices. You may also use key sharing. Further, the key change command may be sent by an external tool that is temporarily connected.
  • the transmitter When the transmitter receives the key change command and the new key after switching is ready, it starts waiting for the key preparation completion notification 1 from the receiver. During this time, normal processing continues, and secure communication continues using the old key before the change. If the configuration is such that authentication using a new key is not provided for sending and receiving notifications, it is sufficient that the new key can be prepared by the timing of the key change notified in the key change timing notification 2.
  • the receiver receives the key change command and sends a key preparation completion notification 1 when the new key after switching is ready.
  • the receiver may send the key preparation completion notification 1 at the timing when the new key becomes available for use, or the receiver may send the key preparation completion notification 1 at the timing when the new key becomes available for use, or the receiver may send the key preparation completion notification 1 at the timing when the new key becomes available for use. It may be transmitted a predetermined time after the timing when it becomes available. Further, the key preparation completion notification 1 may be periodically transmitted in consideration of the case where the transmitter is not in a state where a new key can be used at the timing of transmitting the key preparation completion notification 1. It is sufficient to transmit the key preparation completion notification 1 before receiving the key change timing notification 2 from the transmitter.
  • the transmitter After receiving the key preparation completion notification 1 from the receiver, the transmitter transmits the key change timing notification 2.
  • the freshness value is used to specify the timing of switching the key to be used.
  • the key change timing notification 2 includes information on the freshness value that is set 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 due to a change in the order of transmission processing and reception processing, the secure communication frame using the new key may be sent before the receiver receives and processes the key change timing notification 2. Since there is a risk that the notification may be received and processed, it is desirable to set the timing to be in the future than the notification transmission timing.
  • the receiver When the receiver acquires 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, and performs authentication processing using the old key. If it is after the timing value, authentication processing is performed using a new key (S303 to S305).
  • the result of calculating a hash value using the new key may be added to each notification.
  • a hash value calculated using a freshness value, a specific data string, or the payload of the notification to be sent may be added to the notification.
  • the transmitter and receiver may calculate the hash value using mutually known information and a key. By doing this, processing can be continued only when the new key is changed to the same new key. For example, if the value of the new key to which the transmitter and receiver are switching is different due to an error, etc. It is possible to suppress the start of communication using a new key. If authentication fails in each notification, error handling may be performed. For example, it may send a notification of a key mismatch or log an error.
  • the key preparation completion notification 1 may be sent with the old key or with no authentication required. In a configuration in which the key preparation completion notification 1 is sent using the old key or in a state where no authentication is required, it is possible to detect on the network that a key change process has started in a transmitter that has not prepared a new key.
  • FIG. 5 is a timing chart of an operation example of this embodiment, and shows an operation example when switching to key 0, key 1, and key 2 in order.
  • key preparation of the receiver is completed after the key preparation of the transmitter is completed.
  • key 1 becomes the old key and key 2 becomes the new key.
  • an operation example will be shown in which the key preparation of the transmitter is completed after the key preparation of the receiver is completed.
  • the transmitter When a key change command is issued to change the key from 0 to 1 while key 0 is in use (t15), the transmitter first prepares the key (t16). The transmitter waits for the key preparation completion notification 1 that is transmitted after the receiver completes the key preparation (t21) (t22). After receiving the key preparation completion notification 1 (t22), the transmitter transmits the key change timing notification 2 (t24). Key change timing notification 2 includes information on key change timing 3.
  • key change timing notification 2 includes information on key change timing 3.
  • the transmitter and receiver reach key change timing 3 (t29), they change the key used during transmission from 0 to 1.
  • the receiver authenticates security communication frames received after key change timing 3 (t29) using key 1, and authenticates security communication frames received before key change timing 3 (until t28) using key 0.
  • the time t is the freshness value, and even if the order of processing is changed on the receiver side, the key used by the freshness value is managed.
  • the receiver is ready for the key first (t34).
  • the receiver transmits key preparation completion notification 1 (t35).
  • the transmitter ignores the key preparation completion notification 1 (t35, t37) while the key is not ready (from t34 to t38).
  • the transmitter receives the key preparation completion notification 1 (t39)
  • it transmits the key change timing notification 2 (t40).
  • Key change timing notification 2 includes information on key change timing 3.
  • the receiver may stop transmitting the key preparation completion notification 1.
  • the transmitter and receiver switch the key to be used at key change timing 3, similar to the case where key 0 is changed to key 1.
  • FIG. 6 is a timing chart of an operation example when the second method of determining the predetermined period without using the freshness value is adopted.
  • the main difference in processing from FIG. 5 is that after the preparation of new key 1 is completed (t16), the transmitter uses key 0 to send secure communication frames during a predetermined time 1a (t16 to t24). Send.
  • the receiver performs authentication processing using key 0 from after completion of key preparation (t19) until authentication with key 0 fails and authentication with key 1 succeeds (t24). Further, even after successful authentication using key 1 (t24), the receiver also performs authentication using key 0 for a predetermined period of time (see FIG. 4).
  • each communication device has the functions and processing of the transmitter and receiver described above.
  • communication device 1 and communication device 2 communicate, communication device 1 has a receiver function and a transmitter function for communication device 2, and communication device 2 has a receiver function and a transmitter function for communication device 1.
  • It has the following functions. Processing of security communication from communication device 1 to communication device 2 and security communication from communication device 2 to communication device 1 are performed independently. For example, when changing the common key related to security communication from communication device 1 to communication device 2, it is not necessary to change the common key related to security communication from communication device 2 to communication device 1.
  • security communication processing may be considered to be independent for each communication path. In such a case, the process of the present invention may be applied to each communication path.
  • the processing of the present invention is preferably performed independently for each communication path.
  • Communication control information such as freshness value, key, key change timing 3, etc. is managed for each communication path. If keys are changed simultaneously on multiple communication paths, the new key and old key may be shared by each communication path. Furthermore, the same common key may be used in the transmission path and the reception path.
  • step S102 of FIG. 1 the determination is YES when the key preparation completion notification 1 is received from all the receivers.
  • multiple transmitters may be provided.
  • Communication control information such as freshness value, key, key change timing 3, etc. is managed for each transmission source.
  • the new key and old key may be shared by each communication path.
  • the predetermined period 2 of the receiver is after the key change timing notification 2 has been received and the key change timing 3 has passed for all transmitters, or after the timing when authentication with the new key has been successful, It is preferable to lock or delete the old key after an arbitrary period of time has elapsed (for example, after the timing at which reception using the old key is no longer possible).
  • the keys are changed simultaneously in all the transmitters, if the key change timing notification 2 cannot be received from at least some of the transmitters, it may be treated as an error and an error process may be executed.
  • a count value that increases each time 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 context of the transmission in the period from receiving the key change timing notification 2 to the key change timing 3. For example, if values from 0 to 100 are adopted, a value corresponding to a count of minus 30 from the current value may be set as a past value. Here, if the current value is 20, subtracting 30 will result in -10, and correcting it within the range of 0 to 100 will result in 90. At this time, it is preferable to treat 20 to 89 as future values, and 90 to 100 and 0 to 19 as past values.
  • a count value that can be received with a change in order for example 91, is a past value. If the count value is 20, by setting the key change timing to a future value such as 89, the receiver will change the key to be used at the timing when the count value 89 is first passed after receiving the key change timing notification 2. All you have to do is switch.
  • the handling of the authentication result in the key change process may be changed depending on the cause of the failure.
  • a communication device on the network may request a key management communication device that manages keys to change the key, and the key management communication device that receives the key change request may start the key change process.
  • any communication device on the network can make a key change request, and one specific communication device can manage the key change timing and key value, so that when key change requests overlap, It is possible to prevent differences in the keys used, which may occur during Furthermore, since each communication device can detect a security risk and request a key change, the load for detecting a security risk can be distributed.
  • the present invention can be used not only for communications to prevent impersonation, but also for changing keys used in encrypted communications.
  • the timing of changing the key to be used can be specified by assigning a sequence number that indicates the transmission order of encrypted communication. Only the sequence number may be transmitted in plain text, or the sequence number may be included in the cipher text if it is possible to determine whether the decryption is successful.
  • the key preparation completion notification 1 and the key change timing notification 2 may be encrypted using the old key.
  • at least only the sequence number may be encrypted using the old key. By doing so, it is possible to uniquely identify the sequence number even in a situation where new keys and old keys are mixed.
  • a 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.
  • a hash value using a decryption key may be added.
  • the technology for changing the key for secure communication described above can also be applied to applications that change the key at any time. For example, if interference is detected in the security communication while the vehicle is running, the key can be changed immediately, improving security risk resistance. That is, the key may be changed if the hash values of communications with the same value (for example, freshness value) representing the data transmission timing are correct.
  • One example in which it can be determined that a key has been leaked is to record at least part of the received freshness value and hash value as a reception history, and for a received message, if the hash value is correct and the same freshness value exists in the reception history, If the hash values are different, it can be determined that the key has been leaked.
  • 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 performed using a leaked key.
  • memory can be saved compared to recording and comparing all received messages. If part of the hash value is to be recorded, it is advisable to extract part of the received hash value using a similar method.
  • FIG. 8 is a diagram showing the key change timing in this embodiment.
  • the transmitter continues to transmit using the old key for a predetermined period 1 after the key change.
  • the receiver authenticates the received message using the old key for a predetermined period 2.
  • the new key may be received each time the key is changed or may be received in advance. In this way, even during a period when the keys do not match between the transmitter and the receiver on the network, the old key and the new key can be mixed, and secure communication can be continued.
  • FIG. 9 is a diagram showing the key change timing in this embodiment.
  • the transmitter when the 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.
  • the receiver allows authentication using the old key for a predetermined period 2, taking into account the shift in key change timing. That is, if authentication with one key fails, authentication is attempted with the other key.
  • the transmitter transmits a notification regarding the key change timing when the new key after the change becomes available, and after the new key becomes available, the transmitter sends a notification regarding the key change timing.
  • the data is transmitted using the old key before the change during a first predetermined period of time, and the receiver performs an authentication process upon reception using the old key during a second predetermined period after the new key becomes usable.
  • a notification regarding the key change timing is received 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. Since authentication processing is performed, security communication failures due to key changes can be reduced. Furthermore, even during the key change, secure communication can be continued as usual, so the key can be changed at any timing. By determining whether the key is correct based on the success or failure of decryption, it can be applied to various security communications.
  • the receiver fails authentication using the old key during the second predetermined period, it can switch to the correct key without receiving a notification by performing authentication processing using the new key.
  • the receiver transmits a key preparation completion notification to the transmitter when authentication becomes possible with the new key, and the first predetermined period is a period until receiving the key preparation completion notification. , notifications can be used to ensure switching to the correct key.
  • the receiver transmits a key preparation completion notification when authentication becomes possible with the new key, receives the key preparation completion notification for a first predetermined period, and further receives the key preparation completion notification when a predetermined period elapses or a predetermined period elapses.
  • the transmitter can reliably match the key change timing between the transmitter and the receiver.
  • the key change timing can be reliably matched between the transmitter and the receiver.
  • first predetermined period and the second predetermined period are specified by the freshness value used for secure communication, secure communication can be continued even if the order of arrival of data is changed. Furthermore, since the existing freshness value is used, there is no need to provide a separate counter to manage keys.
  • the present invention is not limited to the embodiments described above, and includes various modifications and equivalent configurations within the scope of the appended claims.
  • the embodiments described above have been described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to having all the configurations described.
  • a part of the configuration of one embodiment may be replaced with the configuration of another embodiment.
  • the configuration of one embodiment may be added to the configuration of another embodiment.
  • other configurations may be added, deleted, or replaced with a part of the configuration of each embodiment.
  • each of the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in part or in whole by hardware, for example by designing an integrated circuit, and a processor realizes each function. It may also be realized by software by interpreting and executing a program.
  • Information such as programs, tables, files, etc. that realize each function can be stored in a storage device such as a memory, hard disk, or SSD (Solid State Drive), or in a recording medium such as an IC card, SD card, or DVD.
  • a storage device such as a memory, hard disk, or SSD (Solid State Drive)
  • a recording medium such as an IC card, SD card, or DVD.
  • control lines and information lines shown are those considered necessary for explanation, and do not necessarily show all control lines and information lines necessary for implementation. In reality, almost all configurations can be considered interconnected.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Lock And Its Accessories (AREA)

Abstract

送信機と受信機の間で鍵を用いてセキュリティ通信を行う通信システムであって、前記鍵を前記セキュリティ通信中に変更可能であって、前記送信機は、変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、前記新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信し、前記受信機は、前記新鍵が使用可能になった後の第２の所定の期間において前記旧鍵で受信時の認証処理を行い、前記送信機から前記鍵変更タイミングに関する通知を受信した場合、鍵変更タイミングより前に送信されたデータは前記旧鍵で認証処理を行い、前記鍵変更タイミングより後に送信されたデータは前記新鍵で認証処理を行う。

Description

通信システム、送信機、及び受信機
　本発明は、セキュリティ通信を行う通信システムに関する。
　コンピュータのセキュリティ通信の一つになりすまし防止の仕組みがある。例えば、通信機間で共通する鍵を用いてハッシュ値を計算し、受信機の計算結果と比較して受信したハッシュ値と計算したハッシュ値が一致するかを判定する。
　自動車の車載用ソフトウェアに活用されるＡＵＴＯＳＡＲ仕様によれば、ＣＡＮメッセージフレームに共通鍵で算出されるＭＡＣ(Message Authentication Code)を付与して、なりすまし防止ができる。また、フレッシュネス値を追加して、再送信攻撃を防止できる。
　共通鍵を用いたセキュリティ通信では、鍵変更時に各通信機における鍵変更のタイミングが同時ではない場合、セキュリティ通信の認証失敗によって、通信不可能な状態が生じる。また、認証失敗時の通知が発生し、通信負荷が増加する可能性がある。
　鍵変更に関する背景技術は以下のものが存在する。第一に鍵変更を各通信機器で逐次実行する方法があり、第二に鍵変更時は鍵変更モードなどに移行してネットワーク上の通信機の鍵をすべて変更完了させてから、通常モードに復帰する方法がある。
　第一の場合では、鍵変更が完了するタイミングの差によって、ネットワーク上の機器間で鍵が異なる期間が生じ、当該期間でセキュリティ通信が不可能な期間が生じ、セキュリティ通信の失敗が発生する。
　第二の場合では、鍵変更モードでは、通常モードで利用する少なくともセキュリティ通信機能が制限されるため、鍵変更処理は特定の状況に制約される。
　通信中に鍵を変更する技術として、以下の背景技術がある。特許文献１（特開２０１２－２２７６７２号公報）には、共通鍵を管理する鍵管理サーバ、路側機、車載機で構成する車車／路車間通信システムにおいて、鍵管理サーバがエリアの管理をおこない、あるエリアに存在する路側機および車載機は同じ共通鍵を共有し、共有した共通鍵を使ってメッセージの機密性または完全性、もしくはその両方を保証することを特徴とする車車／路車間通信システムが記載されている。
特開２０１２－２２７６７２号公報
　前述した背景技術では、本願が想定するような、任意のタイミングで使用する鍵を変更する場合や、予め決まっていない任意の鍵に変更する場合、未知の新しい鍵の変更タイミングの特定が困難である。また、通信機器間で鍵変更タイミングを合わせるため、時刻同期が必要である。
　本発明は、鍵変更に伴うセキュリティ通信の失敗の軽減を目的とする。
　本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、送信機と受信機の間で鍵を用いてセキュリティ通信を行う通信システムであって、前記鍵を前記セキュリティ通信中に変更可能であって、前記送信機は、変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、前記新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信し、前記受信機は、前記新鍵が使用可能になった後の第２の所定の期間において前記旧鍵で受信時の認証処理を行い、前記送信機から前記鍵変更タイミングに関する通知を受信した場合、前記鍵変更タイミングより前に送信されたデータは前記旧鍵で認証処理を行い、鍵変更タイミングより後に送信されたデータは前記新鍵で認証処理を行うことを特徴とする。
　本発明の代表的な実施の形態によれば、鍵変更に伴うセキュリティ通信の失敗を軽減できる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
本発明の実施例の送信機の処理の例のフローチャートである。 本発明の実施例の受信機の処理の例のフローチャートである。 第１の方法における受信機の処理の例のフローチャートである。 第１の方法における受信機の処理の例のフローチャートである。 第２の方法における受信機の処理の例のフローチャートである。 第２の方法における受信機の処理の例のフローチャートである。 本実施例の動作例のタイミングチャートである。 第２の方法の動作例のタイミングチャートである。 受信処理順序が入れ替わる場合の説明図である。 本実施例の鍵変更のタイミングを示す図である。 本実施例の鍵変更のタイミングを示す図である。 本発明の実施例の送信機と受信機の構成を示す図である。
　本発明の実施例は、鍵変更の指令がなされたとき、鍵の受け取り完了後に、送信機は古い鍵での送信を所定の期間１だけ継続し、受信機は古い鍵での受信メッセージの認証を所定の期間２だけ行う。
　ここで、鍵受け取り完了のタイミングとは、使用する鍵を切り替え可能な状態としてもよい。また、予め次に使用する共通鍵が決まっている場合は、次の共通鍵を使用する指令などを受け取ったタイミングを鍵受け取り完了のタイミングとしてもよい。また、鍵受け取り完了のタイミングは、日時などで予め指定されてもよい。
　旧鍵は、送信機、受信機ともに所定の期間１や所定の期間２の終了後に削除したり、ロックしてもよい。旧鍵は、鍵の不一致期間と送信、受信処理順序が入れ替わった場合に使用するので、入れ替わりによる旧鍵で認証されるフレームを受信できなくなった場合に削除したりロックしてもよい。送信機の場合では、使用する鍵を新鍵に切り替えたタイミング以降では、旧鍵を使った送信処理を行わないので直ちに削除してもよい。例示した以外のタイミングでもよく、削除タイミングは様々なタイミングでよい。
　所定の期間１と所定の期間２を決定し設定する方法の例について説明する。
　第１の方法として、フレッシュネス値で鍵の変更タイミングを特定する方法について説明する。
　図１は、送信機の処理の例のフローチャートであり、図２、図３Ａ及び図３Ｂは、受信機の処理の例のフローチャートである。図２は、使用する鍵の変更タイミングが決定するまでの処理を記載し、図３Ａ及び図３Ｂは、鍵変更処理が開始してから、鍵の切り替えが完了するまでの受信処理を記載する。図１と図２は、それぞれ鍵変更指令を受信したときに開始されてもよい。図３Ａ及び図３Ｂは、受信機が鍵変更指令を受信してから旧鍵を用いた送信がされなくなるまでの間のセキュリティ通信の受信処理でもよい。
　第１の方法では、期間の一例はフレッシュネス値とするが、通信機器間でタイミングを計れる値であればよく、時間や通信回数などを使用できる。
　図１に示すように、送信機は、鍵変更タイミングで鍵管理装置から新鍵を受け取って、新鍵が使用可能となるまで待機し（Ｓ１０１）、所定の時間が経過してタイムアウトするまで（Ｓ１０７）、鍵準備完了通知１を受信したかを判定する（Ｓ１０２）。鍵準備完了通知１を受信せずに所定の時間が経過してタイムアウトした場合（Ｓ１０７でＹＥＳ）、タイムアウト時の処理を実行する（Ｓ１０８）。タイムアウト時の処理は任意のものでよく、その一例は、鍵の変更処理をキャンセルしたり、エラー通知をするものとしてもよい。また、タイムアウトを設けずに処理を継続してもよい。一方、鍵準備完了通知１を受信した場合（Ｓ１０２）、鍵変更タイミングを決定し（Ｓ１０３）、鍵変更タイミング通知２を送信する（Ｓ１０４）。鍵変更タイミングは、受信側の準備時間後の将来のタイミングであり、例えば、現在時刻（現在のフレッシュネス値）に所定値を加算して計算できる。フレッシュネス値でなく時間や通信シーケンスを計測できる値を使用してもよい。データの到着順乱れを考慮するとシーケンシャルに付与されるフレッシュネス値を採用するとよい。鍵変更タイミング通知２には、鍵変更するときのフレッシュネス値を含める。この値までが所定の期間１（図６の時間１ａ）であり、将来のタイミングとすることが望ましいが、受信機が鍵変更タイミング通知２を十分に受信できる期間となるように設定するとよく、例えば、通信の設計に基づいた値を設定しても、通信負荷や頻度や相手数など通信状況に基づいて設定してもよいし、これらに基づいて動的に設定してもよい。
　その後、送信機は、鍵変更タイミング３に到達したかを判定する（Ｓ１０５）。鍵変更タイミングに到達していなければ、鍵変更タイミング通知を所定のタイミングで繰り返し送信し（Ｓ１０９）、鍵変更タイミングに到達したかの判定を続ける。一方、鍵変更タイミングに到達していれば、送信時に使用する鍵を切り替える（Ｓ１０６）。ステップＳ１０９における定期送信は、鍵変更到達タイミングまでに所定の回数が送信されるように、その送信間隔が設定されてもよい。
　図２に示すように、受信機は、新鍵が使用可能となるまで待機し（Ｓ２０１）、鍵受け取りを完了した場合、鍵準備完了通知１を送信する（Ｓ２０２）。そして、鍵変更タイミング通知２を受信したかを判定する（Ｓ２０３）。鍵変更タイミング通知２を受信しない場合、ステップＳ２０２に戻り、鍵変更タイミング通知２を受信するまで、鍵準備完了通知１を送信してもよい。鍵変更タイミング通知２を複数回送信してもよい。一方、鍵変更タイミング通知２を受信した場合、受信した鍵変更タイミング通知に従って、鍵変更タイミング３を決定する（Ｓ２０４）。ステップＳ２０２の送信前に、所定時間の待機を追加してもよい。受信機が新鍵を受け取るまでに必要な最大の時間を待機することで、鍵準備完了通知１が受信されない場合を減らすことができる。所定の時間までに、ステップＳ２０３において、鍵変更タイミング通知２を受信できなかった場合、タイムアウト時の処理を実行してもよい。一例は、鍵変更処理のキャンセルやエラーの通知である。
　送信機は、受信機が複数存在する場合、全ての受信機から鍵準備完了通知１を受け取ってから、鍵変更タイミング通知２を送信するとよい。少なくとも一部の受信機から鍵準備完了通知１を受け取れない場合に、タイムアウトを設定して以降の処理を続行させてもよい。この場合、鍵準備完了通知１を受信できなかった受信機を無視して、新しい鍵を用いた送受信処理を続けてもよいし、ネットワーク全体の通信を制限してもよい。このような場合に実行される所定の処理をステップＳ１０８で実行してもよい。タイムアウトが発生した場合にタイムアウト時の任意の処理を実行してもよい。例えば、エラーの通知や、鍵変更処理のキャンセルをしてもよい。
　図３Ａ及び図３Ｂに示すように、受信機は、鍵変更指令の受信後、受信データから受信フレッシュネス値を抽出する（Ｓ３０１）。なお、毎回フレッシュネス値を抽出せずに、前回受信したフレッシュネス値から推測してもよい。鍵変更タイミング通知２を受信しているかを判定する（Ｓ３０２）。そして、鍵変更タイミング通知２を受信した場合、受信フレッシュネス値が鍵変更タイミング以降であるかを判定する（Ｓ３０３）。そして、鍵変更タイミング以降の受信フレッシュネス値のタイミングでは新鍵で受信し（Ｓ３０４）、鍵変更タイミング以前の受信フレッシュネス値のタイミングでは旧鍵で受信する（Ｓ３０５）。このタイミングまでが所定の期間２（図６の２ａ）となる。タイミングを時間や通信回数などで定める場合も同様に、鍵変更タイミング以前か以降かによって使用する鍵を分けるとよい。
　その後、受信機は、認証が成功したかを判定する（Ｓ３０６）。例えば、認証は、送信されたデータとフレッシュネス値のハッシュ値が一致するかを判定するとよい。また、受信済みフレッシュネス値を再度の受信すると認証失敗と判定するとよい。認証に成功した場合、認証成功時処理を実行し（Ｓ３０７）、認証に失敗した場合、認証失敗時処理を実行する（Ｓ３０８）。受信機が鍵変更タイミング通知２を受信している場合は、認証失敗の要因は新鍵と旧鍵との切り替え処理における使用鍵の間違いであることは、理論上は無いと考えることもできる。従って、鍵の切り替え処理における認証失敗時の処理や成功時の処理（Ｓ３０８、Ｓ３０７）を行わず、もともとの認証結果に応じた処理を行ってもよいし、ステップＳ３０７、Ｓ３０８はもともとの認証結果に応じた処理としてもよい。
　ステップＳ３０２で鍵変更タイミング通知２を受け取れなかった場合、新鍵で受信経験あり、かつ受信フレッシュネス値が鍵変更タイミング以降（所定の期間２（図６の２ｂ））であるかを判定する（Ｓ３１６）。新鍵で受信経験ない、又は受信フレッシュネス値が鍵変更タイミング以降でない場合（Ｓ３１６でＮＯ）、新鍵か旧鍵か不明なので、旧鍵と新鍵の両方での認証を試行する。すなわち、旧鍵で認証し（Ｓ３０９）、認証が成功したかを判定する（Ｓ３１０）。旧鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ３１４）。旧鍵での認証に失敗した場合、新鍵で認証し（Ｓ３１１）、認証が成功したかを判定する（Ｓ３１２）。新鍵での認証に成功した場合、以後は新鍵で認証をすればよいので受信フレッシュネス値で鍵変更タイミングを変更し、そのタイミングを所定の期間２（図６の２ｂ）の終了タイミングとする（Ｓ３１３）。新鍵での認証に失敗した場合、認証失敗時処理を実行する（Ｓ３１５）。
　一方、新鍵で受信経験あり、かつ受信フレッシュネス値が鍵変更タイミング以降である場合（Ｓ３１６でＹＥＳ）、新鍵で認証し（Ｓ３１７）、認証が成功したかを判定する（Ｓ３１８）。新鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ３１９）。新鍵での認証に失敗した場合、認証失敗時処理を実行する（Ｓ３２０）。すなわち、新鍵で認証した以降のフレッシュネス値のタイミングにおいては新鍵で認証する。
　ステップＳ３１３において、複数の受信について新鍵での認証に成功した場合、フレッシュネス値が小さいものを採用し、当該小さいフレッシュネス値で鍵変更タイミングを変更する。旧鍵で認証成功したフレッシュネス値の最大値を記録し、当該最大値以下の受信では、新鍵による認証を試みなくてもよい。鍵変更タイミング通知２を受け取れなかった場合をエラーとしてもよく、その場合は旧鍵での認証失敗後の新鍵での再認証処理を実行しなくてもよい。旧鍵によるセキュリティ通信を受信しなくなったとき、旧鍵による受信を停止して、新鍵による通常のセキュリティ通信処理を実行してもよい。
　旧鍵か新鍵かが明らかでないフレッシュネス値、即ち、新鍵で受信したフレッシュネス値の最大値と新鍵で受信したフレッシュネス値の最小値の間の値について、最初に新鍵と旧鍵どちらの鍵で試行するかを、そのフレッシュネス値に応じて決めてもよい。例えば、旧鍵の最大値に近い値である場合は旧鍵でまず試行し、新鍵の最小値に近い値の場合は新鍵で試行するようにしてもよい。
　なお、Ｓ３０２で鍵変更タイミング通知２を受け取れなかった場合のステップＳ３１１、Ｓ３１２、Ｓ３１３の処理は、鍵変更タイミング通知２の受信に失敗した場合の対策となるオプションの処理であり、Ｓ３０２で鍵変更タイミング通知２を受け取れなかった場合に新鍵での認証試行を行わず認証エラー（例えばＳ３１５）としてもよい。
　鍵変更タイミング２を受信するまでの間（Ｓ３０２がＮＯの間）は、旧鍵を用いた通常の認証処理が行われるものとしてもよい。
　前述の構成にすることで、使用する鍵の変更タイミングをフレッシュネス値で明確に決定できるので、新鍵と旧鍵との鍵の不一致を要因とした認証失敗が生じない。その為、本当の認証失敗の発生タイミングを直ちに把握できる。また、フレッシュネス値でタイミングを特定する場合、フレッシュネス値に応じて使用する鍵を変えるので、送信処理順序や受信処理順序の入れ替わりの影響を受けない。
　図７に示すように、フレッシュネス値が１～４までを旧鍵、５以降を新鍵で送信する場合を例にして、受信処理順序の入れ替わり時の処理例を説明する。
　フレッシュネス値を用いず、受信処理順序通りに処理する場合、３を受信した後、６を受信し、旧鍵で失敗した後新鍵でリトライして認証できる。受信処理順序の入れ替わりがない場合は、以降の受信処理は新鍵を用いれば認証可能である。しかし、図７に示す例のように受信処理順序が入れ替わる場合、フレッシュネス値が５において新鍵を用いたデータ受信した後、フレッシュネス値が４において旧鍵を用いたデータを受信する場合がある。新鍵で認証に失敗した場合、旧鍵でリトライすることによって認証できる。フレッシュネス値を用いない場合は、フレッシュネス値がメッセージに含まれなくてもよい。
　フレッシュネス値を用いる場合、送信機はフレッシュネス値を順に増加するカウンタとしてセキュリティフレームを送信し、受信機は送受信メッセージに含まれるフレッシュネ値で使用する鍵を判定する。すなわち、旧鍵から新鍵へ変えるフレッシュネス値を設定し、当該フレッシュネス値より大きいか小さいかで新旧鍵を使い分ける。鍵変更タイミング通知２で新鍵を用いるフレッシュネス値を鍵変更タイミング３として通知する。図７に示す例では５が通知される。受信機は、フレッシュネス値が５未満の場合は旧鍵で認証処理を実行し、フレッシュネス値が５以上の場合は新鍵で認証処理を実行する。
　このため、図７に示すように、受信側でフレッシュネス値４～６の範囲で受信順序が入れ替わっても、セキュリティフレームを受信するための鍵を一意に特定でき、再認証が不要となる。また、セキュリティ通信に使用されるフレッシュネス値を用いるので、メッセージ構成の変更が不要である。
　ここで、鍵変更タイミング通知２と鍵準備完了通知１は、既存の通信に用いる信号で代用してもよい。例えば、同期用の信号で代用できる。具体的には、定期的にＭＡＣ値を付与して送信されるフレッシュネス値の同期用の信号に、新鍵でのＭＡＣ値を付与して送信する。受信機は同期用の信号の認証を旧鍵で失敗し新鍵で成功したとき、それが鍵変更タイミング通知２と判断することができる。このとき、旧鍵で計算したＭＡＣを付与したものを並行して送信してもよいし、新鍵で計算したもののみを送信してもよい。
　第２の方法として、ＭＡＣ認証の成否で使用する鍵の切り替えを行う方法について説明する。
　第２の方法における送信機の処理のフローチャートの例は、図１のステップＳ１０２において常にＹＥＳとなり、ステップＳ１０４において所定の時間だけ待機した後に鍵変更タイミング通知２を送信する場合と同じである。
　図４Ａ及び図４Ｂは、第２の方法における受信機の処理の例のフローチャートである。
　ここでは、所定の期間１（図６の１ｂ）は、受信機の新しい鍵の利用準備が完了できる十分な時間とするとよい。例えば、所定の期間１は、通信系の設計に基づいて設計者やユーザが任意に設定してもよく、バス負荷などに基づいて送信機や受信機などの通信機器が算出してもよく、送信回数などの通信機の処理に基づく条件で設定してもよい。
　受信機は、鍵変更指令受信以降、鍵の準備完了時に所定の期間２（図６の２ｂ）を開始し、新鍵で認証成功経験があるかを判定する（Ｓ４０１）。新鍵で認証成功経験があれば、新鍵で認証し（Ｓ４０９）、認証が成功したかを判定する（Ｓ４１０）。新鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ４１４）。新鍵での認証に失敗した場合、旧鍵で認証し（Ｓ４１１）、認証が成功したかを判定する（Ｓ４１２）。旧鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ４１４）。旧鍵での認証に失敗した場合、認証失敗時処理を実行する（Ｓ４１５）。
　新鍵で認証成功経験がなければ、旧鍵で認証し（Ｓ４０２）、認証が成功したかを判定する（Ｓ４０３）。旧鍵での認証に成功した場合、認証成功時処理を実行する（Ｓ４０８）。旧鍵での認証に失敗した場合、新鍵で認証し（Ｓ４０４）、認証が成功したかを判定する（Ｓ４０５）。新鍵での認証に成功した場合、そのタイミングを所定の期間２（図６の２ｂ）の完了タイミングとして、認証成功時処理を実行する（Ｓ４０８）。新鍵での認証に失敗した場合、認証失敗時処理を実行する（Ｓ４０７）。
　受信機は、タイミングの判断にフレッシュネス値を用いて、第１の方法のように処理してもよいし、新鍵での認証成功タイミング以降の時間的タイミングであるかによって切り替えてもよい。フレッシュネス値をタイミングとして利用する場合、切り替えタイミングより遅いタイミングのフレッシュネス値の認証を旧鍵で失敗した場合は、新鍵で認証を行うとよい。複数の受信について新鍵での認証に成功した場合、フレッシュネス値が小さいものを採用し、当該小さいフレッシュネス値で鍵変更タイミングを変更する。旧鍵で認証成功したフレッシュネス値の最大値を記録し、当該最大値以下の受信では、新鍵による認証を試みなくてもよい。また、新鍵で認証を試みてから旧鍵で認証を試みてもよい。
　所定の期間２（図６の２ｂ）の間に新鍵での認証に成功した場合、所定の期間２（図６の２ｂ）を延長してもよい。このようにすることで、送信処理と受信処理の順序の入れ替わりによる認証失敗を抑制できる。例えば、新鍵で認証成功した後も、しばらくの間旧鍵での受信を許容する（Ｓ４１１）。継続する期間は、時間的に延長してもよいし、例えば「ｎ回受信するまで」のように受信回数で条件を設定してもよい。また、新鍵での認証に成功した場合、所定の期間２を短くしてもよい。新鍵での受信後に旧鍵での受信ができる期間を減らすことができる為、セキュリティが向上する。
　新鍵での認証成功後は、送信処理と受信処理の順序の入れ替わらない限り新鍵で認証される通信フレームを受信するので、新鍵で認証を試みてから旧鍵での認証を試みることで（Ｓ４０９、Ｓ４１０、Ｓ４１１、Ｓ４１２）、セキュリティ計算の回数を削減できる。また、新鍵での認証に成功するまでは、旧鍵での認証を先に試みることで（Ｓ４０２、Ｓ４０３、Ｓ４０４、Ｓ４０５）、セキュリティ計算の回数を削減できる。但し、通信確立の観点からは認証を試みる鍵の順番はいずれでもよい。
　所定の期間２（図６の２ｂ）が終了した後は、図４のフローチャートに代えて、新鍵を用いた通常の受信処理を行ってもよい。つまり、旧鍵を用いた通信を許容しない状態に移行してもよい。
　ステップＳ４０１で所定の期間内に新鍵での認証がされなかった場合、任意のエラー処理を実行してもよい。
　第２の方法では、第１の方法と比較して、処理の制御用に新たな信号を追加する必要がない。そのため、メッセージの種類の追加をすることなく、既存の通信機に第２の方法を適用できる。
　第２の方法では、第１の方法と比較して、旧鍵で認証失敗した場合に新鍵での認証も行うので、計算負荷が増加する。しかし、新鍵、旧鍵での再認証処理は実際の切り替えタイミングでのみ発生すること、受信順序の入れ替わり時のみ新鍵での複数回の再認証が必要なことから、負荷の増加を抑制できる。
　以上に説明した実施例を適用可能な通信機の例を説明する。本発明が適用可能な通信機は以下に例示する構成に限らず、適用先の変更や、類似機能を持つ構成要素への置き換えなどの種々の変形が可能である。
　通信機は、ＥＣＵなど一般的なコンピュータや電子回路で構成されるものでよい。また、ソフトウェアなどによって仮想的に実現されるものでもよい。送受信は、例えばプロセス間通信やモジュール間のデータの送受信など、ソフトウェア間のデータの送受信でもよい。
　本実施例の説明のため、通信機は送信機と受信機とで分けて構成する。送信機が受信機の機能を有してもよいし、受信機が送信機の機能を有してもよい。複数の送信機又は受信機がネットワークで接続される構成でもよい。
　送信機と受信機は、信号やデータの送受信が可能に接続される。通信の方法は有線、無線のいずれでもよく、いずれの通信方式でもよい。車載機器、ＥＣＵでは主に様々なＣＡＮ通信が用いられる。
　図１０は、本発明の実施例の送信機と受信機の構成を示す図である。
　本実施例における鍵を用いた暗号化通信は、ＥＣＵ１０、２０の間で行われる。また、ＥＣＵ１０、２０とゲートウェイ５０との間でも鍵を用いた暗号化通信が行われる。さらに、ＥＣＵ１０と管理センタ１００の間や、ゲートウェイ５０と管理センタ１００の間でも鍵を用いた暗号化通信が行われる。これらの場合、あるタイミングでは、一方の装置（例えばＥＣＵ１０）が送信機となり、対向する他方の装置（例えばＥＣＵ２０）が受信機となる。また、他のタイミングでは送受信が入れ替わって通信が行われる（例えば、ＥＣＵ２０が送信機となり、ＥＣＵ１０が受信機となる）。
　ＥＣＵ１０の内部には、マイコン１２が搭載されている。マイコン１２は、プログラムを実行する少なくとも一つのプロセッサ（ＣＰＵ）１３と、揮発性記憶領域を提供するＲＡＭ１４と、他の装置との通信を制御する少なくとも一つの通信部１５と、プログラムやデータを不揮発性記憶領域に保持する不揮発性メモリ１６を有する。同様にＥＣＵ２０の内部には、マイコン２２が搭載されている。マイコン２２は、プログラムを実行する少なくとも一つのプロセッサ（ＣＰＵ）２３と、揮発性記憶領域を提供するＲＡＭ２４と、他の装置との通信を制御する少なくとも一つの通信部２５と、プログラムやデータを不揮発性記憶領域に保持する不揮発性メモリ２６を有する。
　ゲートウェイ５０は、ＥＣＵ間の通信を制御する装置であり、プログラムを実行する制御部５１と、他の装置との通信を制御する通信部５２を有する。
　管制センタ１１０は、ＥＣＵ１０にデータやプログラムを提供する計算機であり、アプリケーション部１１１と通信部１１２とを有する。アプリケーション部１１１は、データやプログラムをＥＣＵ１０に提供する処理を実行する。通信部１１２は、ＥＣＵ１０やゲートウェイ５０との通信を制御する。
　通常時のセキュリティ通信では、送信機は共通鍵を用いて、送信するデータとフレッシュネス値を入力にハッシュ値（ここでは主にＭＡＣを扱う）を計算する。前述した第２の方法については、フレッシュネス値は必須ではないものの、再送信攻撃の防止のために適用するとよい。
　送信機は、データと、フレッシュネス値の少なくとも一部と、ハッシュ値の少なくとも一部を結合して、フレームとして送信する。
　受信機は、セキュリティ通信のフレームを受信し、データと、フレッシュネス値と、ハッシュ値を取得する。
　送信機がフレッシュネス値の一部のみを送信している場合、受信機が記録している送信機のフレッシュネス値に基づいて、フレッシュネス値の全部を計算する。例えば、フレッシュネス値の下位バイト部分しか送信されていない場合は、上位バイトの部分は、受信機が記録している送信機のフレッシュネス値から推論し、計算する。
　このとき、受信経験があるフレッシュネス値である場合や、受信を許可する範囲外である場合は、認証失敗とする。後述するハッシュ計算結果の判定の後にフレッシュネス値を判定してもよい。一般的に、フレッシュネス値の判定よりハッシュ計算の方が計算負荷が大きいので、フレッシュネス値の判定を先に実施したほうが効率が良い。ハッシュ計算や復号などセキュリティ計算を実施しないとフレッシュネス値が分からない場合、セキュリティ計算を先に実施するとよい。
　ハッシュ値の一部を送信している場合、受信機で計算したハッシュ値を、送信機と同様の方法で一部を取り出して比較する。
　受信したハッシュ値と計算したハッシュ値が一致した場合は、受信機はフレームを受理する。即ち認証成功とする。失敗した場合は受理しない。即ち認証失敗とする。失敗した場合は、失敗時の処理を実施してよい。例えば、失敗した旨を通知するようにしてもよい。
　各通信機は、鍵変更の指令を受け取ると、セキュリティ通信に用いる鍵を切り替える処理を開始する。鍵変更の指令は、ネットワーク上の特定の機器が通信機に送信してもよいし、いずれかの通信機がネットワーク上の通信機に送信してもよい。使用する鍵を予め用意しておいて、鍵変更の指令で使用する鍵を切り替えてもよいし、鍵変更の指令やその一連の処理において使用する鍵を選択してもよいし、通信機間での鍵の共有を使用してもよい。また、鍵変更の指令は、一時的に接続される外部ツールによって送信されるものでもよい。
　本実施例の第１の方法を適用する場合について説明する。
　送信機は、鍵変更の指令を受信し、切り替え後の新鍵が準備できたとき、受信機から鍵準備完了通知１を待機する状態を開始する。この間も、通常の処理は継続され、変更前の旧鍵を用いてセキュリティ通信が継続する。通知の送受信に新鍵を用いた認証を付与しない構成とする場合は、鍵変更タイミング通知２で通知される鍵変更のタイミングまでに新鍵が準備できればよい。
　受信機は、鍵変更の指令を受信し、切り替え後の新鍵が準備できたとき、鍵準備完了通知１を送信する。受信機は、新鍵を使用可能になるタイミングで鍵準備完了通知１を送信してもよいし、送信機が新鍵を使用可能になるタイミングのずれを考慮して、受信機が新鍵を使用可能になるタイミングの後の所定の時間後に送信してもよい。また、鍵準備完了通知１を送信するタイミングで、送信機が新鍵を使用可能な状態になっていない場合を考慮して、鍵準備完了通知１を定期的に送信してもよい。送信機から鍵変更タイミング通知２を受信するまでに、鍵準備完了通知１を送信すれば十分である。
　送信機は、受信機から鍵準備完了通知１を受信した後、鍵変更タイミング通知２を送信する。
　本実施例では、フレッシュネス値の値を用いて使用する鍵の切り替えタイミングを特定する。鍵変更タイミング通知２に、鍵変更タイミング３とするフレッシュネス値の情報を含める。通知する鍵変更タイミング３は、通知送信直後のタイミングとしてもよいが、送信処理や受信処理の順番入れ替わりによって、受信機が鍵変更タイミング通知２を受信処理する前に新鍵を用いたセキュリティ通信フレームを受信処理してしまう恐れがあるため、通知の送信タイミングより未来のタイミングとすることが望ましい。
　受信機は、鍵変更タイミング通知２に含まれる切り替えタイミングのフレッシュネス値を取得した場合、以降の受信処理時にフレッシュネス値が当該切り替えタイミング値未満の場合は旧鍵を用いて認証処理を行い、当該切り替えタイミング値以降の場合は新鍵を用いて認証処理を行う（Ｓ３０３～Ｓ３０５）。
　ここで、各通知には新鍵を用いてハッシュ値を計算した結果を付与してもよい。例えば、フレッシュネス値や特定のデータ列や送信する通知のペイロードを用いて計算したハッシュ値を通知に付与するとよい。送信機と受信機が、互いに知りえる情報と鍵を用いてハッシュ値を計算してもよい。このようにすることで、同じ新鍵に変更される場合のみ処理を継続することができ、例えば、送信機と受信機で切り替え先の新鍵の値が、エラーなどが原因で異なる場合、異なる新鍵を使用した通信の開始を抑制できる。各通知において認証に失敗した場合は、エラー処理を実行してもよい。例えば、鍵不一致を知らせる通知を送信したり、エラーを記録してもよい。
　鍵準備完了通知１を旧鍵又は認証不要な状態で送信してもよい。鍵準備完了通知１を旧鍵や認証不要状態で送信する構成では、新鍵を準備できていない送信機で鍵変更処理が開始していることをネットワーク上で検知できる。
　図５は、本実施例の動作例のタイミングチャートであり、鍵０、鍵１、鍵２へ順に切り替えた場合の動作例を示す。
　鍵０から鍵１への変更時は、鍵０が旧鍵、鍵１が新鍵となり、送信機の鍵準備が完了した後、受信機の鍵準備が完了する場合の動作例を示す。鍵１から鍵２への変更時は、鍵１が旧鍵、鍵２が新鍵となる。また、受信機の鍵準備が完了した後、送信機の鍵準備が完了する場合の動作例を示す。
　鍵０を使用中において、鍵を０から１に変更する鍵変更指令がされたとき（ｔ１５）、先に送信機で鍵の準備ができた（ｔ１６）。送信機は、受信機の鍵準備完了（ｔ２１）後に送信される鍵準備完了通知１を待つ（ｔ２２）。送信機は、鍵準備完了通知１を受信（ｔ２２）後に鍵変更タイミング通知２を送信する（ｔ２４）。鍵変更タイミング通知２は鍵変更タイミング３の情報を含む。送信機及び受信機は、鍵変更タイミング３に到達したとき（ｔ２９）、送信時に使用する鍵を０から１に変更する。受信機は、鍵変更タイミング３（ｔ２９）以降に受信したセキュリティ通信フレームは鍵１で認証し、鍵変更タイミング３以前（ｔ２８まで）に受信したセキュリティ通信フレームは鍵０で認証する。フレッシュネス値をタイミング特定に使用する場合、時間ｔはフレッシュネス値であり、受信機側で処理の順番が入れ替わっても、フレッシュネス値で使用する鍵が管理される。
　次に、鍵１から鍵２に変更する鍵変更指令がされたとき（ｔ３３）、受信機が先に鍵の準備ができた（ｔ３４）。受信機は鍵準備完了通知１を送信する（ｔ３５）。送信機は鍵の準備ができていない間（ｔ３４からｔ３８まで）、鍵準備完了通知１を無視する（ｔ３５、ｔ３７）。送信機は鍵準備ができた（ｔ３８）後に、鍵準備完了通知１を受信したとき（ｔ３９）、鍵変更タイミング通知２を送信する（ｔ４０）。鍵変更タイミング通知２は鍵変更タイミング３の情報を含む。受信機は、鍵変更タイミング通知２を受信後、鍵準備完了通知１の送信を停止してもよい。送信機及び受信機は、鍵０から鍵１に変更した場合と同様に、鍵変更タイミング３で使用する鍵を切り替える。
　図６は、フレッシュネス値を用いないで所定期間の決定する第２の方法を採用した場合の動作例のタイミングチャートである。
　図５との処理の主な違いは、送信機は、新鍵１の準備が完了してから（ｔ１６）、所定の時間１ａ（ｔ１６からｔ２４）の間は鍵０を用いてセキュリティ通信フレームを送信する。受信機は、鍵準備完了後（ｔ１９）から鍵０での認証に失敗し鍵１での認証に成功する（ｔ２４）まで、鍵０で認証処理を行う。また、受信機は、鍵１での認証成功後（ｔ２４）後も、所定の時間だけ鍵０での認証も実施する（図４参照）。
　受信機の鍵準備が先に完了する鍵１から鍵２への切り替え時も同様に、受信機は鍵準備完了後（ｔ３４）、鍵１で認証失敗し、鍵２で認証成功するまで（ｔ４６）、鍵１での認証処理を継続し、鍵２での認証成功後（ｔ４６）所定の時間（ｔ４７）まで鍵１での認証も実施する。
　通信機が相互に通信をする場合、前述した送信機と受信機の機能及び処理を各通信機に持たせるとよい。例えば、通信機１と通信機２が通信するとき、通信機１は通信機２に対する受信機の機能と送信機の機能を有し、通信機２は通信機１に対する受信機の機能と送信機の機能を有する。通信機１から通信機２へのセキュリティ通信と通信機２から通信機１へのセキュリティ通信の処理は独立して実施される。例えば、通信機１から通信機２へのセキュリティ通信に関する共通鍵の変更時に通信機２から通信機１へのセキュリティ通信に関する共通鍵を変更しなくてもよい。すなわち、通信経路各々でセキュリティ通信の処理は独立していると考えてもよい。このような場合、本発明の処理を各通信経路に適用すればよい。本発明の処理は通信経路ごとに独立して実施されるとよい。フレッシュネス値、鍵、鍵変更タイミング３などの通信制御情報は通信経路ごとに管理される。複数の通信経路で同時に鍵が変更される場合などは、各通信経路で新鍵と旧鍵を共用してもよい。また、送信経路と受信経路において、同じ共通鍵を用いてもよい。
　さらに、複数の受信機を設けてもよい。この場合、図１のステップＳ１０２において、全ての受信機からの鍵準備完了通知１を受信したときＹＥＳと判定される。
　さらに、複数の送信機を設けてもよい。この場合、送信元ごとに独立して受信処理を実行するとよい。フレッシュネス値、鍵、鍵変更タイミング３などの通信制御情報は送信元ごとに管理される。複数の通信経路で同時に鍵が変更される場合、各通信経路で新鍵と旧鍵を共用してもよい。この場合、受信機の所定の期間２は、すべての送信機について、鍵変更タイミング通知２を受信して鍵変更タイミング３を経過した、又は新鍵での認証に成功したタイミング以降であって、任意の期間経過後（例えば、旧鍵での受信をしえないタイミング以降）に、旧鍵をロック又は削除するとよい。また、全ての送信機において、同時に鍵が変更される場合、少なくとも一部の送信機から鍵変更タイミング通知２を受信できなかった場合、エラーとして扱い、エラー時処理を実行してもよい。
　フレッシュネス値を用いる場合、フレッシュネス値の代わりに送信毎に増加するカウント値を用いてもよく、このカウント値は所定の範囲内で繰り返す値にしてもよい。受信機は、鍵変更タイミング通知２を受信した後、鍵変更タイミング３までの期間での、送信の前後関係が分かればよい。例えば、０から１００の値を採用した場合、現在の値からマイナス３０のカウントに相当する値は過去の値としてよい。ここで、現在の値が２０の場合、３０を減じると－１０となり、０～１００の範囲内に修正すると９０となる。このとき、２０から８９は将来の値で、９０から１００と０から１９は過去の値として扱うとよい。３０以上の受信処理の入れ替わりは発生しないとすると、順番が入れ替わって受信しうるカウント値、例えば９１は過去の値であると判定できる。カウント値が２０の場合、鍵変更タイミングを８９など将来の値に設定することで、受信機は鍵変更タイミング通知２を受信してからカウント値８９を最初に通過するタイミングで、使用する鍵を切り替えればよい。
　認証処理時に、フレッシュネス値を原因とした認証失敗が発生する場合（図３のＳ３１０など）、失敗の要因に応じて、鍵変更処理における認証結果の扱いを変更してもよい。
　ネットワーク上の通信機が、鍵を管理する鍵管理通信機に鍵変更を要求して、鍵変更要求を受けた鍵管理通信機が鍵変更処理を開始してもよい。このように構成することで、ネットワーク上のいずれの通信機でも鍵変更要求が可能となり、特定の一つの通信機が鍵変更タイミングや鍵の値を管理することで、鍵変更要求が重なったときに発生しうる、使用鍵に違いが生じることを防止できる。また、各通信機がセキュリティリスクを検知して、鍵変更を要求することができるので、セキュリティリスクを検知するための負荷を分散できる。
　本発明は、なりすまし防止のための通信の他、暗号通信に用いる鍵の変更に関しても利用できる。第１の方法を適用する場合、暗号通信の送信順序が分かるシーケンス番号が付与されることで、使用鍵の変更タイミングを特定できる。シーケンス番号のみを平文で送信してもよく、復号成功を判定可能であれば、シーケンス番号を暗号文に含めてもよい。また、鍵準備完了通知１や鍵変更タイミング通知２は旧鍵を用いて暗号化してもよい。鍵の変更処理中において、少なくともシーケンス番号のみを旧鍵で暗号化してもよい。こうすることで、新鍵と旧鍵の入り混じる状況においても一意にシーケンス番号を特定することができる。復号成否を判定可能な場合は新鍵を用いてもよい。鍵準備完了通知１は旧鍵で暗号化して、鍵変更タイミング通知２は新鍵で暗号化してもよい。暗号化の代わりに、暗号復号用の鍵を用いたハッシュ値を付与してもよい。
　以上に説明したセキュリティ通信の鍵を変更とする技術は、タイミングを問わずに鍵を変更するアプリケーションにも適用できる。例えば、車両走行中のセキュリティ通信の利用中にセキュリティ通信に干渉を検知した場合に、直ちに鍵を変更でき、セキュリティリスク耐性を向上できる。すなわち、データの送信タイミングを表す値（例えばフレッシュネス値）が同じ通信のハッシュ値が正しい場合に、鍵を変更するとよい。
　例えば、フレッシュネス値が同じで、異なる内容の通信のハッシュ値が正しい値のデータを受信した場合、意図した通信相手と意図しない通信相手からのセキュリティ通信の信号を受信した可能性があり、セキュリティ通信用の鍵が流出した可能性がある。このとき、予め用意していた別の新鍵に変更すれば、新鍵を知らない意図しない通信相手は通信を継続できず、以降の通信のセキュリティを確保できる。
　鍵の流出と判定できる一つの例は、受信したフレッシュネス値とハッシュ値の少なくとも一部を受信履歴として記録し、受信したメッセージについて、ハッシュ値が正しく、同じフレッシュネス値が受信履歴に存在して、かつハッシュ値が異なる場合、鍵が流出したと判断することができる。ここで、ハッシュ値が同じ場合は再送攻撃がされたと判定してもよい。異なるメッセージに対して、同じハッシュ値が算出される可能性は低い為、ハッシュ値が異なる場合は流出した鍵による通信が実施されたと判定できる。また、ハッシュ値の少なくとも一部を記録することで、全ての受信メッセージを記録して比較する場合に比べて、メモリの節約が可能となる。ハッシュ値の一部を記録する場合は、受信したハッシュ値を同様の方法で一部を取り出すとよい。
　以後、別な図を使用して本発明の実施例の鍵変更のタイミングを説明する。
　図８は、本実施例の鍵変更のタイミングを示す図である。
　図８に示すように、鍵が変更され、鍵変更タイミング通知が送信されると、鍵変更後の所定期間１だけ送信機は旧鍵での送信を継続する。受信機は所定期間２だけ旧鍵で受信メッセージを認証する。なお、新鍵は変更の都度受け取っても、予め受け取っておいてもよい。このようにすると、ネットワーク上の送信機と受信機との間で鍵が不一致の期間も、旧鍵と新鍵との混在を許容し、セキュリティ通信を継続できる。
　図９は、本実施例の鍵変更のタイミングを示す図である。
　図９に示すように、鍵が変更され、鍵変更タイミング通知が送信されると、受信機が新鍵を利用可能になるまでの所定期間１だけ送信機は旧鍵での送信を継続する。送信機は鍵変更タイミングをその変更前に受信機に通知する。受信機は、新鍵が利用可能になった後も、鍵変更タイミングのずれを考慮して、所定期間２だけ旧鍵での認証を許容する。すなわち、一方の鍵での認証に失敗した場合、他方の鍵で認証を試みる。
　以上に説明したように、本発明の実施例の通信システムでは、送信機は、変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信し、受信機は、新鍵が使用可能になった後の第２の所定の期間において旧鍵で受信時の認証処理を行い、前記送信機から前記鍵変更タイミングに関する通知を受信した場合、前記鍵変更タイミングより前に送信されたデータは旧鍵で認証処理を行い、前記鍵変更タイミングより後に送信されたデータは新鍵で認証処理を行うので、鍵変更に伴うセキュリティ通信の失敗の軽減できる。また、鍵変更中においても、通常時のようにセキュリティ通信を継続できるので、任意のタイミングで鍵を変更できる。暗号の復号成否で鍵が正しいかを判定することで、様々なセキュリティ通信に適用できる。
　また、受信機は、第２の所定の期間において旧鍵を用いた認証に失敗した場合、前記新鍵で認証処理を行うことで、通知を受信しなくても正しい鍵に切り替えできる。
　また、受信機は、新鍵で認証が可能となった場合に鍵準備完了通知を送信機に送信し、第１の所定の期間は、鍵準備完了通知を受信するまでの期間とすることで、通知を用いて正しい鍵に確実に切り替えできる。
　また、受信機は、新鍵で認証が可能となった場合に鍵準備完了通知を送信し、第１の所定の期間は、鍵準備完了通知を受信し、さらに所定の期間経過する又は所定の条件を満たすまでの期間とすることで、受信機の鍵変更の準備期間を考慮して正しい鍵に確実に切り替えできる。
　また、送信機は、第１の所定の期間が終了するタイミングを、鍵変更タイミング通知によって、受信機に通知することで、送信機と受信機の間で鍵変更タイミングを確実に整合できる。
　また、第２の所定の期間は、鍵変更タイミング通知に含まれる鍵変更タイミングまでの期間とすることで、送信機と受信機の間で鍵変更タイミングを確実に整合できる。
　また、第１の所定の期間及び第２の所定の期間は、セキュリティ通信に用いるフレッシュネス値によって特定されるので、データの到着順序が入れ替わってもセキュリティ通信を継続できる。また、既存のフレッシュネス値を使用するので、鍵を管理するために別にカウンタを設ける必要がない。
　なお、本発明は前述した実施例に限定されるものではなく、添付した特許請求の範囲の趣旨内における様々な変形例及び同等の構成が含まれる。例えば、前述した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに本発明は限定されない。また、ある実施例の構成の一部を他の実施例の構成に置き換えてもよい。また、ある実施例の構成に他の実施例の構成を加えてもよい。また、各実施例の構成の一部について、他の構成の追加・削除・置換をしてもよい。
　また、前述した各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等により、ハードウェアで実現してもよく、プロセッサがそれぞれの機能を実現するプログラムを解釈し実行することにより、ソフトウェアで実現してもよい。
　各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Solid State Drive）等の記憶装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
　また、制御線や情報線は説明上必要と考えられるものを示しており、実装上必要な全ての制御線や情報線を示しているとは限らない。実際には、ほとんど全ての構成が相互に接続されていると考えてよい。

Claims (13)

  1. 　送信機と受信機の間で鍵を用いてセキュリティ通信を行う通信システムであって、
    　前記鍵を前記セキュリティ通信中に変更可能であって、
    　前記送信機は、
    　変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、
    　前記新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信し、
    　前記受信機は、
    　前記新鍵が使用可能になった後の第２の所定の期間において前記旧鍵で受信時の認証処理を行い、
    　前記送信機から前記鍵変更タイミングに関する通知を受信した場合、鍵変更タイミングより前に送信されたデータは前記旧鍵で認証処理を行い、前記鍵変更タイミングより後に送信されたデータは前記新鍵で認証処理を行うことを特徴とする通信システム。
  2. 　請求項１に記載の通信システムであって、
    　前記受信機は、前記第２の所定の期間において前記旧鍵を用いた認証に失敗した場合、前記新鍵で認証処理を行うことを特徴とする通信システム。
  3. 　請求項１に記載の通信システムであって、
    　前記第２の所定の期間は、前記旧鍵で認証に失敗し、前記新鍵で認証に成功するまでの期間であることを特徴とする通信システム。
  4. 　請求項１に記載の通信システムであって、
    　前記第２の所定の期間は、前記旧鍵で認証に失敗し、前記新鍵で認証に成功した後、さらに所定の期間が経過する又は所定の条件を満たすまでの期間であることを特徴とする通信システム。
  5. 　請求項１に記載の通信システムであって、
    　前記第１の所定の期間は、前記受信機が前記新鍵で認証が可能となるまでの期間であることを特徴とする通信システム。
  6. 　請求項１に記載の通信システムであって、
    　前記受信機は、前記新鍵で認証が可能となった場合に鍵準備完了通知を前記送信機に送信し、
    　前記第１の所定の期間は、前記鍵準備完了通知を受信するまでの期間であることを特徴とする通信システム。
  7. 　請求項１に記載の通信システムであって、
    　前記受信機は、前記新鍵で認証が可能となった場合に鍵準備完了通知を送信し、
    　前記第１の所定の期間は、前記鍵準備完了通知を受信し、さらに所定の期間経過する又は所定の条件を満たすまでの期間であることを特徴とする通信システム。
  8. 　請求項１に記載の通信システムであって、
    　前記送信機は、前記第１の所定の期間が終了するタイミングを、鍵変更タイミング通知によって、前記受信機に通知することを特徴とする通信システム。
  9. 　請求項８に記載の通信システムであって、
    　前記第２の所定の期間は、前記鍵変更タイミングに関する通知に含まれる鍵変更タイミングまでの期間であることを特徴とする通信システム。
  10. 　請求項１に記載の通信システムであって、
    　前記第１の所定の期間は、前記セキュリティ通信に用いるフレッシュネス値によって特定されることを特徴とする通信システム。
  11. 　請求項１に記載の通信システムであって、
    　前記第２の所定の期間は、前記セキュリティ通信に用いるフレッシュネス値によって特定されることを特徴とする通信システム。
  12. 　鍵を用いて受信機とセキュリティ通信を行う送信機であって、
    　前記鍵が前記セキュリティ通信中に変更される場合、変更後の新鍵が使用可能になると、鍵変更タイミングに関する通知を送信し、前記新鍵が使用可能になった後の第１の所定の期間において変更前の旧鍵でデータを送信することを特徴とする送信機。
  13. 　鍵を用いて送信機とセキュリティ通信を行う受信機であって、
    　前記鍵が前記セキュリティ通信中に変更される場合、変更後の新鍵が使用可能になった後の第２の所定の期間において変更前の旧鍵で受信時の認証処理を行い、
    　前記送信機から鍵変更タイミングに関する通知を受信した場合、鍵変更タイミングより前に送信されたデータは前記旧鍵で認証処理を行い、前記鍵変更タイミングより後に送信されたデータは前記新鍵で認証処理を行うことを特徴とする受信機。
PCT/JP2022/014982 2022-03-28 2022-03-28 通信システム、送信機、及び受信機 WO2023187896A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/014982 WO2023187896A1 (ja) 2022-03-28 2022-03-28 通信システム、送信機、及び受信機

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/014982 WO2023187896A1 (ja) 2022-03-28 2022-03-28 通信システム、送信機、及び受信機

Publications (1)

Publication Number Publication Date
WO2023187896A1 true WO2023187896A1 (ja) 2023-10-05

Family

ID=88199655

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/014982 WO2023187896A1 (ja) 2022-03-28 2022-03-28 通信システム、送信機、及び受信機

Country Status (1)

Country Link
WO (1) WO2023187896A1 (ja)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006019975A (ja) * 2004-06-30 2006-01-19 Matsushita Electric Ind Co Ltd 暗号パケット通信システム、これに備えられる受信装置、送信装置、及びこれらに適用される暗号パケット通信方法、受信方法、送信方法、受信プログラム、送信プログラム
JP2018182665A (ja) * 2017-04-20 2018-11-15 富士通株式会社 通信装置、通信システム及び暗号化通信制御方法
JP2019140577A (ja) * 2018-02-13 2019-08-22 株式会社デンソー 電子制御装置及び通信システム
JP2022012202A (ja) * 2020-07-01 2022-01-17 Ｎｅｃプラットフォームズ株式会社 第１の通信装置、第２の通信装置、システム、方法、及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006019975A (ja) * 2004-06-30 2006-01-19 Matsushita Electric Ind Co Ltd 暗号パケット通信システム、これに備えられる受信装置、送信装置、及びこれらに適用される暗号パケット通信方法、受信方法、送信方法、受信プログラム、送信プログラム
JP2018182665A (ja) * 2017-04-20 2018-11-15 富士通株式会社 通信装置、通信システム及び暗号化通信制御方法
JP2019140577A (ja) * 2018-02-13 2019-08-22 株式会社デンソー 電子制御装置及び通信システム
JP2022012202A (ja) * 2020-07-01 2022-01-17 Ｎｅｃプラットフォームズ株式会社 第１の通信装置、第２の通信装置、システム、方法、及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BABA, TATSUYA: "Mastering IPsec, 2nd edition", 18 August 2006, O'REILLY JAPAN, INC., JP, ISBN: 4-87311-295-8, article BABA, TATSUYA: "Passages; Mastering IPsec", pages: 140 - 197, XP009549953 *

Similar Documents

Publication Publication Date Title
EP3447971A1 (en) Update control apparatus, software update system and update control method
US10812261B2 (en) Vehicle system and key distribution method
CN109218263B (zh) 一种控制方法及装置
JP6663032B2 (ja) 車載ゲートウェイ、鍵管理装置
CN102413224B (zh) 绑定、运行安全数码卡的方法、系统及设备
KR102450811B1 (ko) 차량 내부 네트워크의 키 관리 시스템
EP3565212B1 (en) Method for providing an authenticated update in a distributed network
EP3247080B1 (en) Certificate management method, device and system
US20190026478A1 (en) Vehicle secure communication method and apparatus, vehicle multimedia system, and vehicle
US10862675B2 (en) Method for exchanging messages between security-relevant devices
CN111444496A (zh) 应用控制方法、装置、设备以及存储介质
JP2021090151A (ja) ストレージシステムおよびストレージシステムのデータ保護方法
US11537717B2 (en) Information processing apparatus
WO2023187896A1 (ja) 通信システム、送信機、及び受信機
US11218309B2 (en) Vehicle communication system and vehicle communication method
CN116235467A (zh) 一种关联控制方法及相关装置
CN114980083A (zh) 一种基于自适应应用的安全通信方法以及服务端
US20210014059A1 (en) Control method, apparatus and system
CN110166452B (zh) 一种基于JavaCard共享接口的访问控制方法及系统
CN113343203A (zh) 数字车钥匙处理方法、设备及平台系统
CN113438242A (zh) 服务鉴权方法、装置与存储介质
JP2023519910A (ja) 特に自動車におけるデータの異常を処理するための方法
CN107493262B (zh) 用于传输数据的方法和装置
CN114844674B (zh) 动态授权方法、系统、电子设备及存储介质
CN111190631B (zh) 智能卡及其cos后更新安全的方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22935050

Country of ref document: EP

Kind code of ref document: A1