JP2012227672A - Inter-vehicle/road-to-vehicle communication system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To solve a problem that a common key cannot be obtained in a place where a road side machine does not exist, so that secure inter-vehicle communication is impossible, in a secure inter-vehicle/road-to-vehicle communication system which assures the confidentiality or integrity of a message or both of them by using the common key.SOLUTION: An road side machine which exists in an area and an on-vehicle machine are communicated with each other by using the same common key. The road side machine obtains the common key of the area to which the road side machine belongs and a neighboring area, from a key management server, and distributes that to the on-vehicle machine which can be communicated. The on-vehicle machine has obtained the common key of the neighboring area in advance, so that, can carry out secure inter-vehicle communication even if communication with the road side machine is impossible when moving forward to the next area. By using two kinds of the common keys which are a previous key having a distribution period of the common key longer than a valid period, and an original key having the generally same distribution period as the valid period, depending on a situation, even if the update of the common key occurs when the communication with the road side machine is impossible, the on-vehicle machine can create a secure message.

Description

  The subject matter disclosed herein relates to a vehicle / road-to-vehicle communication system and apparatus using a common key cryptosystem.

  In recent years, investigation of vehicle-to-vehicle / road-vehicle communication for the purpose of preventive safety has been promoted with the aim of reducing the number of traffic fatalities. Services related to preventive safety often send danger information or information necessary to create danger information to the surroundings as a message, and therefore often perform broadcast or geocast instead of unicast. For services related to preventive safety, the content of the message affects the driving of the car, so a single erroneous message can lead to a major accident. Therefore, it is ensured that the message is sent by the correct device (roadside machine or in-vehicle device) and that the message sent by the correct device has not been tampered with by a malicious person, that is, the integrity of the message is guaranteed. It is important to.

  In general, encryption is used as a method for guaranteeing the integrity of a message. There are two types of encryption: public key encryption in which the message sender / receiver performs encryption / decryption using different keys, and common key encryption in which the message sender / receiver performs encryption / decryption using the same key. A key used in public key cryptography is a pair of a secret key and a public key, and the secret key must not be disclosed to a third party, but the public key may be disclosed to a third party. On the other hand, the key used for common key encryption must not be disclosed to anyone other than the message sender / receiver.

  The following non-patent documents are available as a mechanism for guaranteeing message integrity in vehicle-to-vehicle / road-vehicle communication.

IEEE Standards 1609.2, IEEE Trial-Use Standard for Wireless Access in Vehicular Environments-Security Services for Applications and Management Messages, July, 2006

JP 2008-228051 A

  Non-Patent Document 1 uses public key cryptography to guarantee message integrity. Each device has its own public / private key pair. The message transmission device generates a message signature using the secret key, and transmits the signature and the public key together with the message. The message receiving device verifies the signature using the received public key. Since the key for verifying the signature can be made public, there is no problem even if the public key is distributed together with the message and signature. However, since public key cryptography generally takes a long time, Not suitable for communications that require real-time performance. However, when using common key cryptography, a mechanism for securely sharing keys between message transmitting and receiving devices is required. Patent Document 1 discloses a mechanism for sharing a common key in road-to-vehicle communication.

  In Patent Document 1, each time an in-vehicle device enters an area where it can communicate with a roadside device, the position information of the in-vehicle device is stored in the in-vehicle device and also transmitted to the server via the roadside device. The server stores the received position information of the in-vehicle device. When the server and the vehicle-mounted device communicate with each other, the vehicle-mounted device and the server each generate a key from the accumulated position information, and perform encrypted communication using the generated key.

  When the above method is applied to vehicle-to-vehicle communication, each time the in-vehicle device enters an area where communication with the roadside device is possible, the in-vehicle device itself transmits position information of the in-vehicle device to the in-vehicle device of the communication partner via the server. The server transmits the position information to the in-vehicle device of the communication partner via the roadside device. At this time, since the in-vehicle device of the communication partner does not always exist in an area where communication with the roadside device is possible, the same is performed between the in-vehicle devices communicating with each other. It is difficult to share location information.

  Also, when broadcasting or geocasting a message, it is necessary for multiple in-vehicle devices that receive the message to be able to decrypt the message, so that all in-vehicle devices share the same common key or each in-vehicle device that receives the message It is necessary to send an encrypted message using a shared common key.

  When the former is realized by the above method, there is a possibility that there is an in-vehicle device that cannot receive position information, and it is not known when and from which in-vehicle device the message is received. There is also a problem that the memory required for the in-vehicle device increases. Even when the latter is realized by the above method, there may be an in-vehicle device that cannot receive position information, and it is necessary to transmit a message for the number of in-vehicle devices that receive the message, which compresses the network bandwidth. There's a problem.

  In the present specification, in view of such circumstances, a system, an apparatus, and a method for sharing a common key between apparatuses that transmit and receive messages using vehicle / road-to-vehicle communication are disclosed.

  The disclosed vehicle-to-vehicle / road-to-vehicle communication system that manages a common key for guaranteeing the integrity and / or confidentiality of a message flowing through a communication path includes a key management server, a roadside device, and an in-vehicle device. The The key management server manages the area. A common key is shared between the roadside device and the vehicle-mounted device existing in the area divided by the key management server. There are two types of common keys: a key and a prior key, and a period in which each key can be used and a period in which it can be distributed to in-vehicle devices are determined. The original key can be distributed to the in-vehicle device from a little before the original key use start time to a little after the original key use end time. The advance key can be distributed to the vehicle-mounted device long before the use start time of the advance key and slightly after the use end time of the advance key. The key management server generates a common key for each area. A plurality of versions of a common key are generated in advance for each area. Hereinafter, the current version refers to a common key that can be used at that time, and the next version refers to a common key that can be used next to the current version.

  When a roadside device is installed or when a key update occurs, the key management server and the roadside device confirm that each other's devices are correct. Distribute multiple versions of the common key and the current version of the common key in the neighborhood. When the in-vehicle device can communicate with the roadside device, the in-vehicle device and the roadside device confirm that each other's devices are correct, and the roadside device is common to the in-vehicle device in the current version of the area to which the roadside device belongs. Distribute the key, the prior key of the next version of the area to which the roadside machine belongs, and the common key of the current version of the neighboring area.

  The in-vehicle device entered the next area by acquiring the common key for the neighboring area from the roadside device, but even if communication with the roadside device is not possible, the common key for the next area has already been acquired in the previous area. , Enabling vehicle-to-vehicle communication with guaranteed message integrity and / or confidentiality. Also, by acquiring the current version common key and the next version advance key from the roadside device, the common key is updated while the on-vehicle device is stopped, and when the on-vehicle device is started again, the roadside Even if communication with the aircraft is not possible, or even if the common key is updated while communication with the roadside device is not possible, the advance key is used to generate a message that guarantees integrity and / or confidentiality. Can do.

  In addition, when the in-vehicle device obtains the common key from the roadside device, the information that can be used by the in-vehicle device reduces the memory size required for the in-vehicle device and / or the message that guarantees the integrity and / or confidentiality of the message. The transmission probability can be improved. For example, when the route information to the destination is available, when obtaining the common key of the neighboring area from the roadside machine, if the common key of the area to which the route to the destination belongs is obtained, It is not necessary to acquire a common key for an area to which no route belongs. When travel history information is available, if a common key for an area with a high probability of traveling next is acquired, a common key for an area with a low probability of traveling next need not be acquired. In this way, by narrowing down the common key for the neighboring area to be acquired, the size of the memory required for the in-vehicle device can be suppressed.

  In addition, if travel history information is available, messages that are guaranteed to be complete and / or confidential by deciding which version of the prior key should be obtained rather than the next version of the prior key. The possibility of sending increases.

  When the in-vehicle device sends a message, if the original version has the original key, use the original key. If the original device does not have the key, use the advance key to obtain the MAC ( Message Authentication Code) generation and encryption. Then, the version of the common key and the key type are transmitted together with the message. When a message is received, MAC verification and decryption of the message are performed based on the common key version and key type.

  According to the above aspect, when a roadside device and an in-vehicle device existing in an area use the same common key to guarantee message integrity and / or confidentiality, the roadside device is common to the area to which the roadside device belongs. Distributing the key and the common key of the neighboring area to the in-vehicle device ensures the integrity and / or confidentiality of the message even if it is not possible to communicate with the roadside device when entering the next area Car-to-vehicle communication can be performed. Also, by preparing two types of common keys, a prior key with a different distribution period and an original key, and always obtaining the next version of the prior key, it is not possible to communicate with the roadside device when the common key is updated The in-vehicle device can also create a message that is guaranteed to be complete and / or confidential. In addition, the in-vehicle device uses the route information and travel history information to the destination held by the in-vehicle device, and selects the common key acquired from the in-vehicle device, so that the memory size required for the in-vehicle device can be reduced. The transmission probability of a message with guaranteed security and / or confidentiality can be improved.

  According to the disclosure, it is possible to realize a vehicle / road-to-vehicle communication system and a device capable of transmitting and receiving a message in which integrity and / or confidentiality are guaranteed.

It is a figure which illustrates the composition of the system of this embodiment. It is a block diagram which illustrates the functional composition of the key management server of this embodiment. It is a figure which illustrates the data structure of the area management table which the key management server of this embodiment memorize | stores. It is a figure which illustrates the data structure of the roadside machine management table which the key management server of this embodiment memorize | stores. It is a figure which illustrates the data structure of the key information table which the key management server of this embodiment memorize | stores. It is a block diagram which illustrates the functional composition of the roadside machine of this embodiment. It is a figure which illustrates the data structure of the neighborhood area information table which the roadside machine of this embodiment memorize | stores. It is a figure which illustrates the data structure of the key information which the roadside machine of this embodiment memorize | stores. It is a figure which illustrates the data structure of the key information of the neighborhood area which the roadside machine of this embodiment memorize | stores. It is a block diagram which illustrates the functional composition of the in-vehicle machine of this embodiment. It is a figure which illustrates the data structure of the area information table which the vehicle equipment of this embodiment memorize | stores. It is a figure which illustrates the data structure of the key information table which the vehicle equipment of this embodiment memorize | stores. It is a flowchart showing the example of the key management process of the key management server of this embodiment. It is a flowchart showing the example of the key distribution process of the key management server of this embodiment, and a roadside machine. It is a figure which illustrates the data format of the message transmitted to a roadside machine from a key management server at the time of key distribution of this embodiment, or from a roadside machine to a vehicle equipment. It is a flowchart showing the key acquisition process example of the roadside machine of this embodiment. It is a flowchart showing the key acquisition processing example of the vehicle equipment of this embodiment. It is a flowchart showing the process example at the time of the roadside machine and vehicle equipment of this embodiment transmitting a message. It is a figure which illustrates the data format of the message at the time of performing vehicle-to-vehicle / road-vehicle communication of this embodiment. It is a flowchart showing the process example at the time of the roadside machine and vehicle equipment of this embodiment receiving a message.

  Embodiments will be described below.

  FIG. 1 is a diagram illustrating the configuration of a system according to the present embodiment. This embodiment includes a key management server 101, a roadside device 102, and an in-vehicle device 103. The key management server 101 can communicate with the roadside device 102 via a network. The key management server may communicate with other servers such as a server that manages traffic information via a network. The communication means may be wireless communication or wired communication. The roadside device 102 can communicate with the key management server 101 via a network, and performs wireless communication with the in-vehicle device 103 capable of communication.

  The roadside machine may be installed outdoors or indoors, or may be mounted on a device such as a traffic light or a fueling station. In FIG. 1, the communicable ranges of the roadside devices 102 do not overlap, but may overlap. The in-vehicle device 103 performs wireless communication with the roadside device 102 and the in-vehicle device 103. The in-vehicle device 103 may be mounted on a device other than the vehicle.

  FIG. 2 is a block diagram showing a functional configuration of the key management server 101 of the present embodiment. The function of the key management server 101 described below can be realized by executing a program stored in the storage device by the CPU in an information processing device including a CPU, a storage device, a communication device, and the like. The program may be stored in advance in a storage device, or may be introduced from a storage medium or another device via a communication medium as necessary. The communication medium refers to the network shown in FIG. 1 or a carrier wave or digital signal that propagates through the network.

  The key management server 101 includes a communication control processing unit 210, an area management processing unit 220, a key generation processing unit 230, a key distribution processing unit 240, an area information storage unit 250, and a security information storage unit 260. The communication control processing unit 210 performs processing for communicating with the roadside device 102 and other servers. The area management processing unit 220 manages areas that share a common key.

  Specifically, when an area is added or an area range is changed, the area management processing unit 220 updates the area management table 251 of the area information storage unit 250. The area management table 251 will be described in the area information storage unit 250 described later. In addition, when a new installation of the roadside device 102, a change of the installation position, removal, or the like occurs, the area management processing unit 220 updates the roadside device management table 252 of the area information storage unit 250.

  The roadside machine management table 252 will be described in the area information storage unit 250 described later. The key generation processing unit 230 generates a common key for each area. The key distribution processing unit 240 distributes the common key generated by the key generation processing unit 230 to the roadside device 102. The area information storage unit 250 stores an area management table 251 and a roadside machine management table 252.

  The area management table 251 is a table for managing an area, and includes an area ID 301, an area range 302, and a neighborhood area 303 as shown in FIG. An area ID 301 is an identifier indicating an area. An area range 302 indicates an area range. In FIG. 3, the latitude / longitude is shown, but it is sufficient that the area is uniquely determined. The neighborhood area 303 indicates an area identifier 301 that exists in the vicinity of the area identifier 301. Areas may overlap each other.

  The roadside machine management table 252 is a table for managing an area where roadside machines are installed, and includes a roadside machine ID 401, installation position information 402, and area ID 403 as shown in FIG. The roadside machine ID 401 is an identifier indicating a roadside machine. The installation position information 402 indicates a place where the roadside machine 102 is installed. In FIG. 4, the latitude / longitude is shown, but the installation position is uniquely determined, and it is only necessary to know which area of the area management table 251 belongs to.

  The area ID 403 is an identifier of the area to which the place where the roadside machine ID 401 is installed belongs, and indicates the value of the area ID 301 in the area management table. When the roadside machine 102 belongs to a plurality of areas, a plurality of areas are described. The security information storage unit 260 stores a key information table 261 and roadside machine / key management server authentication information 262.

  The key information table 261 manages common key information for each area, and includes an area ID 501, type 502, version 503, value 504, validity period 505, and distribution period 506, as shown in FIG. The area ID 501 is an identifier indicating an area, and indicates the same value as the area ID 301 of the area management table shown in FIG. The type 502 is an identifier indicating whether the key is a prior key or an original key. When separating the key used for encryption / decryption from the key used for MAC generation / verification, the key for encryption / decryption, the key for MAC generation / verification, the original key for encryption / decryption, and the key for MAC generation / verification There are essentially four types of keys. The version 503 indicates the version of the common key.

  The value 504 is a common key value. The valid machine period 505 indicates a period during which the value 504 is valid as a common key. The distribution period 506 indicates a period during which the value 504 can be distributed from the roadside device 102 to the in-vehicle device 103. The roadside machine / key management server inter-authentication information 262 is information necessary for the roadside machine 102 and the key management server 101 to confirm that each other's devices are correct when communication with the roadside machine 102 is started. Authentication methods may include passwords, public key certificates, and authentication using a common key.

  FIG. 6 is a block diagram showing a functional configuration of the roadside machine 102 of the present embodiment. The functions of the roadside machine 102 described below can be realized by an information processing apparatus including a CPU, a storage device, a communication device, and the like by the CPU executing a program stored in the storage device. The program may be stored in advance in a storage device, or may be introduced from a storage medium or another device via a communication medium as necessary. The communication medium refers to the network shown in FIG. 1 or a carrier wave or digital signal that propagates through the network.

  The roadside device 102 includes a communication control processing unit 610, a key acquisition processing unit 620, a key distribution processing unit 630, a MAC generation / verification processing unit 640, an encryption / decryption processing unit 650, an area information storage unit 660, and a security information storage unit 670. Consists of. The communication control processing unit 610 performs processing for communicating with the key management server 101 and the in-vehicle device 102. The key acquisition processing unit 620 performs processing for acquiring a common key from the key management server 101.

  The key distribution processing unit 630 performs processing for distributing the common key to the in-vehicle device 103. The MAC generation / verification processing unit 640 performs MAC generation of a message to be transmitted and MAC verification of a received message using a common key. The encryption / decryption processing unit 650 encrypts the message to be transmitted and decrypts the received message using the common key. The area information storage unit 660 stores installation position information 661, area ID 662, area range 663, and neighborhood area information table 664.

  The installation position information 661 indicates the place where the roadside machine 102 is installed, and is the same as the installation position information 402 of the roadside machine management table 252 of the key management server 101. The area ID 662 is an identifier of an area to which the place where the roadside device 102 is installed belongs, and is the same as the area ID 301 of the area management table 251 of the key management server 101. The area range 663 indicates the range of the area to which the roadside device 102 belongs, and is the same as the area range 302 of the area management table 251 of the key management server 101.

  The neighborhood area information table 664 is a table in which information on the neighborhood area of the area to which the roadside machine 102 belongs is registered, and includes a neighborhood area ID 701 and an area range 702 as shown in FIG. The neighborhood area ID 701 is an identifier of the neighborhood area of the area to which the roadside device 102 belongs. The area range 702 is an area range of the neighborhood area ID 701. The neighborhood area information table 664 may be distributed from the key management server 101, or may be set using other means. In addition, when there are a large number of roadside devices 102 in the area ID 301, if the roadside device 102 installed at a position close to the neighborhood area stores the neighborhood area information table 664, the roadside installed at a location far from the neighborhood area The machine 102 may not store the neighborhood area information table 664.

  The security information storage unit 670 stores a roadside machine ID 671, roadside machine / key management server authentication information 672, in-vehicle machine / roadside machine authentication information 673, key information 674, and a neighborhood area key information table 675. The roadside machine ID 671 is an identifier indicating a roadside machine. The roadside machine / key management server-to-key management server authentication information 672 is information necessary for confirming that each device is correct when the key management server 101 distributes the key to the roadside machine 102. The in-vehicle device / roadside device authentication information 673 is information necessary for confirming that each device is correct when the roadside device 102 distributes the common key to the in-vehicle device 103. As an authentication method, authentication using a password, a public key certificate, a common key, or the like can be considered.

  The key information 674 is key information of an area to which the roadside device 102 belongs, and includes a type 801, a version 802, a value 803, a valid period 804, and a distribution period 805 as shown in FIG. The type 801 indicates whether the common key is a prior key or an original key. When separating the key used for encryption / decryption from the key used for MAC generation / verification, the key for encryption / decryption, the key for MAC generation / verification, the original key for encryption / decryption, and the key for MAC generation / verification There are essentially four types of keys. Version 802 indicates the version of the common key. A value 803 is a common key value. The validity period 804 indicates a period during which the common key is valid. A distribution period 805 indicates a period during which the common key can be distributed to the in-vehicle device.

  The neighborhood area key information table 675 includes a neighborhood area ID 901, a type 902, a version 903, a validity period 905, and a distribution period 906, as shown in FIG. The neighborhood area ID 901 is an identifier of the neighborhood area of the area to which the roadside device 102 belongs, and is the same as the neighborhood area ID 701 in the neighborhood area information table 664 of the roadside device 102. The type 902 indicates whether the common key is a prior key or an original key. When separating the key used for encryption / decryption from the key used for MAC generation / verification, the key for encryption / decryption, the key for MAC generation / verification, the original key for encryption / decryption, and the key for MAC generation / verification There are essentially four types of keys.

  Version 903 indicates the version of the common key. How many versions of the common key information in the neighborhood area are stored depends on the key management server 101. A value 904 indicates the value of the common key. The valid period 905 indicates a period during which the use of the common key is valid. A distribution period 906 indicates a period during which the common key can be distributed to the in-vehicle device. When there are a large number of roadside devices 102 in the area ID 301, if the roadside device 102 installed near the neighboring area stores the neighborhood area key information table 675, the roadside device installed far from the neighboring area. 102 may not store the neighborhood area key information table 675.

  FIG. 10 is a block diagram illustrating a functional configuration of the in-vehicle device 103 according to the present embodiment. The functions of the in-vehicle device 103 to be described below can be realized by executing a program stored in the storage device by the CPU in an information processing device including a CPU, a storage device, a communication device, and the like. The program may be stored in advance in a storage device, or may be introduced from a storage medium or another device via a communication medium as necessary. The communication medium refers to the network shown in FIG. 1 or a carrier wave or digital signal that propagates through the network.

  The in-vehicle device 103 includes a communication control processing unit 1010, a key acquisition processing unit 1020, a MAC generation / verification processing unit 1030, an encryption / decryption processing unit 1040, a position detection processing unit 1050, and a communication control processing unit 1060 with other devices of the vehicle. , An area information storage unit 1070 and a security information storage unit 1080. The communication control processing unit 1010 performs processing for communicating with the roadside device 102 and the vehicle-mounted device 103. The key acquisition processing unit 1020 performs processing for acquiring a common key from the roadside device.

  The MAC generation / verification processing unit 1030 performs MAC generation of a message to be transmitted and MAC verification of a received message using the common key acquired from the roadside device 102. The encryption / decryption processing unit 1040 uses the common key acquired from the roadside device 102 to encrypt the message to be transmitted and decrypt the received message. The position detection processing unit 1050 acquires current position information of the in-vehicle device 103. The position information may be any information that indicates which area ID the in-vehicle device 103 exists in. A communication control processing unit 1060 with another device of the vehicle performs processing for communicating with another device such as a car navigation in a vehicle on which the vehicle-mounted device is mounted. The area information storage unit 1070 stores an area information table 1071.

  The area information table 1071 includes an area ID 1101 and an area range 1102 as shown in FIG. The area ID 1101 indicates an identifier of an area where the in-vehicle device 103 exists and a neighboring area. An area range 1102 indicates the area range of the area ID 1101. The area information table 1071 may be set in the in-vehicle device in advance or may be acquired from the key management server 101 via the network. In addition, when acquiring the common key information from the roadside device 102, information on the area to which the roadside device 102 belongs and the neighboring area of the area to which the roadside device 102 belongs is acquired together with the common key information, and is registered in the area information table 1071. Also good. When registering in the area information table 1071, information other than the area to which the roadside 102 belongs and the neighboring area of the area to which the roadside machine 102 belongs is deleted, and the area information table 1071 includes the area where the vehicle-mounted device 103 exists at that time and Information other than information on the neighboring area may not be stored.

  The security information storage unit 1080 stores an in-vehicle device ID 1081, in-vehicle device / roadside device authentication information 1082, and a key information table 1083. The in-vehicle device ID 1081 is an identifier indicating the in-vehicle device. The in-vehicle device / roadside device authentication information 1082 is information for confirming that the devices are correct when the in-vehicle device 103 acquires a common key from the roadside device 102.

  The key information table 1083 is information on the common key of the area where the in-vehicle device 103 exists and the neighboring area. As shown in FIG. 12, the area ID 1201, the type 1202, the version 1203, the value 1204, the validity period 1205, and the distribution period 1206 Composed. The area ID 1201 is an identifier indicating an area where the in-vehicle device 103 exists. The type 1202 is an identifier indicating whether the common key is a prior key or an original key. When separating the key used for encryption / decryption from the key used for MAC generation / verification, the key for encryption / decryption, the key for MAC generation / verification, the original key for encryption / decryption, and the key for MAC generation / verification There are essentially four types of keys. Version 1203 indicates the version of the common key. A value 1204 indicates the value of the common key. The validity period 1205 indicates a time during which the common key can be used. A distribution period 1206 indicates a time during which the common key can be distributed to the in-vehicle device 103.

  FIG. 13 shows a key management mechanism in the key management server 101. In step 1310, the key management server 101 monitors the common key information (area ID, version, type, value, valid period, distribution period) in the key information table 261 and confirms whether it is necessary to transmit the common key information. If necessary, the process proceeds to step 1320. If not, the key information table 261 is monitored again. The transmission of the common key information is required when the effective time of the common key information transmitted to the roadside device 102 or the end time of the distribution period is approaching, or the validity of the common key information of the neighboring area transmitted to the roadside device 102 This is when the end time of the period or distribution period is approaching.

  In step 1320, it is determined whether new common key information needs to be generated or already generated common key information needs to be transmitted. If new common key information needs to be generated, the process proceeds to step 1330; otherwise, the process proceeds to step 1350. In step 1330, the key generation processing unit 230 generates new common key information. In step 1340, the generated common key information is registered in the corresponding part of the key information table 261, and the common key information whose validity period has passed is deleted. The possible common key information is deleted.

  Next, in step 1350, the roadside machine 102 that transmits the common key information is searched using the roadside machine management table 252 and the area management table 251, and the key distribution process in step 1370 is started. The key distribution process will be described later. In step 1360, it is confirmed whether or not the key distribution processing in step 1370 has been completed for all roadside devices that are determined to require transmission of the common key information in step 1350. If not, the key distribution processing in step 1370 is performed. repeat.

  FIG. 14 shows a procedure of key distribution processing from the key management server 101 to the roadside device 102. The key distribution process is performed by the key distribution processing unit 240 of the key management server 101. In step 1410, the key management server performs authentication using the roadside machine 102 that transmits the common key information and the roadside machine / key management server authentication information 262. If the authentication is successful, the key management server transmits the common key that is transmitted in step 1420. Encrypt key information and generate integrity guarantee code. Encryption may be public key encryption or common key encryption. The integrity guarantee code may be a public key signature or a common key MAC. The key used for encryption and the generation of the integrity guarantee code may be shared at the time of authentication or may be set in advance. After the processing in step 1420 is completed, the common key information, integrity guarantee code, and security information encrypted in step 1430 are transmitted to the corresponding roadside device 102 as a common key information message.

  FIG. 15 shows a format example of the common key information message transmitted from the key management server 101 to the roadside device 102 in step 1430. The common key information message includes a message type 1501, security information 1502, the number of common key information 1503, common key information 1504, and an integrity guarantee code 1505. The message type 1501 is an identifier indicating that it is a common key information message. The security information is information necessary for the roadside device 102 to perform message decryption and message integrity guarantee, and the type of security information depends on the means used for encryption and integrity guarantee code. The common key information number 1503 indicates the number of common key information to be transmitted. The common key information 1504 includes an area ID 1506, a type 1507, a version 1508, a value 1509, a validity period 1510, and a distribution period 1511.

  The area ID 1506 is an identifier of an area where the common key can be used. The type 1507 indicates whether the common key is an original key or a prior key. When separating the key used for encryption / decryption from the key used for MAC generation / verification, the key for encryption / decryption, the key for MAC generation / verification, the original key for encryption / decryption, and the key for MAC generation / verification There are essentially four types of keys. Version 1508 indicates the version of the common key. A value 1509 indicates the value of the common key. The validity period 1510 indicates a period during which the common key can be used. A distribution period 1511 indicates a period during which the common key can be distributed to the in-vehicle device 103. The common key information 1504 is encrypted at step 1420. The integrity guarantee code 1505 is a value that guarantees the integrity of the common key information 1504 to the message type 1501 of the common key information message.

  FIG. 16 shows the procedure of the key acquisition process of the roadside device 102. The key acquisition process is performed by the key acquisition processing unit 620 of the roadside device 102. In step 1610, the roadside device 102 authenticates with the key management server 101 using the roadside device / key management server authentication information 672. If the authentication is successful, the flow advances to step 1620, and the key management server 101 sends the common key information. Receive a message.

  In step 1630, the common key information is decrypted and the integrity guarantee code is verified. If the verification of the integrity guarantee code fails, the key acquisition process is terminated (step 1640). As processing when verification of the integrity guarantee code fails, a retransmission request for the common key information may be issued to the key management server 101. If verification of the integrity guarantee code is successful, it is checked in step 1650 whether the decrypted common key information is the common key information of the area to which the roadside device 102 belongs.

  If it is the common key information of the area to which the roadside device 102 belongs, the process proceeds to step 1660; otherwise, the process proceeds to step 1670. In step 1660, the acquired common key information is added to the key information 674. If there is common key information that can be deleted, such as common key information whose validity period has expired, the common key information is deleted, and the process proceeds to step 1670. In step 1670, it is confirmed whether the decrypted common key information is the common key information of the neighboring area. If it is the common key information of the neighboring area, the process proceeds to step 1680. Otherwise, the key acquisition process is terminated. In Step 1680, the acquired common key information is added to the neighborhood area key information table 675. If there is common key information that can be deleted, such as common key information whose validity period has passed, it is deleted, and the key acquisition process is terminated.

  Next, a case where the roadside device 102 performs a key distribution process to the in-vehicle device 103 will be described. The key distribution process is performed by the key distribution processing unit 630 of the roadside device 102. The procedure of the key distribution process is the same as that when the key management server 101 performs the key distribution process to the roadside device 102, and is shown in FIG. The key distribution process starts with a common key acquisition request from the in-vehicle device 103 to the roadside device 102. In step 1410, the roadside device 102 performs authentication using the onboard device 103 and the onboard device / roadside device authentication information 673. If the authentication is successful, in step 1420, the common key information transmitted from the area ID 662, the key information 674 to the vehicle-mounted device 103, and the common key information transmitted from the neighboring area key information table 675 to the vehicle-mounted device 103 are acquired and encrypted. And complete the integrity guarantee code.

  Similar to the key distribution processing from the key management server 101 to the roadside device 102, the encryption may be public key encryption or common key encryption. The integrity guarantee code may be a public key signature or a common key MAC. The key used for encryption and the generation of the integrity guarantee code may be shared at the time of authentication or may be set in advance. After the processing in step 1420 is completed, the common key information, integrity guarantee code, and security information encrypted in step 1430 are transmitted to the corresponding in-vehicle device 103 as a common key information message.

  FIG. 17 shows a procedure for key acquisition processing of the in-vehicle device 103. The key acquisition process is performed by the key acquisition processing unit 1020 of the in-vehicle device 103. In step 1710, the in-vehicle device 103 authenticates with the roadside device 102 using the in-vehicle device / roadside device authentication information 1082. If the authentication is successful, the in-vehicle device 103 proceeds to step 1720 and receives a common key information message from the roadside device 102. To do. At that time, if the route information or the travel history information to the destination is available using the communication control processing unit 1060 with the other device of the vehicle, the route information or the travel history information is transmitted to the roadside device 102, The pre-key version to be acquired or the common key information of the neighboring area may be narrowed down, or the common key information to be stored may be selected from the acquired common key information message.

  In step 1730, the common key information is decrypted and the integrity guarantee code is verified. If the verification of the integrity guarantee code is successful, the process proceeds to step 1750. If the verification is unsuccessful, the key acquisition process is terminated (step 1740). As a process in the case where verification of the integrity guarantee code fails, a retransmission request for the common key information may be issued to the roadside device 102. In step 1750, it is determined whether or not the key information table 1083 needs to be updated. If it is necessary to update, the process proceeds to step 1760. If it is not necessary to update, the common key acquisition process is terminated. In step 1760, the decrypted common key information is registered in the key information table 1083. If there is common key information that can be deleted, such as common key information whose validity period has expired, it is deleted and the key acquisition process is terminated.

  FIG. 18 shows a procedure for transmitting / receiving a message using a common key shared by a roadside device and an in-vehicle device existing in the area. In step 1810, the roadside device or in-vehicle device that transmits the message checks whether or not there is a currently available primary key that is used for message encryption and / or MAC generation. In the case of a roadside machine, the key information 674 is used for confirmation. In the case of the in-vehicle device, after confirming the area ID to which the current position detected by the position detection processing unit 1050 belongs in the area information table 1071, it is confirmed in the key information table 1083 whether the original key of the corresponding area ID exists. If there is a primary key that can be used, the process proceeds to step 1830; otherwise, the process proceeds to step 1820.

  In step 1820, whether or not there is a pre-use key that can be used at present is confirmed with the key information 674 for the roadside device and the key information table 1083 for the vehicle-mounted device. If the advance key exists, the process proceeds to step 1830. If not, the process ends. In step 1830, it is determined whether the message needs to be encrypted. If it is necessary, the process proceeds to Step 1840; otherwise, the process proceeds to Step 1850.

  In step 1840, the message is encrypted using the original key if it is determined in step 1610 that the key is inherently present, and using the prior key if it is determined in step 1620 that the prior key is present. Proceed to 1850. In step 1850, it is confirmed whether or not MAC generation is necessary. If necessary, the process proceeds to step 1860, and if not necessary, the process proceeds to step 1870. In step 1860, the MAC of the message is generated using the original key if it is determined in step 1610 that the key is originally present, and using the preliminary key if it is determined in step 1620 that the pre-key is present. Proceed to 1870 to send the message.

  FIG. 19 shows a format example of the transmission message. The transmission message includes a message type 1901, presence / absence of security processing 1902, area ID 1903, type 1904, version 1905, message 1906, and MAC 1907. A message type 1901 indicates the type of message. The presence or absence of security processing 1902 indicates the presence or absence of encryption or the presence or absence of MAC. The area ID 1903 indicates the area ID of the common key used for message encryption and MAC generation. The type 1904 indicates whether the used common key is an original key or a prior key.

  Version 1905 indicates the version of the common key used. Area ID 1903, type 1904, and version 1905 are information for identifying a common key used for encryption and MAC generation. When the roadside device or in-vehicle device that has received the message tries to perform MAC verification using all the common keys stored in the security information storage unit 670 or the security information storage unit 1080, the area ID 1903, type 1904, version There is no need to send 1905.

  However, the MAC is not generated for the message, but when encryption is performed, it is necessary to transmit the area ID 1093, the type 1904, and the version 1905 as information for identifying the common key used for encryption. The area ID message 1906 is originally a message to be transmitted, and is encrypted when it is determined in step 1930 that encryption is necessary. The MAC 1907 is a code that guarantees the completeness from the message type 1901 to the message 1905, and does not exist when it is determined in step 1850 that the MAC generation is not necessary.

  FIG. 20 shows a procedure when the in-vehicle device or the roadside device receives a message. When a message is received, in step 2010, the presence / absence of security processing 1902 is confirmed. If there is neither message encryption nor MAC, the processing ends. If there is a security process, the in-vehicle device checks the key information table 1083 and the roadside device checks the key information 672 whether there is a corresponding common key from the area ID 1903, type 1904, and version 1905 of the transmission message.

  If the corresponding common key exists, the process proceeds to step 2030, and if it does not exist, the message reception process ends. In step 2030, it is confirmed whether the presence / absence of security processing 1902 is MAC. If there is a MAC, the process proceeds to step 2040. If not, the process proceeds to step 2050. In step 2040, MAC verification is performed using the common key confirmed in step 2020. If the MAC verification is successful, the process proceeds to step 2050, and if not, the message reception process is terminated.

  In step 2050, it is confirmed whether the presence / absence of security processing 1902 is encryption. If encryption is present, the process proceeds to step 2060; otherwise, the message reception process is terminated. In step 2060, the message is decrypted using the common key confirmed in step 2020, and the message reception process is terminated.

  In this embodiment, the key management server 101 has the key generation processing unit 230 and generates the common key information. However, after the roadside device 102 has the key generation processing unit and generates the shared key information, The generated common key information may be transmitted to the key management server 101 and registered in the key information table.

  In addition, the key management server 101 cooperates with other servers to acquire vehicle travel history information and proceeds to the next step from the area to which the roadside device 102 belongs when transmitting common key information of a neighboring area to the roadside device 102. An area with a high probability may be ranked, and the information may be transmitted to the roadside device together with the common key information. And if the onboard equipment 103 acquires the common key of the neighboring area with the high probability of proceeding next, it does not need to acquire the common key of the neighboring area with the low probability of proceeding next.

  101: Key management server, 102: Roadside device, 103: In-vehicle device

Claims (20)

In a vehicle / road / vehicle communication system composed of a key management server, a roadside device, and an in-vehicle device that manages a common key, the key management server manages the area, and the roadside device and the in-vehicle device that exist in a certain area have the same common key. A vehicle-to-vehicle / road-to-vehicle communication system characterized by guaranteeing confidentiality and / or integrity of a message using a shared common key. The vehicle / road-vehicle communication system according to claim 1,
A vehicle-to-vehicle / road-to-vehicle communication system, wherein a key management server generates a common key for each area, and distributes to the roadside machine a common key for the area to which the roadside machine belongs and neighboring areas. The vehicle / road / vehicle communication system according to claim 1 or 2,
When the in-vehicle device can communicate with the roadside device, authentication is performed between the in-vehicle device and the roadside device. If the authentication is successful, the roadside device distributes to the in-vehicle device a common key for the area to which the roadside device belongs and neighboring areas. A vehicle-to-vehicle / road-to-vehicle communication system from a roadside machine. In the vehicle / road-vehicle communication system according to claim 3,
The in-vehicle device sends the route information or travel history information to the destination to the roadside device, and the roadside device selects the common key of the neighboring area to be transmitted to the onboard device from the information received from the onboard device, or the roadside device Vehicle-to-vehicle / road-to-vehicle communication characterized in that a common key for a nearby area is transmitted to the vehicle-mounted device, and the vehicle-mounted device selects a common key for the nearby area stored in the vehicle-mounted device from route information or travel history information to the destination. system. A vehicle / road-vehicle communication system according to any one of claims 1 to 4,
There are two types of common keys, the original key that has almost the same usage period and distribution period, and the pre-key that has a longer distribution period than the usage period, and the roadside device or in-vehicle device uses the original key if it has the original key. A vehicle-to-vehicle / road-vehicle communication system that guarantees the confidentiality and / or integrity of a message using a prior key when the key is not originally provided. The vehicle / road-vehicle communication system according to claim 5,
The key management server generates two types of common keys, original key and advance key for each area, and for each roadside device, the original key and advance key for the area where the roadside device exists, the original key and advance key for the neighboring area A vehicle-to-vehicle / road-to-vehicle communication system characterized by distributing the vehicle. The vehicle / road-vehicle communication system according to claim 5 or 6,
When the in-vehicle device can communicate with the roadside device, authentication is performed between the in-vehicle device and the roadside device. A vehicle-to-vehicle / road-to-vehicle communication system characterized by distributing the original key and advance key of the area. The vehicle / road-vehicle communication system according to claim 7,
The in-vehicle device transmits the travel history information to the roadside device, and the roadside device selects the pre-key version of the area to which the roadside device to be transmitted to the in-vehicle device belongs from the travel history information received from the in-vehicle device, or the in-vehicle device travels A vehicle-to-vehicle / road-to-vehicle communication system characterized in that a version of a prior key that is highly likely to be necessary is determined from history information, and the in-vehicle device requests a version of the prior key that the roadside device transmits to the on-vehicle device. A communication device for use in the vehicle / road / vehicle communication system according to claim 1,
It has a function of storing the common key of the area to which the device belongs and the common key of the neighboring area, and distributing the common key of the area to which the other device belongs and the neighboring area when distributing the common key to the other device. A communication device characterized by the above. The communication device according to claim 9,
It has a function to acquire route information and travel history information from a device that acquires a common key to a destination, select a common key in a neighboring area that is likely to be used by a device that acquires the common key, and distribute it. A communication device. The communication device according to claim 9 or 10, wherein
A communication apparatus having a function of generating a common key for each area. The communication device according to claim 9 or 10, wherein
A communication apparatus having a function of acquiring a common key of an area where the apparatus exists and a neighboring area from an apparatus that distributes the common key. The communication device according to claim 12,
Send the route information and travel history information to the destination to the device that distributes the common key, and do not receive the common key of the neighboring area that is unlikely to be used, and the common key of the neighboring area that is likely to be used without receiving it It has the function of acquiring the common key of all neighboring areas of the area to which the device that receives or distributes the common key belongs and selects the common key of the neighboring area to be stored from the route information to the destination and the travel history information A communication device characterized by the above. The communication device according to any one of claims 9 to 11, which is used for the vehicle / road / vehicle communication system according to claim 5.
As a common key, a function that distributes an original key that has almost the same usage period and distribution period and an advance key that has a longer distribution period than the use period, and a function that generates an original key and an advance key if it has a function to generate a common key. A communication device comprising: The communication device according to claim 14, wherein
A communication device having a function of acquiring travel history information from a device that acquires a common key, selecting a version of a prior key that is likely to be used, and transmitting the selected key. The communication device according to claim 12 or 13,
A communication apparatus having a key acquisition function for acquiring an original key and an advance key of an area where the apparatus exists and an original key and an advance key of a neighboring area from an apparatus that distributes a common key. The communication device according to claim 16, wherein
A communication apparatus having a function of acquiring one or more versions of a prior key from an apparatus that distributes a common key and storing a version of the prior key that is highly likely to be used based on travel history information. The communication device according to claim 14 or 15,
An apparatus comprising the key acquisition function according to claim 16. The communication device according to any one of claims 9 to 18,
A communication apparatus having a function of detecting an area to which the apparatus belongs and performing message encryption and / or MAC generation using a common key of the corresponding area. The communication device according to any one of claims 14 to 19,
If the original key that can be used is stored, the original key is used. If the previous key that can be used is stored but not the original key that can be used, the previous key is used to encrypt the message. A communication device having a function of generating and / or generating a MAC.

Images