JPWO2012153530A1 - OBE - Google Patents

Abstract

The digest holding unit 151c holds the digest of the public key certificate included in the packet signal broadcast from the base station apparatus. The certificate verification unit 151a verifies the public key certificate included in the packet signal. At that time, when receiving a packet signal including a digest of a public key certificate different from the digest of the public key certificate held in the digest holding unit 151c, the certificate verification unit 151a receives the public key included in the packet signal. When the packet signal including the digest of the public key certificate corresponding to the digest of the public key certificate held in the digest holding unit 151c is received after the certificate is verified, the public key certificate included in the packet signal is received. Skip document validation.

Description

  The present invention relates to a communication technique, and more particularly to a terminal device that transmits and receives a signal including predetermined information.

  The form of wireless communication for automobiles is roughly classified into road-to-vehicle communication and vehicle-to-vehicle communication (including road-to-vehicle communication). Both types of communication can be used for preventing collisions at intersections and rear-end collisions due to traffic jams at corners. For example, the current position information is detected in real time by GPS (Global Positioning System) in vehicle-to-vehicle communication, and the position information is exchanged between the vehicle-mounted devices, thereby preventing collision at an intersection. In road-to-vehicle communication, a roadside machine is installed at an intersection or on the roadside, and the driving support information as described above is transmitted from the roadside machine to the vehicle-mounted device.

  Compared with wired communication, wireless communication is easier to intercept by communication and impersonation by third party impersonation. Therefore, countermeasures against them are more important than wireless communication. In order to ensure the confidentiality of the communication content, a method of performing message authentication using an encryption method for communication data is effective. The encryption methods are roughly classified into public key encryption methods and common key encryption methods. The former is higher in security than the latter, but has a large amount of data and a large processing load, resulting in higher implementation costs. That is, both are in a trade-off relationship.

JP 2005-202913 A JP 2007-104310 A JP-A-8-331075

  The present invention has been made in view of such circumstances, and an object thereof is to provide a technique for efficiently ensuring the security of a communication system.

  A terminal device according to an aspect of the present invention includes a receiving unit that receives a plurality of packet signals broadcast from a wireless device, a first verification unit for verifying a certificate that includes a public key included in the packet signal, The information which specifies the certificate contained in the packet signal verified by 1 verification part, and the digest holding | maintenance part holding a public key are provided. When the packet signal including the certificate specified by the information specifying the certificate held in the digest holding unit is received, the first verification unit verifies the certificate including the encryption key included in the packet signal. skip.

  A terminal device according to another aspect of the present invention includes a receiving unit that receives an encrypted packet signal and a decrypting unit that decrypts the packet signal. The packet signal is encrypted by a common key encryption method, and is encrypted by a different operation method between a packet signal broadcast from the base station apparatus and a packet signal broadcast from another terminal apparatus.

  It should be noted that any combination of the above-described constituent elements and a conversion of the expression of the present invention between a method, an apparatus, a system, a recording medium, a computer program, etc. are also effective as an aspect of the present invention.

  According to the present invention, security of a communication system can be efficiently ensured.

It is a figure which shows the structure of the communication system which concerns on Example 1 of this invention. FIGS. 2A to 2D are diagrams showing a superframe format defined in the communication system. FIGS. 3A to 3B are diagrams illustrating the configuration of subframes. FIGS. 4A to 4F are diagrams illustrating frame formats of each layer defined in the communication system. It is a figure which shows the specific example of a RSU packet. When four RSU cores are mounted in a terminal device, it is a figure which shows the process example of each RSU core. It is a figure which shows an example of the data structure of the security frame contained in a RSU packet. It is a figure which shows another example of the data structure of the security frame contained in a RSU packet. 1 is a diagram illustrating a configuration of a base station apparatus according to Embodiment 1. FIG. It is a figure which shows the structure of the terminal device mounted in the vehicle based on Example 1. FIG. It is a figure which shows the structural example 1 of a verification part. It is a flowchart which shows the reception process of the RSU packet of the terminal device in which the verification part which concerns on the structural example 1 is used. It is a figure which shows the structural example 2 of a verification part. It is a flowchart which shows the reception process of the RSU packet of the terminal device in which the verification part which concerns on the structural example 2 is used. It is a flowchart which shows the verification process of the public key certificate of the terminal device in which the verification part which concerns on the structural example 2 is used. It is a flowchart which shows the verification process of the message with an electronic signature of the terminal device in which the verification part which concerns on the structural example 2 is used. It is a figure which shows the modification 1 of the data structure of the security frame contained in a RSU packet. It is a figure which shows the modification 2 of the data structure of the security frame contained in a RSU packet. It is a figure which shows the modification 3 of the data structure of the security frame contained in a RSU packet. 20A to 20C are diagrams showing a fourth modification of the data structure of the security frame included in the RSU packet. FIGS. 21A to 21B are diagrams illustrating a fifth modification of the data structure of the security frame included in the RSU packet. FIGS. 22A to 22C are diagrams illustrating a sixth modification of the data structure of the security frame included in the RSU packet. It is a figure which shows an example of the data structure of a security frame. FIG. 6 is a diagram illustrating a configuration of a base station apparatus according to a second embodiment. It is a figure which shows the structure of the terminal device mounted in the vehicle based on Example 2. FIG. It is a figure for demonstrating the normal message transmission / reception procedure in the road-vehicle communication using the communication system which concerns on Example 2. FIG. It is a figure for demonstrating the update procedure of the road-vehicle master key in the road-vehicle communication using the communication system which concerns on Example 2. FIG. It is a figure which shows an example of the data structure of the security frame contained in the packet produced | generated in road-to-vehicle communication. It is a figure for demonstrating the normal message transmission / reception procedure in the communication between vehicles using the communication system which concerns on Example 2. FIG. It is a figure which shows an example of the data structure of the security frame contained in the packet produced | generated in vehicle-to-vehicle communication. It is a figure which shows the format of a common key table. It is a figure which shows an example of the operation method of a common key table. It is a figure for demonstrating the addition or update of a common key table. It is a figure for demonstrating the addition or update procedure of a common key table in the road-vehicle communication using the communication system which concerns on Example 2. FIG. FIGS. 35A and 35B are diagrams illustrating the common key table held in the terminal device according to the third embodiment (part 1). FIGS. 36A and 36B are diagrams illustrating a common key table held in the terminal device according to the third embodiment (part 2). FIGS. 37A and 37B are diagrams illustrating a state of switching of the common key table according to the third embodiment (part 1). FIGS. 38A and 38B are diagrams illustrating a state of switching the common key table according to the third embodiment (part 2). FIGS. 39A and 39B are diagrams illustrating an emergency update state of the common key table according to the third embodiment. FIGS. 40A and 40B are diagrams illustrating a state of switching after the emergency update of the common key table according to the third embodiment. It is a figure which shows the 1st switching example of the transmission key table which concerns on Example 3. FIG. FIG. 10 is a diagram illustrating a second switching example of the transmission key table according to the third embodiment. It is a figure for demonstrating the addition or update of the common key table which concerns on Example 3. FIG.

Example 1
The knowledge which became the foundation of Example 1 of the present invention is as follows. Since road-to-vehicle communication is more public than vehicle-to-vehicle communication, it is desirable that requests for spoofing and data falsification be greater and that the legitimacy of the sender can be confirmed. In view of this, a system for notifying a packet signal storing data with a public key certificate and an electronic signature from a roadside device (base station device) to a vehicle-mounted device (terminal device) has been studied.

  However, high-speed processing is required to execute verification of public key certificates and electronic signatures included in all packet signals, and it is necessary to install high-speed hardware in the terminal device. Since the public key cryptosystem is used for these verification processes, the amount of calculation increases and the circuit scale increases.

  The first embodiment has been made in view of such a situation, and an object thereof is to provide a technique for reducing processing load when receiving a packet signal while improving security.

  The outline | summary of the one aspect | mode of Example 1 is as follows. A terminal device according to an aspect of the first embodiment includes a receiving unit that receives a plurality of packet signals broadcast from a “wireless device” and a first certificate for verifying a “certificate including a public key” included in the packet signal. A verification unit; information for specifying a certificate included in the packet signal verified by the first verification unit; and a digest storage unit that stores a public key. When the packet signal including the certificate specified by the information specifying the certificate held in the digest holding unit is received, the first verification unit receives the certificate including the public key included in the packet signal. Skip verification. The “wireless device” may be a base station device or a terminal device. The “certificate including a public key” links the validity of a public key issued by a third party such as a certificate authority and the owner of the public key.

  By including the “certificate including the public key” in the packet signal, security can be improved. Further, the processing load can be reduced by appropriately skipping the “certificate including public key” verification process.

  A second verification unit for verifying a signed message included in the packet signal; and the second verification unit for a packet signal including a certificate specified by information specifying a certificate held in the digest holding unit. And a status management unit that holds the verification result in. When the second verification unit verifies the packet signal including the certificate specified by the information specifying the certificate held in the digest holding unit, the second verification unit holds the verification result in the status management unit, and further, the status While the verification unit holds the verification success, verification of the signed message of at least one of the packet signals may be skipped.

  By including a signed message in the packet signal, security can be improved. Further, the processing load can be reduced by appropriately skipping the verification process of the signed message.

  The second verification unit may determine that the signed message is approved when the verification of the signed message of at least one of the packet signals is skipped. According to this, the processing load can be further reduced.

  Of the plurality of packet signals received from one wireless device during the wireless device signal reception period, the certificate may be included in at least the first packet signal of the wireless device signal reception period. Specific information for specifying the certificate may be included in a packet signal that does not include the certificate. The second verification unit, when the verification of the signed message included in the first packet signal among a plurality of packet signals received in one wireless device signal reception period is successful, is a proof specified by the specific information Or verification of a signed message of the received packet signal including the specific information may be skipped. According to this, it is possible to achieve a balance between security improvement and processing load reduction.

  Of a plurality of packet signals received from one radio apparatus during the radio signal reception period, an electronic signature may be included in at least the first packet signal of the radio apparatus signal reception period. The message authentication code may be included in at least a packet signal other than the first packet signal in the wireless device signal reception period. The terminal device includes: a second verification unit for verifying a message with an electronic signature included in a packet signal; a third verification unit for verifying a message with a message authentication code included in a packet signal other than the packet signal; , May be further provided. According to this, it is possible to achieve a balance between security improvement and processing load reduction.

  An outline will be given before specifically explaining the first embodiment of the present invention. Embodiment 1 of the present invention is a road-to-vehicle communication executed to provide information to a terminal device mounted on a vehicle from a base station device installed at an intersection or a roadside, and a terminal device mounted on the vehicle The present invention relates to a communication system such as ITS (Intelligent Transport Systems) using vehicle-to-vehicle communication executed to provide information to other vehicles.

  In ITS, the use of wireless communication similar to wireless LAN standards such as IEEE 802.11 is being studied. In such wireless communication, an access control function called CSMA / CA (Carrier Sense Multiple Access with Collision Avidance) is used. Therefore, in the wireless communication, the same wireless channel is shared by the base station device and the plurality of terminal devices. In such CSMA / CA, after confirming that no other packet signal is transmitted by carrier sense, the packet signal is transmitted by broadcast (hereinafter, transmission of the packet signal by broadcast is referred to as “notification”).

  As inter-vehicle communication, the terminal device reports a packet signal storing vehicle information indicating the speed, position, etc. of the vehicle in which the terminal device is mounted. The terminal device that has received the packet signal recognizes the approach of the vehicle based on the information stored in the packet signal. In addition, as road-to-vehicle communication, the base station device broadcasts a packet signal in which intersection information, traffic jam information, and the like are stored.

  The intersection information includes information on the situation of the intersection such as the position information of the intersection, route information of the intersection where the base station device is installed, a photographed image, and position information of vehicles and pedestrians in the intersection. The terminal device displays this intersection information on the monitor. It is also possible to recognize the situation of the intersection based on this intersection information and notify the user of visual information or a voice message for the purpose of preventing collisions with vehicles, bicycles, and pedestrians due to encounters, right turns, and left turns. . The traffic jam information includes information related to the congestion status of the runway where the base station device is installed, road construction, and accidents. The terminal device transmits the traffic jam in the traveling direction to the user based on the traffic jam information. Further, a detour for detouring the traffic jam may be presented.

  FIG. 1 shows a configuration of a communication system 500 according to Embodiment 1 of the present invention. This corresponds to a case where one intersection is viewed from above. The communication system 500 includes a base station device 20, a terminal device 10a mounted on the first vehicle 100a, and a terminal device 10b mounted on the second vehicle 100b. Area 202 indicates the radio wave range of the base station device 20, and outside area 204 indicates the radio wave range of the base station device 20. The upper side of the drawing corresponds to “north”, the first vehicle 100a proceeds from “south” to “north”, and the second vehicle 100b proceeds from “east” to “west”. The base station device 20 can communicate with an external device via the external network 200.

  2A to 2D show a superframe format defined in the communication system 500. FIG. FIG. 2A shows the structure of the super frame. The superframe is formed by N subframes indicated as the first subframe to the Nth subframe. For example, when the length of the superframe is 100 msec and N is 8, a subframe having a length of 12.5 msec is defined. N may be other than 8.

  FIG. 2B shows a configuration of a super frame generated by the first base station apparatus 20a. The first base station device 20a corresponds to any one of the base station devices 20. The first base station apparatus 20a sets a road and vehicle transmission period at the beginning of the first subframe. Moreover, the 1st base station apparatus 20a sets a vehicle transmission period following a road and vehicle transmission period in a 1st sub-frame. The vehicle transmission period is a period during which the terminal device 10 notifies the packet signal. That is, in the road and vehicle transmission period which is the head period of the first subframe, the first base station apparatus 20a always broadcasts the packet signal during this period. On the other hand, the other base station apparatus 20 arranged within the radio wave arrival distance of the first base station apparatus 20a and the terminal apparatus 10 within this radio wave arrival distance do not report the packet signal during this period. . It is defined that the terminal device 10 can notify the packet signal in the vehicle transmission period subsequent to the road and vehicle transmission period of the first subframe. Furthermore, the first base station apparatus 20a sets only the vehicle transmission period from the second subframe to the Nth subframe.

  FIG.2 (c) shows the structure of the super frame produced | generated by the 2nd base station apparatus 20b. The second base station apparatus 20b corresponds to a base station apparatus 20 different from the first base station apparatus 20a. The second base station apparatus 20b sets a road and vehicle transmission period at the beginning of the second subframe. Further, the second base station apparatus 20b sets the vehicle transmission period from the first stage of the road and vehicle transmission period in the second subframe, from the first subframe and the third subframe to the Nth subframe.

  FIG. 2D shows a configuration of a super frame generated by the third base station apparatus 20c. The third base station apparatus 20c corresponds to a base station apparatus 20 different from the first base station apparatus 20a and the second base station apparatus 20b. The third base station apparatus 20c sets a road and vehicle transmission period at the beginning of the third subframe. Also, the third base station apparatus 20c sets the vehicle transmission period from the latter stage of the road and vehicle transmission period in the third subframe, the first subframe, the second subframe, and the fourth subframe to the Nth subframe. In this way, the plurality of base station apparatuses 20 select different subframes, and set the road and vehicle transmission period at the beginning of the selected subframe. Thus, the base station apparatus 20 provides a unique notification period in the superframe by monopolizing the road and vehicle transmission period of one subframe in order for the base station apparatus 20 to notify the packet signal (information). Although the number of subframes that can be set in the superframe is limited (eight in this embodiment), if the superframe is selected in consideration of the radio wave arrival distances of the plurality of base station apparatuses 20, the base station apparatus 20 There is no limit to the number of installations. Conversely, the base station apparatus 20 is not necessarily installed for all subframes in the superframe.

  FIGS. 3A to 3B show subframe configurations. As shown to Fig.3 (a), a sub-frame is comprised in order of the road vehicle transmission period and the vehicle transmission period. In the road and vehicle transmission period, the base station device 20 can notify the packet signal, and in the vehicle and vehicle transmission period, the terminal device 10 can notify the packet signal. FIG. 3B shows the arrangement of packet signals during the road and vehicle transmission period. As illustrated, a plurality of road-to-vehicle communication packet signals (hereinafter referred to as RSU packets) are arranged in a road-vehicle transmission period (hereinafter referred to as RSU (Load Side Unit) period). Here, the front and rear RSU packets are separated by SIFS (Short Interframe Space).

  4A to 4F show the frame formats of the respective layers defined in the communication system 500. FIG. FIG. 4A shows the frame format of the physical layer. As shown in the figure, a PLCP preamble, a PLCP header, a PSDU (Physical Layer Service Data Unit), and a tail are sequentially arranged in the frame. FIG. 4B shows a frame format of the MAC layer. This frame is stored in the PSDU of FIG. As illustrated, a MAC header, an MSDU (MAC Layer Service Data Unit), and an FCS (Frame Check Sequence) are sequentially arranged in the frame. FIG. 4C shows a frame format of the LLC layer. This frame is stored in the MSDU of FIG. As illustrated, an LLC header and an LSDU (LLC Layer Service Data Unit) are sequentially arranged in the frame.

  FIG. 4D shows the frame format of the inter-vehicle / road-vehicle shared communication control information layer. This frame is stored in the LSDU of FIG. As shown in the figure, an IR header and an APDU (Application Protocol Data Unit) are sequentially arranged in the frame. FIG. 4E shows the frame format of the security layer. This frame is stored in the APDU of FIG. As illustrated, a security header (Security Header), a payload (Payload), and a security footer (Security Footer) are sequentially arranged in the frame. FIG. 4F shows the frame format of the application layer. This frame is stored in the payload of FIG. 4 (e), and is composed of application data. Hereinafter, the MAC layer frame is referred to as a MAC frame, and the security layer frame is referred to as a security frame. The frame format is called a data structure.

  FIG. 5 shows a specific example of an RSU packet when N = 4 and one base station apparatus 20 occupies and uses one RSU period. This specific example is a case where a maximum of four base station apparatuses 20 whose radio wave coverages overlap each other can be installed, and there are four RSU periods in the superframe period (100 msec in this specific example). In this specific example, seven RSU packets are transmitted in one RSU period. The security frame of each RSU packet includes a security header, a payload for storing application data, and a security footer. A public key certificate is stored in the header, and an electronic signature is stored in the footer. Note that the header of the lower layer than the security frame is omitted. In this specific example, during the superframe period, the terminal apparatus 10 needs a function of processing RSU packets from a maximum of four base station apparatuses 20, that is, for four RSU periods arranged in four subframes. Become. Here, the terminal apparatus 10 refers to the RSU packet processing system for each RSU period held as the RSU packet core. Therefore, the terminal device 10 corresponding to this specific example includes four RSU cores. The verification processing function used for signature verification by the public key cryptosystem may be arranged for each RSU packet core, or may be shared by a plurality of RSU packet cores.

  FIG. 6 illustrates a processing example of each RSU core when the terminal device 10 includes four RSU cores (RSU1 core to RSU4 core). In FIG. 6, the vehicle 100 travels from “west” to “east”. In the vicinity of the area through which the vehicle 100 passes, there are five base station devices (hereinafter also referred to as roadside devices) (in FIG. 6, the first base station device 20a, the second base station device 20b, the third base station device 20c, the second base station device). 4 base station apparatus 20d and 5th base station apparatus 20e) are installed.

  In FIG. 6, a period Tv indicates a period during which the RSU core stops processing, a period Tc indicates a period during which public key certificate verification is performed, and a period Tm performs verification of a message with an electronic signature. The period during which Moreover, the circle indicates the radio wave range of each base station apparatus 20, and RSU1 to RSU4 in each circle indicate that each uses RSU period 1 to RSU period 4 in FIG. When the vehicle 100 enters the radio wave range of the first base station device 20a, the RSU1 core executes verification of the public key certificate of the RSU packet broadcast from the first base station device 20a. When verification of the public key certificate is successful, verification of the electronically signed message of the RSU packet is executed. When the vehicle 100 goes out of the radio range of the first base station device 20a, the verification process of the RSU packet notified from the first base station device 20a is terminated. Thereafter, when the vehicle 100 enters the radio wave range of the fifth base station device 20e, the RSU1 core executes verification of the public key certificate of the RSU packet broadcast from the fifth base station device 20e. When verification of the public key certificate is successful, verification of the electronically signed message of the RSU packet is executed. When the vehicle 100 goes out of the radio range of the fifth base station apparatus 20e, the verification process of the RSU packet notified from the fifth base station apparatus 20e is terminated. The core for RSU2 to the core for RSU4 also execute the same processing as the core for RSU1.

  FIG. 7 shows an example of the data structure of the security frame included in the RSU packet. In this data structure, “version”, “message format”, “key ID”, “nonse”, “data length”, and “public key certificate” are arranged as a security header, followed by “payload”. Finally, an “electronic signature” is arranged as a security footer. In this example, the encryption target is “public key certificate”, “payload”, and “electronic signature”, and the signature target is “payload”.

  “Version” indicates the version of the frame format. “Message format” specifies a message format. The message format includes a plain text data format, an authenticated data format, and an encrypted data format with authentication.

  The “key ID” is information for identifying a communication key shared between the base station apparatus 20 and the terminal apparatus 10. When the data format is an encrypted data format with authentication, the “public key certificate”, “payload”, and “electronic signature” are encrypted with the communication key. As the communication key, a common key of a common key cryptosystem shared in advance, for example, an AES (Advanced Encryption Standard) key can be used. In the example of FIG. 7, encryption is performed in the CTR (CountTeR) mode.

  “Nonse” is set to a unique value or a part thereof for each communication used for disturbing the encryption result in the encryption using the communication key. This value may be a random number or a transmission time. Further, the source device ID may be added to the random number or the transmission time. When only the transmission time is set in “nonse”, the transmission time set in “nonce” and a unique value of the base station device 20 such as a public key certificate are used as unique values used for each communication. The serial number or device ID is used as a unique value for each communication. Even when a random number is set in “nonce”, the random number set in “nonce” and the unique value of the base station device 20 may be used as a unique value for each communication. “Data length” is the data length (more specifically, the number of bytes) of data to be encrypted. If the data length of the “public key certificate” is a fixed length, the data length of the “payload” may be set.

  The “public key certificate” sets a public key certificate for a public key unique to the base station apparatus 20. A public key certificate is a certificate that links a public key and the owner of the public key. The public key certificate includes signer identification information, device ID (public key certificate identification information), expiration date, public key (including key generation algorithm and size), signer signature, and the like. In the present embodiment, the signer is a certificate authority (CA). The signature is generated by a public key cryptosystem such as RSA, DSA (Digital Signature Algorithm), or ECDSA (Elliptic Curve-DSA). In this embodiment, ECDSA is adopted.

  A signature for “payload” is set in “electronic signature”. The signature is a signature generated using a private key that is paired with the public key included in the “public key certificate”. The signature is set in the “electronic signature” when the data format is the data format with authentication or the encrypted data format with authentication. In the case of the encrypted data format with authentication, after setting the signature in “electronic signature”, “public key certificate”, “payload”, and “electronic signature” are encrypted.

  FIG. 8 shows another example of the data structure of the security frame included in the RSU packet. Compared with the data structure shown in FIG. 7, the data structure shown in FIG. Along with this, the “public key certificate” is arranged before the “data length”. In the data structure illustrated in FIG. 8, “public key certificate” is arranged immediately before “nonse”. In the following, processing when the message format of the security frame in FIG. 7 is the encrypted data format with authentication will be described. In addition, when the message format is a data format with authentication, only the processing relating to encryption and decryption is omitted. If the message format is a plain text data format, only signature generation and verification is omitted. At this time, any value may be set in the “electronic signature” of the security footer. Furthermore, the security footer may be omitted. Further, in the security frame of FIG. 8, when the message format is the data format with authentication, the “public key certificate” is simply excluded from the encryption target. In FIG. 7, “public key certificate”, “payload”, and “electronic signature” are encrypted. In FIG. 8, “payload” and “electronic signature” are encrypted. However, in order to conceal information and prevent information loss, at least “payload” needs to be encrypted.

  FIG. 9 illustrates a configuration of the base station apparatus 20 according to the first embodiment. The base station apparatus 20 includes an antenna 21, an RF unit 22, a modem unit 23, a MAC frame processing unit 24, a security processing unit 25, a data generation unit 26, a network communication unit 27, a storage unit 28, and a control unit 29. The security processing unit 25 includes a signature unit 251 and an encryption unit 252.

  The configuration of the MAC frame processing unit 24, the security processing unit 25, the data generation unit 26, the network communication unit 27, the storage unit 28, and the control unit 29 can be realized by an arbitrary processor, memory, or other LSI in terms of hardware. In terms of software, it is realized by a program loaded in a memory or the like, but here, functional blocks realized by their cooperation are depicted. Accordingly, those skilled in the art will understand that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof.

  The RF unit 22 receives a packet signal from the terminal device 10 and another base station device 20 by the antenna 21 as a reception process. The RF unit 22 performs frequency conversion on the received radio frequency packet signal to generate a baseband packet signal. The RF unit 22 outputs the baseband packet signal to the modem unit 23. Generally, since a baseband packet signal is formed by an in-phase component and a quadrature component, two signal lines should be shown, but in order to simplify the drawing, only one signal line is shown in FIG. Show. The RF unit 22 includes a low noise amplifier (LNA), a mixer, an AGC, an A / D conversion unit, etc. (not shown) as components of the reception system.

  The RF unit 22 transmits the generated packet signal from the base station apparatus 20 as a transmission process. The RF unit 22 performs frequency conversion on the baseband packet signal input from the modem unit 23 to generate a radio frequency packet signal. The RF unit 22 transmits a radio frequency packet signal from the antenna 21 during the RSU period assigned to itself. The RF unit 22 includes a PA (Power Amplifier), a mixer, a D / A converter, and the like (not shown) as components of the transmission system.

  The modem unit 23 demodulates the baseband packet signal from the RF unit 22 as a reception process. The modem unit 23 outputs the digital data obtained by demodulation to the MAC frame processing unit 24. Further, the modem unit 23 performs modulation on the MAC frame from the MAC frame processing unit 24 as transmission processing. The modem unit 23 outputs the modulated result to the RF unit 22 as a baseband packet signal.

  The communication system 500 according to the present embodiment employs an OFDM (Orthogonal Frequency Division Multiplexing) modulation scheme. In this case, the modem unit 23 performs FFT (Fast Fourier Transform) as the reception process, and executes IFFT (Inverse Fast Fourier Transform) as the transmission process.

  As a reception process, the MAC frame processing unit 24 extracts a MAC frame from the digital data from the modem unit 23, extracts a security frame from the extracted MAC frame, and outputs the security frame to the security processing unit 25. The MAC frame processing unit 24 adds a MAC header, an LLC header, and an IR information header to the security frame from the security processing unit 25 as a transmission process, generates a MAC frame, and outputs the MAC frame to the modulation / demodulation unit 23. . Further, the packet signal transmission / reception timing is controlled so that packet signals from other base station apparatuses 20 or terminal apparatuses 10 do not collide.

  The network communication unit 27 is connected to the external network 200. The network communication unit 27 receives road information regarding construction and traffic jams from the external network 200.

  Further, the network communication unit 27 outputs the processing result by the security processing unit 25 to the external network 200, accumulates it in the storage unit 28, and periodically outputs it to the external network 200. The data generation unit 26 generates application data. For example, road information is set in application data. Then, the data format is designated according to the contents of the application data, and the generated application data and its data length are output to the security processing unit 25. The storage unit 28 stores various information. The control unit 29 controls processing of the entire base station apparatus 20.

  The security processing unit 25 generates or interprets a security frame. In this embodiment, since attention is paid to packet transmission from the base station apparatus 20, attention is paid to processing for generating a security frame. The security processing unit 25 generates a security frame to be output to the MAC frame processing unit 24 using application data received from the data generation unit 26, a private key received from a certificate authority, a public key certificate, and the like.

  The security processing unit 25 includes a signature unit 251 and an encryption unit 252. In the present embodiment, the signature unit 251 stores therein a public key certificate including a secret key issued by a certificate authority (not shown) and a public key that is paired with the secret key. By making the private key and public key certificate unique to the base station apparatus 20, security can be enhanced as compared with the common key cryptosystem. The signature unit 251 generates a signature for the signature target using the private key held by itself. The encryption unit 252 encrypts the encryption target using a communication key shared with the terminal device 10. In the data structure shown in FIG. 7, the “public key certificate”, “payload”, and “electronic signature” are encrypted.

  FIG. 10 illustrates a configuration of the terminal device 10 mounted on the vehicle 100 according to the first embodiment. The terminal device 10 includes an antenna 11, an RF unit 12, a modem unit 13, a MAC frame processing unit 14, a security processing unit 15, a reception processing unit 161, a notification unit 162, a data generation unit 17, a storage unit 18, and a control unit 19. . The security processing unit 15 includes a verification unit 151 and a decryption unit 152.

  The configuration of the MAC frame processing unit 14, the security processing unit 15, the reception processing unit 161, the notification unit 162, the data generation unit 17, the storage unit 18, and the control unit 19 is arbitrary in terms of hardware, such as an arbitrary processor, memory, and the like. Although it can be realized by an LSI and is realized by a program loaded into a memory in terms of software, here, functional blocks realized by their cooperation are drawn. Accordingly, those skilled in the art will understand that these functional blocks can be realized in various forms by hardware only, software only, or a combination thereof.

  The antenna 11, the RF unit 12, the modem unit 13, and the MAC frame processing unit 14 are basically the same in configuration and operation as the antenna 21, the RF unit 22, the modem unit 23, and the MAC frame processing unit 24 of FIG. Hereinafter, these components will be described focusing on the differences.

  The reception processing unit 161 is based on the data received from the security processing unit 15 and the vehicle information of the own vehicle received from the data generation unit 17, the risk of collision, the approach of an emergency vehicle such as an ambulance or fire engine, and the road in the traveling direction And estimation of traffic congestion at intersections. Further, if the data is image information, it is processed to be displayed on the notification unit 162.

  The notification unit 162 includes means for notifying a user such as a monitor, a lamp, and a speaker (not shown). In accordance with an instruction from the reception processing unit 161, the driver is notified of the approach of another vehicle (not shown) via the notification means. In addition, traffic information, image information such as intersections, and the like are displayed on the monitor.

  The data generation unit 17 specifies a current position, a traveling direction, a moving speed, and the like of the vehicle 100 on which the terminal device 10 is mounted based on information supplied from a GPS receiver, a gyroscope, a vehicle speed sensor, and the like (not shown). The current position is indicated by latitude / longitude. Since the method for identifying these pieces of information can be realized by a generally known technique, description thereof is omitted here. The data generation unit 17 generates data to be notified to other terminal devices 10 and the base station device 20 based on the specified information, and outputs the data to the security processing unit 15. Further, the specified information is output to the reception processing unit 161 as vehicle information of the own vehicle. The storage unit 18 stores various information. The control unit 19 controls processing of the entire terminal device 10.

  The security processing unit 15 generates or interprets a security frame. In this embodiment, in order to pay attention to packet reception from the base station apparatus 20, attention is paid to processing for interpreting a security frame stored in the packet signal. The security processing unit 15 includes a verification unit 151 and a decryption unit 152. The decryption unit 152 decrypts the encryption target using the communication key specified by the “key ID” of the security frame. In the data structure shown in FIG. 7, “public key certificate”, “payload”, and “electronic signature” are decrypted. The verification unit 151 verifies the “public key certificate” and the “electronic signature”. In this embodiment, the verification unit 151 stores therein an authentication key for verifying a public key certificate issued by a certificate authority (not shown) in order to verify the public key certificate. This authentication key is a public key that is paired with the private key used to generate the signature of the public key certificate in the certificate authority.

  FIG. 11 shows a configuration example 1 of the verification unit 151. The verification unit 151 according to the configuration example 1 includes a certificate verification unit 151a, a message verification unit 151b, a digest holding unit 151c, and an authentication key holding unit 151d. In the configuration example 1, the verification unit has a verification function for public key signature verification that ends verification of a public key certificate or an electronically signed message of an RSU packet received in a unit RSU period in each RSU core within a superframe period. 151 is assumed to have.

  The digest holding unit 151c holds the digest, public key, and device ID of the public key certificate that has been successfully verified by the certificate verification unit 151a. For convenience of explanation, these pieces of information are collectively referred to as RSU verification information. The digest holding unit 151c holds RSU verification information for each RSU period (subslot). That is, the RSU verification information is held by the number of RSU cores. Here, the signature included in the public key certificate is applied as the digest of the public key certificate. However, in the following processing, the hash value, the public key and / or the public key certificate of the entire certificate or a part of the certificate is used. The signature and device ID (public key certificate identification number) included may be used as a substitute for the digest. That is, any information may be used as long as it can specify a certificate. In this way, the amount of data held in the digest holding unit 151c is reduced. Note that the RSU verification information only needs to be able to at least identify the public key certificate that has been successfully verified, and therefore does not necessarily require all of the digest of the public key certificate, the public key, the device ID, and the identification number of the public key certificate. However, it is not necessary to limit to these. Any information can be used as long as it can be obtained from the public key certificate. The status is state information indicating a verification state in the RSU period. The authentication key holding unit 151d holds an authentication key for verifying the public key certificate by the certificate verification unit 151a.

  The certificate verification unit 151a verifies the signature included in the public key certificate included in the packet signal broadcast from the base station device 20, using the authentication key held in the authentication key holding unit 151d. This authentication key may be incorporated in advance, or may be acquired afterwards by a secure means and held in the authentication key holding unit 151d.

  If the verification of the signature included in the public key certificate is successful, it can be estimated that the public key generated by the base station device 20 included in the public key certificate is authentic and certified by the certificate authority. However, since a public key cryptosystem (ECDSA in the present embodiment) is used for this signature, the processing load increases if public key certificate verification is performed on all RSU packets. Therefore, public key certificate verification is skipped as appropriate.

  In the following, unless otherwise specified, the processing related to the RSU verification information in the digest holding unit 151c is processing for the RSU verification information corresponding to the RSU period in which the packet signal is received. When the certificate verification unit 151a receives the packet signal broadcast from the base station device 20, the certificate verification unit 151a compares the digest extracted from the public key certificate included in the RSU packet with the digest held in the digest holding unit 151c. To do. When the two are different, the certificate verification unit 151a performs verification of the public key certificate included in the packet signal. If the verification of the public key certificate is successful, the RSU verification information held in the digest holding unit 151c is updated to that of the verified public key certificate. If verification of the public key certificate fails, the process ends. When both correspond (more precisely, match), the verification of the public key certificate included in the packet signal is skipped. That is, the verification is considered successful if the digest of the public key certificate matches without performing formal verification. This is because the packet signal broadcast from the same base station apparatus 20 can be estimated while the digest of the public key certificate or the public key and device ID match. That is, once verification of a public key certificate included in a packet signal broadcast from a certain base station apparatus 20 is successful, it can be determined that the reliability of the subsequent packet signal broadcast from that base station apparatus 20 is high. In the message verification, message verification processing is executed using the public key and device ID held in the digest holding unit 151c. The reason why the public key and the device ID are not acquired from the public key certificate included in the received RSU packet is to counter the tampering attack of the public key certificate.

  The message verification unit 151b verifies the message with authentication included in the packet signal broadcast from the base station device 20 when the verification of the public key certificate is successful in the certificate verification unit 151a or when the authentication is skipped. . For the verification, the public key and device ID held in the digest holding unit 151c are used. In this embodiment, the integrity and authenticity of the “payload” in the electronically signed message format is verified. In the encrypted message format with electronic signature, the same processing is performed after the decryption (decryption). Since this electronic signature is generated by a private key that is paired with the public key stored in the public key certificate included in the packet signal, verification of the message with the electronic signature using the public key is successful. For example, the message may be a complete and authentic message generated by the base station apparatus 20.

  However, since the public key cryptosystem (ECDSA in this embodiment) is also used for this electronic signature, the processing load increases when verification of a message with an electronic signature is executed in all RSU packets. Therefore, verification of a message with an electronic signature is appropriately skipped according to the processing capability of the verification unit 151. Note that when the number of RSU packets is small or there is a sufficient processing capacity, all messages with electronic signatures may be verified. Since the processing capability of the verification unit 151 increases as the hardware scale and specifications increase, the reliability of data and the circuit scale are in a trade-off relationship.

  The message verification unit 151b has received a packet signal in which the status held in the digest hold 151c is “message verified” and the digest of the public key certificate corresponds (more precisely, matches). Meanwhile, verification of a message with an electronic signature of at least one of the packet signals is skipped. For example, with respect to a plurality of packet signals having the same digest of the public key certificate, when verification of a digitally signed message of at least one (for example, the first packet signal) included in the plurality of packet signals is successful, The message with the electronic signature may be determined to be approved without verifying the message with the electronic signature included in the packet signal.

  More specifically, the message verification unit 151b has successfully verified a message with an electronic signature included in the first packet signal among a plurality of packet signals received during the RSU period of the same subframe and is not a packet signal. If the verification of the electronically signed message included in any one of the packet signals is successful, the electronically signed message included in all the packet signals received during the RSU period may be determined to be approved.

  FIG. 12 is a flowchart illustrating an RSU packet reception process of the terminal device 10 in which the verification unit 151 according to the configuration example 1 is used. The RF unit 12 receives the RSU packet (S10). The RSU packet is output to the security processing unit 15 through the modem unit 13 and the MAC frame processing unit 14. The certificate verification unit 151a compares the digest of the public key certificate held in the digest holding unit 151c with the digest of the public key certificate included in the received RSU packet, and determines whether or not they match (S11). ).

  If the digests do not match (N in S11), the certificate verification unit 151a verifies the signature stored in the public key certificate included in the received RSU packet (S12). Note that when the digests do not match, it occurs when the initial state or the base station apparatus 20 is switched.

  If the verification is successful (Y in S12), the digest of the public key certificate and the public key are overwritten in the digest holding unit 151c (S13). The certificate verification unit 151a determines that the packet authentication within the corresponding RSU period is indefinite, and reports it to the reception processing unit 161 (S14). Indefinite means a state where the result of the authentication process is not fixed. The reception processing unit 161 processes data included in a packet whose authentication is indefinite according to a preset rule. For example, the processing for the data may be stopped until it is authenticated, may be flagged as unauthenticated and passed to the notification unit 162, or depending on the importance of the information included in the message You may use both properly. When the notification unit 162 receives information that is flagged as unauthenticated, the notification unit 162 can notify the user of the information in a manner that allows the user to recognize that the information is unauthenticated.

  If the verification fails in step S12 (N in S12), it is determined that the packet authentication within the corresponding RSU period is denied and reported to the reception processing unit 161 (S15). The process of step S12 to step S15 is the process of the period Tc in FIG. If the digests match in step S11 (Y in S11), a packet signal to be verified for the message with the electronic signature is selected (S16). As described above, the verification target may be a leading packet within the corresponding RSU period or a packet other than the leading packet. Further, the number of packets to be verified may be one or plural.

  The message verification unit 151b verifies the message with the electronic signature included in the selected packet (S17). When the verification is successful (Y in S17), the message verification unit 151b determines that the packet authentication within the corresponding RSU period is approval and reports it to the reception processing unit 161 (S18). When the verification fails (N in S17), the message verification unit 151b determines that the packet authentication within the corresponding RSU period is denied, and reports it to the reception processing unit 161 (S19). The process of step S16 to step S19 is the process of the period Tm in FIG.

  While the reception process of the terminal device 10 is continuing (N in S20), the processes from step S10 to step S19 are repeatedly executed. When the reception process ends (Y in S20), the processes from step S10 to step S19 are also ended.

  FIG. 13 shows a configuration example 2 of the verification unit 151. The verification unit 151 according to Configuration Example 2 has a configuration in which a status management unit 151e is added to the verification unit 151 according to Configuration Example 1. The status management unit 151e manages the status indicating the progress of processing corresponding to each of the RSU verification information held in the digest holding unit 151c. In the configuration example 2, it is assumed that it is not guaranteed that the verification of the public key certificate and the electronically signed message of the RSU packet received during the unit RSU period will be completed during the unit RSU period. That is, the processing capability of the verification unit 151 according to the configuration example 2 is lower than the processing capability of the verification unit 151 according to the configuration example 1, in other words, the circuit scale is designed to be small.

  FIG. 14 is a flowchart illustrating an RSU packet reception process of the terminal device 10 in which the verification unit 151 according to the configuration example 2 is used. The RF unit 12 receives the RSU packet (S30). The RSU packet is output to the security processing unit 15 through the modem unit 13 and the MAC frame processing unit 14. The certificate verification unit 151a compares the digest of the public key certificate held in the digest holding unit 151c with the digest of the public key certificate included in the received RSU packet, and determines whether or not they match (S31). ).

  If the digests do not match (N in S31), the certificate verification unit 151a determines that the verification of the public key certificate of the packet within the corresponding RSU period is necessary, and determines that packet authentication is indefinite, and the reception processing unit 161 Report (S32). After that, the status management unit 151e is instructed to start verification of the public key certificate to the certificate verification unit 151a (S33). If the digests match (Y in S31), the status management unit 151e is instructed to start message verification, and the status management unit 151e determines the status (S34, S38). The status is managed according to flowcharts shown in FIGS.

  When the status is “certificate verification failure” or “message verification failure”, the status management unit 151e determines that the packet authentication within the corresponding RSU period is denied, and reports it to the reception processing unit 161 (S35). When the status is “certificate verifying”, “certificate verification successful”, or “message verification in progress”, the status management unit 151e determines that the packet authentication within the corresponding RSU period is indefinite and reports it to the reception processing unit 161 ( S36). When the status is “successful message verification”, the status management unit 151e determines that the packet authentication within the corresponding RSU period is approval, and reports it to the reception processing unit 161 (S37). In the case of “successful certificate verification” after the report (successful certificate verification in S38), the status management unit 151e instructs the message verification unit 151b to start verification of a message with an electronic signature (S39).

  While the reception processing of the terminal device 10 is continuing (N in S40), the processing from step S30 to step S39 is repeatedly executed. When the reception process ends (Y in S40), the processes from step S30 to step S39 are also ended.

  FIG. 15 is a flowchart illustrating a public key certificate verification process of the terminal device 10 in which the verification unit 151 according to the configuration example 2 is used. The verification process starts upon receiving a public key certificate verification start instruction from the status management unit 151e (S33 in FIG. 14). First, the status management unit 151e sets the status to “certifying in progress” (S331). The status management unit 151e determines whether or not the verification of the public key certificate has been completed (S332). While the process is not completed (N in S332), the status is maintained as “certificate verifying”. When the verification ends (Y in S332), the status management unit 151e determines whether the verification is successful (S333). When the verification is successful (Y in S333), the certificate verification unit 151a overwrites the digest holding unit 151c with the digest of the public key certificate and the public key (S334). The status management unit 151e changes the status to “successful certificate verification” (S335). If the verification fails (N in S333), the status management unit 151e changes the status to “certificate verification failure” (S336).

  FIG. 16 is a flowchart illustrating a verification process for a message with an electronic signature of the terminal device 10 in which the verification unit 151 according to Configuration Example 2 is used. The verification process starts upon receiving an instruction to start verification of a message with an electronic signature from the status management unit 151e (S39 in FIG. 14). First, the status management unit 151e changes the status to “under message verification” (S391). The status management unit 151e determines whether the verification of the message with the electronic signature has been completed (S392). While the process is not completed (N in S392), the status is maintained as “message verification in progress”. When the verification ends (Y in S392), the status management unit 151e determines whether the verification is successful (S393). When the verification is successful (Y in S393), the status management unit 151e changes the status to “message verification successful” (S394). If the verification fails (N in S393), the status management unit 151e changes the status to “message verification failure” (S395).

  14 corresponds to the process in the period Tc in FIG. 6, and the processes in steps S34 to S39 in FIG. 14 and the process in FIG. 16 correspond to the process in the period Tm in FIG. According to the verification process shown in the flowcharts of FIGS. 14 to 16, even if the verification of the public key certificate and the electronic signature message included in the unit RSU period does not end, the verification process can be executed without contradiction. .

  As described above, according to the first embodiment, it is possible to reduce the processing load when receiving a packet signal while improving security. That is, security can be improved by including a public key certificate and an electronic signature using a public key cryptosystem in the packet signal. In addition, the processing load can be reduced by appropriately skipping the public key certificate verification process. The processing load can be further reduced by appropriately skipping the verification process of the electronic signature message. As the processing load is reduced, the circuit scale can be reduced and the cost can be reduced. Therefore, if the terminal device 10 according to the present embodiment is employed in ITS that requires high reliability of road-to-vehicle communication, both high reliability and low cost can be achieved, leading to the spread of ITS.

  The first embodiment has been described above. This embodiment is an exemplification, and it will be understood by those skilled in the art that various modifications can be made to the combination of each component and each processing process, and such modifications are also within the scope of the present invention. .

  FIG. 17 shows a first modification of the format of the security frame of FIG. 7 included in the RSU packet. The data structure according to Modification 1 is a configuration in which “MAC” is added to the data structure shown in FIG. In the data structure shown in FIG. 17, “MAC” is added after “electronic signature”, and the security footer includes “electronic signature” and “MAC”. The “MAC” is generated by applying a predetermined MAC (Message Authentication Code) algorithm to the common key and the MAC target. In the data structure shown in FIG. 17, the MAC objects are “nonse”, “data length”, “public key certificate”, “payload”, and “electronic signature”, and the common key is between the base station apparatus 20 and the terminal apparatus 10. It is a communication key shared by. In the example of FIG. 17, “MAC” substitutes the value of CBC (Cipher Block Chaining) -MAC using an AES (Advanced Encryption Standard) algorithm and a communication key specified by “key ID”. In the case of encrypted data with authentication, it is generated in the CCM (Counter with CBC-MAC) mode.

  “MAC” is a simpler authentication method than “electronic signature”, has a small amount of data, and can perform high-speed processing. The security processing unit 15 of the base station apparatus 20 generates both “electronic signature” and “MAC”. The verification unit 151 of the terminal device 10 performs verification of the public key certificate and the electronically signed message included in the first packet of the RSU period, and when the verification is successful, the packet subsequent to the first packet of the RSU period For, a comparison of digests of public key certificates and verification of a message with a MAC are executed. Verification of messages with MAC is a process that is lighter in load than verification of messages with electronic signature and suitable for hardware, and minimizes the same encryption algorithm as that used for encrypted data with authentication Since there is no additional cryptographic processing, the circuit scale can be reduced while suppressing a decrease in security. The message verification unit 151b in FIG. 11 and FIG. 13 performs MAC verification instead of skipping message verification. If the MAC verification is successful, the packet authentication is approved. If MAC verification fails, packet authentication is reported as denial. In this way, by performing MAC verification instead of skipping all verification, it becomes possible to confirm the integrity and authenticity of each message, thereby reducing the burden of signature verification without incurring security degradation. be able to.

  In the data structure according to the first modification, the “public key certificate” is not subject to encryption. In this case, as in the data structure of FIG. 8, “data length” and “public certificate” are transposed, and “payload” or the number of bytes of encryption target data is substituted for “data length”. Also good. Further, as in FIG. 7, the “public key certificate” may be included in the encryption target.

  FIG. 18 shows a second modification of the data structure of the security frame included in the RSU packet. In the data structure according to the first modification, both “electronic signature” and “MAC” are stored as authentication data, so that the data amount of the security frame increases. Therefore, a method for reducing the data amount of security frames of packets other than the first packet in the RSU period is considered.

  In the data structure according to the modified example 2, only the first RSU packet of one RSU period stores both “electronic signature” and “MAC” in the security footer, and the subsequent RSU packet is only “MAC”. Compared to the data structure according to the first modification, the first packet has the same structure. Subsequent packets have a configuration in which “electronic signature” is deleted and “public key certificate digest” is used instead of “public key certificate”. When the packet position on the communication path is managed in the communication system 500, the “public key certificate digest” can be omitted. As described above, the “public key certificate digest” can be substituted if it is information that can identify the public key certificate. For example, the device ID included in the public key certificate, the identification information of the public key certificate, the signature of the public key certificate, and a part thereof correspond to this. The security frame having the data structure according to the modified example 2 is used for packets other than the first packet in the RSU period.

  Similarly to the data structure according to the first modification, the data structure of the leading RSU packet according to the second modification also excludes the “public key certificate” from being encrypted. In this case, as in the data structure of FIG. 8, “data length” and “public certificate” are transposed, and “payload” or the number of bytes of encryption target data is substituted for “data length”. Also good. Similarly to FIG. 7, “public key certificate” or “public key certificate digest” may be included in the encryption target.

  In addition, regarding the subsequent RSU packet in the data structure according to the modified example 2, “public key certificate digest” is excluded from the encryption target, but “public key certificate digest” is also included in the encryption target. Alternatively, the “data length” and the “public key certificate digest” may be transposed, and “payload” or the number of bytes of data to be encrypted may be substituted for “data length”. Good. Further, the description has been made so that the data structure of the security frame is divided depending on whether the first RSU packet or the subsequent RSU packet of one RSU period. The base station apparatus 20 may include a “public key certificate” and an “electronic signature” in one of all the RSU packets transmitted in the superframe. In this case, the data structure of the security frame is divided into a leading RSU packet to be transmitted in the super frame and other subsequent RSU packets.

  FIG. 19 shows a third modification of the data structure of the security frame included in the RSU packet. In the data structure according to the third modification, the first RSU packet in one RSU period has the same structure as the security frame in FIG. 7, and the subsequent RSU packet has the same structure as the subsequent RSU packet in the second modification. It is most effective when it has a public key signature verification (ECDAS verification) capability for each RSU core within the superframe period. Also in Modification 2 and Modification 3 of the data structure of the security frame, similar to Modification 1, message verification unit 151b in FIGS. 11 and 13 performs MAC verification instead of skipping message verification. If the MAC verification is successful, the packet authentication is approved. If MAC verification fails, packet authentication may be reported as denial.

  The head RSU packet in the data structure according to the modification 3 may have the same structure as the security frame in FIG. In addition, regarding the subsequent RSU packet in the data structure according to the modification 3, the “public key certificate digest” is excluded from the encryption target, but the “public key certificate digest” is also included in the encryption target. Alternatively, the “data length” and the “public key certificate digest” may be transposed, and “payload” or the number of bytes of data to be encrypted may be substituted for “data length”. Good. Similarly to Modification 2, when one base station apparatus 20 uses a plurality of RSU periods, the data structure of the security frame is divided into the first RSU packet to be transmitted in the superframe and the other subsequent RSU packets. You may do it.

  In the first modification and the second modification, when the terminal apparatus 10 enters the radio wave reachable distance of the base station apparatus 20, the first RSU packet in the RSU period is first selected and verified. At this time, the validity of the base station apparatus 20 and the integrity and authenticity of the application data included in the packet signal are confirmed by verifying the public key certificate and the message. When approved, it is confirmed that the RSU packet is a regular packet signal transmitted from the regular base station apparatus 20. Further, due to the nature of communication, it is determined that the regular base station apparatus 20 is the transmission period during the RSU period during which the RSU packet is transmitted. In subsequent RSU packets, the integrity and authenticity of the application data included in the packet signal is confirmed by confirming the match of the digest of the public key certificate and MAC verification. On the other hand, when the terminal device 10 goes out of the radio wave reach of the base station device 20 and enters the radio wave reach of another base station device 20 that uses the same subframe, the digests of the public key certificates do not match. Therefore, the signature is verified again. In the third modification, the process is closed in RSU period units. The public key certificate and the message are verified for the first RSU packet in the RSU period, and the validity of the base station device 20 and the integrity and authenticity of the application data included in the packet signal are confirmed. For the subsequent RSU packet, the integrity and authenticity of the application data included in the packet signal is confirmed by confirming the digest match of the public key certificate and performing MAC verification.

  Next, Modification 4 will be described. In Modification 2 shown in FIG. 18, each RSU packet includes a MAC. In the fourth modification, MACs are not arranged for RSU packets other than the head, and those MACs are also arranged together in the head packet. That is, the head packet includes the MAC for each RSU packet included in the RSU period. FIGS. 20A to 20C show a fourth modification of the data structure of the security frame included in the RSU packet. FIG. 20A shows the format of the leading packet among a plurality of RSU packets included in the road and vehicle transmission period shown in FIG. 3B, that is, the RSU period shown in FIG.

  This corresponds to the RSU packet 1 in FIG. As illustrated, “Ver”, “message format”, “packet ID”, “public key certificate”, “key ID”, “MAC list”, “electronic signature”, “Nonce”, “data length”, “ "Payload" is arranged in order. Since “Ver”, “message format”, “public key certificate”, “key ID”, “electronic signature”, “Nonce”, “data length”, and “payload” are the same as before, here Description is omitted. The packet ID indicates a number for identifying a plurality of RSU packets included in the RSU period. Specifically, packet IDs are defined as “0”, “1”,... In order from the top of a plurality of RSU packets included in the RSU period. Therefore, “0” is indicated as the packet ID in the head packet.

  The configuration of the “MAC list” is shown in FIG. As shown, “number of packets”, “MAC (P0)”, “MAC (P1)”,..., “MAC (Pn−1)” are included. “Number of packets” indicates the number of RSU packets included in the RSU period. Therefore, the number n of “MAC (Pi)” (0 ≦ i <n, i is a natural number) listed in the MAC list is substituted. “MAC (P0)” indicates the MAC for the packet ID “0”, and “MAC (P1)” indicates the MAC for the packet ID “1”. When the “number of packets” is n, up to “MAC (Pn−1)” is included. Returning to FIG. Here, “MAC list” and “electronic signature” are signature targets, “Nonce”, “data length”, and “payload” are MAC targets, and payload is an encryption target. Note that encryption may not be performed.

  FIG. 20C shows the format of the subsequent RSU packet. This corresponds to each of RSU packet 2 to RSU packet 7 in FIG. As illustrated, “Ver”, “message format”, “packet ID”, “public key certificate digest”, “key ID”, “Nonce”, “data length”, and “payload” are arranged in this order. When the number of packets is n, the packet ID indicates “1”, “2”,... “N−1”. In FIG. 20C, unlike the subsequent head RSU packet in FIG. 18, the key ID is not included. This is because in Modification 4, the MAC for all RSU packets is included in the top packet, and a communication key with a common key ID is used for generating the MAC.

  The security processing unit 15 of the base station apparatus 20 generates “MAC” for all the RSU packets, and then generates an “electronic signature” for the “MAC list” including the generated MAC. The security processing unit 15 includes them in the top packet. The verification unit 151 of the terminal device 10 performs verification of the “MAC list” with an electronic signature by using the public key certificate included in the first packet of the RSU period and the public key included in the public key certificate. The validity of the base station device 20 and the authenticity of the application data included in the packet signal are confirmed. When those verifications are successful, that is, when they are approved, it is confirmed that the RSU packet is a regular packet signal transmitted from the regular base station apparatus 20. Further, as described above, the regular base station apparatus 20 determines that the RSU period during which the RSU packet is transmitted is a transmission period. After the two verifications by the public key cryptosystem in the first packet in the RSU period have succeeded, the digest of the public key certificate and the message verification using the MAC (P0) are followed for the first packet. In the packet, the MAC (Pi), (0 <i <n, i is a natural number) included in the first packet in which two verifications by the public key cryptosystem are successful or the digest of the public key certificate is successfully compared Perform the used message authentication.

  According to the modified example 4, since the MACs are aggregated into the head packet, the transmission efficiency of the RSU packets other than the head packet can be improved. Moreover, since the key ID of all RSU packets is made common, the transmission efficiency of all the RSU packets can be improved. In addition, the processing can be closed in units of RSU periods in the same way as the third modification in response to the speedup of the authentication processing by the public key cryptosystem.

  Next, Modification 5 will be described. The modification 5 is different from the modification 4 in that “payload” is a target of an electronic signature and “MAC list” and “electronic signature” are encryption targets. FIGS. 21A and 21B show a fifth modification of the data structure of the security frame included in the RSU packet. FIG. 21A shows the format of the leading packet, and FIG. 21B shows the format of the RSU packet other than the leading packet. In FIG. 21A, compared to FIG. 20A, since the MAC object and the encryption object are different, the positions of the “MAC list” and the “electronic signature” are different. On the other hand, FIG. 21B is the same as FIG. In contrast to the modification 4, the base station device 20 and the terminal device 10 may perform the same processing as that of the modification 3 except for the signature processing and the encryption processing, and thus the description thereof is omitted here. According to the modified example 4, since the MAC list is to be encrypted, security characteristics can be improved.

  In addition, in the packet following the RSU period of the modification 4 and the modification 5, the “public key certificate digest” is included in order to easily confirm the base station device 20 that transmits the packet, but it is omitted. It doesn't matter. When the digest of the public key certificate used when the two verifications by the public key cryptosystem in the first packet of the RSU period are successful and the digest of the public key certificate included in the first packet match, Then, MAC (Pi) (0 ≦ i <n, i is a natural number) is taken out. Therefore, it is determined that the extracted MAC is a valid value transmitted from the legitimate base station device 20. In this case, the digest comparison of the public key certificate with respect to the packet following the RSU period is omitted.

  Next, Modification 6 will be described. In the sixth modification, one electronic signature and one MAC are generated for all the plurality of RSU packets included in the RSU period. FIGS. 22A to 22C show a sixth modification of the data structure of the security frame included in the RSU packet. FIG. 22A shows the format of the head packet, and FIG. 22B shows the format of the RSU packet other than the head packet and the last RSU packet among the plurality of RSU packets included in the RSU period. Further, FIG. 22C shows the format of the last RSU packet. “Total number of packets” in FIG. 22A indicates the total number of RSU packets included in the RSU period, and “payload length” indicates the total number of payload bytes included in FIGS. 22A to 22C. Show. On the other hand, “data length” in FIGS. 22A to 22C indicates the number of bytes to be encrypted in the packet. Further, in FIG. 22A and FIG. 22B, the electronic signature and the MAC are not included. On the other hand, only the electronic signature and the MAC are included in FIG.

  In the data structure of the security frame of Modification 6, the “total number of packets” is included only in the first packet, but the “total number of packets” may be included for all packets. For example, like the first packet, the “packet ID” and the “total number of packets” may be arranged side by side.

  The security processing unit 15 of the base station apparatus 20 generates an electronic signature and MAC for the pre-division payload, and then divides the payload into a plurality of pieces. The number of divisions corresponds to the number of RSUs included in the RSU period. The security processing unit 15 generates an RSU packet having the format shown in FIGS. 22A to 22C based on the divided payload. At that time, as described above, the electronic signature and the MAC are arranged only in the last RSU packet. The verification unit 151 of the terminal device 10 combines a plurality of RSU packets included in the RSU period based on the packet ID. Hereinafter, the synthesized RSU packet is referred to as a concatenated packet. The verification unit 151 verifies the validity of the base station device 20 and the authenticity of the application data included in the packet signal by executing verification of the public key certificate and the electronically signed message included in the concatenated packet. When these verifications are successful, that is, when they are approved, it is confirmed that the concatenated packet is a regular packet signal transmitted from the regular base station apparatus 20. Furthermore, the verification unit 151 performs digest comparison of public key certificates and verification of messages with MAC. According to the modified example 5, since one electronic signature and one MAC are arranged for all of the plurality of RSU packets, transmission efficiency can be improved.

  Further, by adopting the data structure of the security frame of Modifications 1, 2, 4, 5 in which MACs are arranged for all packets and Modification 6 in which all packets are combined in one RSU period, It is also possible to provide a low-cost terminal device 10 that supports only common key cryptography, that is, only decryption of encrypted data and MAC verification, without implementing cryptographic verification processing. The terminal device 10 can obtain the effects of spoofing detection and tampering detection.

  Further, in the first, second, fifth, and sixth modifications, the “electronic signature” is the MAC target, but it is not necessarily included in the MAC target. Even if it is not included, the same effect can be obtained. In the example of the security frame according to the present invention, another example, and the first to sixth modifications, the “payload” is mainly encrypted as an encryption target. However, the encryption is not necessarily performed. If it is not necessary to conceal the password, plain text may be used without encryption.

  In the first embodiment and the modification, the “key ID” is arranged, but an encrypted communication key may be arranged instead.

(Example 2)
The knowledge which became the basis of Example 2 of the present invention is as follows. In road-to-vehicle communication and vehicle-to-vehicle communication that require emphasis on real-time performance, it is effective to adopt a common key encryption method. However, if road-to-vehicle communication and vehicle-to-vehicle communication are operated with the same common key, if the key is leaked, the security of both road-to-vehicle communication and vehicle-to-vehicle communication is broken.

  The second embodiment has been made in view of such a situation, and an object thereof is to provide a technique for efficiently improving the security of a communication system using a common key encryption method.

  The outline | summary of the one aspect | mode of Example 2 is as follows. A terminal device according to an embodiment of the second embodiment includes a receiving unit that receives an encrypted packet signal, and a decrypting unit that decrypts the packet signal. The packet signal is encrypted by a common key encryption method, and is encrypted by a different operation method between a packet signal broadcast from the base station apparatus and a packet signal broadcast from another terminal apparatus.

  According to this aspect, in the communication system using the common key encryption method, it is possible to efficiently improve the security of the entire communication system by using different operation methods for road-to-vehicle communication and vehicle-to-vehicle communication. .

  The packet signal broadcast from the base station apparatus may be encrypted by an operation method having a higher security level than the packet signal broadcast from the other terminal apparatus. According to this, the processing load of the entire communication system is increased by encrypting the former packet signal, which often contains data requiring high reliability, with an operation method having a higher security level than the latter packet signal. As a result, security can be ensured.

  The packet signal broadcast from the base station apparatus may be encrypted with a communication key generated each time a packet is transmitted. The packet signal notified from the other terminal device may be encrypted with any one of the communication keys in the key table including a plurality of communication keys shared between the terminal devices. According to this, the processing load of the entire communication system is increased by encrypting the former packet signal, which often contains data requiring high reliability, with an operation method having a higher security level than the latter packet signal. As a result, security can be ensured.

  A master key may be shared between the base station apparatus and the terminal apparatus. The packet signal broadcast from the base station apparatus may include a communication key encrypted with the master key. The packet signal broadcast from the other terminal device may include identification information of a communication key selected from the key table. According to this, the processing load of the entire communication system is increased by encrypting the former packet signal, which often contains data requiring high reliability, with an operation method having a higher security level than the latter packet signal. As a result, security can be ensured.

  An electronic signature encrypted by a public key cryptosystem may be added to a message included in a packet signal broadcast from the base station apparatus. According to this, it is possible to improve the security of the packet signal broadcast from the base station apparatus.

  FIG. 23 shows an example of the data structure of the security frame. This is a detailed diagram of the contents of FIG. The security header includes a version (VER), a message type (MT), key information, a nonce, and a data length. The version (VER) indicates the version of the frame format and is a fixed value (= 0). The data length of the version (VER) is 1 byte. The message type (MT) specifies a message type, a data authentication method, and the like. The data length of the message type (MT) is 0.5 bytes. The most significant bit (MSB) of the data length is a management application flag and indicates the presence or absence of a management field. “0” indicates no presence and “1” indicates presence. Bit 2 indicates a data authentication method. “0” indicates a message authentication code (MAC) method, and “1” indicates an electronic signature method. Bit 1 and the least significant bit (LSB) indicate the message format. “0” indicates no authentication data, “1” indicates data with authentication, “2” indicates encrypted data with authentication, and “3” indicates reservation.

  The key information includes a flag, a master key, a communication key, and a key ID. The master key, communication key, and key ID are optional. The flag indicates the presence / absence of a subsequent field in the key information. The data length of the flag is 0.5 bytes. The most significant bit (MSB) is the master key (may be encrypted), bit 2 is the communication key (may be encrypted), bit 1 is the key ID, and the least significant bit (LSB) is reserved (= 0). In each bit, “0” indicates absence and “1” indicates presence. Therefore, when all the bits are “0”, this indicates that the field is omitted. The master key indicates a new master key encrypted with the immediately preceding master key. The data length of the master key is 16 bytes. The communication key indicates a communication key encrypted with the latest master key. The data length of the communication key is 16 bytes. The key ID indicates an identification number for referring to the key table. The data length of the key ID is 1 byte. Nonse includes transmission source information and transmission date and time. The transmission source information indicates the device ID of the transmission source. The data length of the sender information is 4 bytes. The transmission date / time indicates a message transmission date / time or a counter value. The data length of the transmission date / time is 6 bytes. The data length indicates the byte length of the payload. The data length is in the range of 1 to 2 bytes. As in the first embodiment, Nonse may be a random number.

  The payload is subject to concealment by the communication key and message authentication. The payload includes a management application and a service application. The management application shows security management application data and is an option. The service application indicates application data. The data length of the management application and service application is variable.

  The security footer includes data authentication. Data authentication indicates a MAC or electronic signature. The data length for data authentication is 12 bytes for the former and 56 bytes for the latter.

  FIG. 24 illustrates the configuration of the base station apparatus 20 according to the second embodiment. The base station apparatus 20 includes an antenna 21, an RF unit 22, a modem unit 23, a MAC frame processing unit 24, a security processing unit 25, a data generation unit 26, a network communication unit 27, a storage unit 28, and a control unit 29. The security processing unit 25 includes an encryption / decryption unit 256, an encryption unit 257, and a key update unit 258. Hereinafter, the description which overlaps with the base station apparatus 20 which concerns on Example 1 of FIG. 9 is abbreviate | omitted, and a difference with it is demonstrated.

  The network communication unit 27 is connected to the external network 200. The network communication unit 27 receives road information regarding construction and traffic jams from the external network 200. In the present embodiment, a master key for road-to-vehicle communication (hereinafter referred to as a road-to-vehicle master key), a device negative list, an encrypted update key table, and a table update key provided from a system operation management apparatus described later are received. The device negative list is a list of terminal devices 10 to which the common key table provided from the system operation management device should not be added or updated. Devices registered in the device negative list include devices that have been found to be defective and are being collected by manufacturers, and devices that have been reported for theft.

  Further, the network communication unit 27 outputs the processing result by the security processing unit 25 to the external network 200, accumulates it in the storage unit 28, and periodically outputs it to the external network 200.

  The storage unit 28 stores various information (for example, a road-to-vehicle master key, a common key table, a table update key). In the present embodiment, road information acquired from the external network 200, a new road-to-vehicle master key, a device negative list, an encrypted update key table and a table update key, and a terminal device 10 provided from a system operation management device described later. The provided device ID and common key table ID (hereinafter referred to as “table ID” where appropriate) are temporarily stored. The control unit 29 controls processing of the entire base station apparatus 20. The data generation unit 26 generates service application data using information from a sensor, a camera (not shown) or the like, or information stored in the storage unit 28. Then, the message format is designated according to the contents of the service application data, and the generated application data and its data length are output to the security processing unit 25.

  The security processing unit 25 generates or interprets a security frame. When the security processing unit 25 receives the service application data from the data generation unit 26 as the transmission process, the security processing unit 25 outputs the security frame to be output to the MAC frame processing unit 24 and the data stored in the received service application data and the storage unit 28. Generate based on For example, the service application data received from the data generation unit 26 is set in the service application of the payload shown in FIG. 23, and the data length is set to the data length of the security header. Also, the communication key (random number) encrypted with the road-to-vehicle master key is set in the communication key of the key information of the security header. Further, the MAC obtained using the communication key (random number) is set in the security footer. Then, a security frame is generated by adding other security headers. Thereafter, when the specified message format is encrypted data with authentication, the message can be concealed by encrypting the payload and MAC using the communication key (random number).

  The security processing unit 25 receives a security frame from the MAC frame processing unit 24 as a reception process. The security processing unit 25 confirms the contents of the security header in the security frame. If the message type is data with authentication, the encryption / decryption unit 256 executes message verification processing. When the message type is encrypted data with authentication, the encryption / decryption unit 256 executes message decryption processing and performs verification processing. If the message type is plain text, these processes are omitted.

  The security processing unit 25 includes an encryption / decryption unit 256, an encryption unit 257, and a key update unit 258. In this embodiment, in order to pay attention to packet transmission from the base station apparatus 20, attention is paid to processing for generating a security frame that is executed as transmission processing. The process of interpreting the security frame performed as the reception process is the same as the reception process of the terminal device 10 described later. The encryption / decryption unit 256 generates a MAC for the payload using the communication key. The MAC is generated by applying a CBC-MAC algorithm using the AES-CBC mode. Note that Nonce and data length are also used for generating the MAC. Next, when the message format is encrypted data with authentication, the payload and the security footer are encrypted using the communication key. For encryption, an AES_CTR (CountTeR) mode is applied. In this embodiment, the encryption / decryption unit 256 applies the AES-CCM mode using the communication key (random number) when the message format is encrypted data with authentication. Encrypt. Note that without applying the AES-CCM mode, after encryption from the payload, MAC may be added, or only one of MAC addition and encryption may be performed. In addition to the communication key, a nonce and a data length are used for generating the MAC for the payload and for encrypting the payload and the security footer. This is based on CBC-MAC and CCM mode algorithms. By using Nonce, different MAC and encryption results can be obtained even if the payload and communication key are the same.

  The encryption unit 257 encrypts a key transmitted from the base station device 20 to the terminal device 10. Specifically, the communication key (random number) used in the encryption / decryption unit 256 is encrypted with the road-to-vehicle master key. The encryption unit 257 encrypts the new road-to-vehicle master key with the current road-to-vehicle master key when updating the road-to-vehicle master key used in road-to-vehicle communication. The encryption unit 257 encrypts the new table update key with the current table update key when updating the common key table used in the vehicle-to-vehicle communication.

  The key update unit 258 performs a road-to-vehicle master key update process. Further, the common key table to be held by the terminal device 10 is updated. Details of these update processes will be described later.

  FIG. 25 illustrates a configuration of the terminal device 10 mounted on the vehicle 100 according to the second embodiment. The terminal device 10 includes an antenna 11, an RF unit 12, a modem unit 13, a MAC frame processing unit 14, a security processing unit 15, a reception processing unit 161, a notification unit 162, a data generation unit 17, a storage unit 18, and a control unit 19. . The security processing unit 15 includes an encryption / decryption unit 156, a decryption unit 157, and a key update unit 158. Hereinafter, the description which overlaps with the terminal device 10 which concerns on Example 1 of FIG. 10 is abbreviate | omitted, and a difference with it is demonstrated.

  The data generation unit 17 specifies a current position, a traveling direction, a moving speed, and the like of the vehicle 100 on which the terminal device 10 is mounted based on information supplied from a GPS receiver, a gyroscope, a vehicle speed sensor, and the like (not shown). The current position is indicated by latitude / longitude. Since the method for identifying these pieces of information can be realized by a generally known technique, description thereof is omitted here. The data generation unit 17 generates data to be notified to other terminal devices 10 and the base station device 20 based on the specified information, and outputs the generated data (hereinafter referred to as application data) to the security processing unit 15. . Then, the message format is designated according to the contents of the application data, and the generated application data and its data length are output to the security processing unit 15. Further, the specified information is output to the reception processing unit 161 as vehicle information of the own vehicle.

  The storage unit 18 stores various information (for example, a road-to-vehicle master key, a common key table, a table update key). Further, in this embodiment, road information acquired from the base station device 20, vehicle information acquired from itself or another terminal device 10, a new encrypted road-to-vehicle master key acquired from the base station device 20, and encryption The update common key table and the encryption table update key are temporarily held. The control unit 19 controls processing of the entire terminal device 10.

  The security processing unit 15 generates or interprets a security frame as a transmission process. The security processing unit 15 generates a security frame to be output to the MAC frame processing unit 14 based on the data stored in the storage unit 18. For example, application data is set in the service application of the payload shown in FIG. Further, the key ID of the communication key used for generating the MAC is set in the key ID of the key information of the security header, and its own device ID and time are set in Nonce. Also, the MAC generated using the communication key selected from the common key table by the key ID is set in the security footer. Then, a security frame is generated by adding other security headers. When the message format is encrypted data with authentication, the message is concealed by encrypting the payload and MAC using the communication key. If the message type is plain text, these processes are omitted.

  The security processing unit 15 receives a security frame from the MAC frame processing unit 14 as a reception process. The security processing unit 15 confirms the contents of the security header in the security frame. If the message type is data with authentication, the encryption / decryption unit 156 performs message verification processing. When the message format is encrypted data with authentication, the encryption / decryption unit 156 performs message decryption processing and verification processing. If the message format is plain text, these processes are omitted.

  The security processing unit 15 includes an encryption / decryption unit 156, a decryption unit 157, and a key update unit 158. The encryption / decryption unit 156 can perform generation and verification of the MAC for the payload, and encryption and decryption for the payload and the MAC. That is, processing according to the message type message format of the security header is performed, and a function equivalent to the encryption / decryption unit 256 of the base station apparatus 20 is provided. Therefore, the transmission process is the same as that of the encryption / decryption unit 256 of the base station apparatus 20, and thus the description thereof is omitted. The encryption / decryption unit 156 receives a security frame from the MAC frame processing unit 14 as a reception process. When the message format is encrypted data with authentication, the encryption / decryption unit 156 decrypts the payload and the security footer using the communication key. Then, the MAC added to the payload is verified. When the message format is encrypted data, the encryption / decryption unit 156 decrypts the payload using the communication key. Note that the decryption and verification are performed by a decryption algorithm corresponding to the encryption algorithm on the transmission side. When the message format is plain text, the encryption / decryption unit 156 does not perform decryption and verification.

  The decryption unit 157 decrypts the communication key (random number) included in the packet signal notified from the base station device 20 with the road-to-vehicle master key. When the road-to-vehicle master key used in road-to-vehicle communication is updated, the decryption unit 157 decrypts the encrypted new master key included in the packet signal notified from the base station device 20 with the current road-to-vehicle master key. Further, when the common key table used in the inter-vehicle communication is updated, the decryption unit 157 decrypts the encryption table update key included in the packet signal notified from the base station device 20 with the current table update key.

  The key update unit 158 performs a road-to-vehicle master key update process and a vehicle-to-vehicle communication common key table update process to be held by itself (the terminal device 10). Details of these update processes of the key update unit 158 will be described later.

  FIG. 26 is a diagram for explaining a normal message transmission / reception procedure in road-to-vehicle communication using the communication system 500 according to the second embodiment. The encryption / decryption unit 256 of the base station device 20 generates a random number to be used as a communication key. The encryption / decryption unit 256 adds the MAC to the plaintext transmission data using the communication key, and encrypts the transmission data with the MAC. At the same time, the encryption unit 257 encrypts the communication key using the road-vehicle master key. For these encryptions, a common key encryption method is used. The security processing unit 25 generates a packet signal that stores the encrypted transmission data and the encrypted communication key. The packet signal is notified to the outside through the antenna 21 from the RF unit 22 via the MAC frame processing unit 24 and the modem unit 23.

  The RF unit 12 of the terminal device 10 receives the packet signal via the antenna 11. The packet signal is passed to the security processing unit 15 through the modem unit 13 and the MAC frame processing unit 14. The decryption unit 157 decrypts the encrypted communication key stored in the packet signal with the road-to-vehicle master key shared with the base station device 20. The encryption / decryption unit 156 decrypts the encrypted transmission data stored in the packet signal with the decrypted communication key, and performs MAC verification. If the decryption and the MAC verification are successful, the encrypted transmission data is restored to plaintext transmission data.

  This message transmission / reception method has the following various merits. First, since the communication key can be dynamically changed, it is not necessary to hold a plurality of communication keys in advance unlike a message transmission / reception method in vehicle-to-vehicle communication described later. Further, since the random number is encrypted as the communication key, the risk of leakage of the road-to-vehicle master key from the communication path is small. As long as the road-to-vehicle master key is not leaked, basically, the system operation management organization and the road-to-vehicle service provider need not do anything. Even if the road-to-vehicle master key leaks, the risk of leaking the communication key is small unless the master key update mechanism is known. Furthermore, the risk of leakage can be reduced by updating the road-vehicle master key by road-vehicle communication. Since the amount of data to be updated is small, the update of the road-to-vehicle master key can be sufficiently handled by the road-to-vehicle communication.

  FIG. 27 is a diagram for explaining a road-to-vehicle master key update procedure in road-to-vehicle communication using the communication system 500 according to the second embodiment. The system operation management apparatus 300 of the system operation management organization generates a new road-to-vehicle master key for update. The new road-to-vehicle master key for update may be generated periodically, or may be generated when a leakage of the road-to-vehicle master key is detected, or both. The system operation management device 300 issues a master key update notification with a new road-to-vehicle master key to the road-to-vehicle service provider terminal device 400 of the road-to-vehicle service provider.

  When the road-to-vehicle service provider terminal device 400 receives the update notification from the system operation management device 300, it issues an update instruction with a new road-to-vehicle master key to the base station device 20. Note that the new road-to-vehicle master key is transferred between the system operation management organization and the road-to-vehicle service provider, and between the road-to-vehicle service provider and the base station device 20 using a back infrastructure other than the communication system 500. For example, a communication network such as a dedicated line that guarantees security may be used, or the recording medium may be distributed.

  When the key update unit 258 of the base station apparatus 20 receives the new road-to-vehicle master key, it updates its own road-to-vehicle master key. Specifically, the current road-to-vehicle master key is recorded in the storage unit 28 as the previous road-to-vehicle master key, and the received new road-to-vehicle master key is recorded as the current road-to-vehicle master key. Then, control is performed so that the current road-to-vehicle master key (accepted new road-to-vehicle master key) is stored in the packet signal for a certain period after the update. The encryption unit 257 encrypts the current road-to-vehicle master key (accepted new road-to-vehicle master key) using the previous road-to-vehicle master key. For this encryption, a common key encryption method may be used, or a public key encryption method may be used. The new encrypted road-to-vehicle master key is stored in the packet signal and notified.

  The decryption unit 157 of the terminal device 10 decrypts the encrypted road-vehicle master key stored in the packet signal using the current road-vehicle master key held by itself. Upon receiving the road-to-vehicle master key decrypted from the decryption unit 157, the key update unit 158 receives the current road-to-vehicle master key when the received road-to-vehicle master key is newer than the current road-to-vehicle master key held by itself. The new road-to-vehicle master key is also replaced with the road-to-vehicle master key (the road-to-vehicle master key held in the storage unit 18 is also updated).

  An unauthorized base station device (so-called impersonation) basically cannot accept a new road-to-vehicle master key via the back infrastructure. It cannot be sent to the device 10. That is, even when an unauthorized base station device knows the current road-to-vehicle master key (that is, when the current road-to-vehicle master key is leaked), if the new road-to-vehicle master key is not known, an unauthorized message is sent to the terminal device. 10 cannot be sent. In order to know a new road-to-vehicle master key, it is also necessary to know the mechanism for updating the road-to-vehicle master key (that is, leakage of specifications). In addition, when the new road-to-vehicle master key is encrypted by the public key cryptosystem, it is also a condition that the unauthorized base station device knows the secret key. The possibility of satisfying all these conditions is considered very low. Note that even if the current road-to-vehicle master key leaks, there may be an option of leaving it until an unauthorized base station device appears.

  FIG. 28 shows an example of the data structure of a security frame included in a packet generated in road-to-vehicle communication. In FIG. 28, the left security frame shows the data structure when a normal message is transmitted and received, and the right security frame shows the data structure when the road-to-vehicle master key is updated. In the data structure of the security frame at the time of normal message transmission, “version”, “message type”, “communication key”, and “NONSE” are arranged as headers, followed by “payload”, and finally “MAC” as a footer. Is arranged. In this example, “payload” is a MAC target. The communication key (random number) stored in the “communication key” is encrypted by the road-to-vehicle master key and kept secret. “MAC” is generated by the communication key (random number), and “payload” and “MAC” are encrypted and kept secret by the communication key (random number).

  In the security frame data structure at the time of road-to-vehicle master key update, a “master key” is inserted between the “message format” and the “communication key” in comparison with the data structure of the security frame at the time of normal message transmission. The “master key” stores a new road-to-vehicle master key, which is encrypted and concealed by the current road-to-vehicle master key. Also, the version information of the road-to-vehicle master key is stored as “device management” in the “payload”. Others are the same as the security frame at the normal message transmission. The key updating unit 158 of the terminal device 10 updates the road-to-vehicle master key after “MAC” verification is successful by the encryption / decryption unit 156. Returning to FIG. When a normal message is transmitted, 6 (binary: 0110) is set in the key information flag. That is, a communication key and a key ID are set. A communication key (random number) encrypted with the current road-to-vehicle master key is set in the communication key, and version information of the road-to-vehicle master key in which the communication key is encrypted is set in the key ID. When the road-vehicle master key is updated, 14 (binary: 1110) is set in the key information flag. That is, a master key, a communication key, and a key ID are set, the master key encrypted with the master key, the communication key (random number) encrypted with the current road-to-vehicle master key as the communication key, and the communication key as the key ID. The version information of the road-to-vehicle master key that encrypts is set. Note that if the road-to-vehicle master key update can be determined without setting the version of the road-to-vehicle master key that encrypts the communication key in the key ID, it is not necessary to use the key ID. In the key information flag, 4 (binary: 0100) is set when a normal message is transmitted, and 12 (binary: 1100) is set when a road-to-vehicle master key is updated.

  FIG. 29 is a diagram for explaining a normal message transmission / reception procedure in inter-vehicle communication using the communication system 500 according to the second embodiment. The encryption / decryption unit 156 of the terminal device 10 randomly selects one communication key from among a plurality of communication keys stored in at least one common key table. The encryption / decryption unit 156 generates a MAC for the plaintext transmission data using the communication key, and encrypts the transmission data with the MAC. The security processing unit 15 generates a packet signal that stores the encrypted transmission data and the key ID of the selected communication key. The packet signal is notified to the outside via the antenna 11 from the RF unit 12 via the MAC frame processing unit 14 and the modem unit 13.

  The RF unit 12 of another terminal device 10 receives the packet signal via the antenna 11. The packet signal is passed to the security processing unit 15 through the modem unit 13 and the MAC frame processing unit 14. The encryption / decryption unit 156 reads the communication key specified by the key ID stored in the packet signal from the common key table, decrypts the encrypted transmission data stored in the packet signal with the communication key, and performs MAC verification. To do. If the MAC verification is successful, the encrypted transmission data is restored to plain text transmission data.

  This message transmission / reception method has the following various merits. First, since a communication key is used statically, the amount of data communication can be reduced compared to the above-described message transmission / reception method in road-to-vehicle communication. In addition, by holding a plurality of communication keys, the risk of leakage of communication keys from the communication path can be reduced. If the common key table is leaked, the security degradation can be suppressed by adding a new version of the communication key table.

  FIG. 30 shows an example of the data structure of a security frame included in a packet generated in vehicle-to-vehicle communication. In the data structure of the security frame, “version”, “message type”, “key ID”, and “NONSE” are arranged as a header, followed by “payload”, and finally “MAC” as a footer. The In this example, “payload” is a MAC target. “MAC” is generated by the communication key in the common key table specified by “key ID”, and “payload” and “MAC” are encrypted and concealed by the communication key.

  FIG. 31 shows the format of the common key table. “Field”, “Table ID”, “Number of key”, “Table Master”, and “Key list” are provided in “Field” of the common key table. “Key 0” to “Key 15” are provided in the “Key list”. Note that the number of keys included in one common key table is not limited to 16.

  In “Version”, “Table ID”, and “Number of key”, a 1-byte area is defined. An area of 16 bytes is defined in “Table Master”, “Key 0” to “Key 15”.

  A table ID is set in “Table ID”. In “Number of keys”, the number of keys in the table is set. A table update key is set in “Table Master”. In “Key 0”, the AES key with the key number 0 is set. In “Key 1”, the AES key with the key number 1 is set. The same applies to “Key 15” below. A common key other than AES may be used. Further, when the number of keys included in the common key table is constant, “Number of key” may be omitted. Furthermore, the table update key may omit “Table Master” as a key shared in advance.

  FIG. 32 shows an example of a common key table operation method. FIG. 32 illustrates an example in which the terminal device 10 holds a storage area that can store four common key tables. Of course, the number of common key tables held by the terminal device 10 is not limited to four. In the initial state (at the time of shipment), the terminal device 10 holds one common key table (version = 1, table ID = 1). The terminal device 10 on the transmission side selects one communication key from the common key table (version = 1, table ID = 1) and uses it for MAC generation and encryption.

  When this common key table (version = 1, table ID = 1) leaks or when the possibility arises, a new common key table (version = 1, table ID = 2) is added. The terminal device 10 on the transmission side selects one communication key from the latest common key table (version = 1, table ID = 2) and uses it for MAC generation and encryption. When a similar event occurs, a new common key table is added in the order of the common key table (version = 1, table ID = 3) and the common key table (version = 1, table ID = 4).

  If the last added common key table (version = 1, table ID = 4) is leaked after the four common key tables are held in the terminal device 10, or if the possibility occurs, the oldest common key table is stored. A new common key table (version = 2, table ID = 1) is overwritten (updated) on the key table (version = 1, table ID = 1). Thereafter, this process is repeated. In FIG. 32, the common key table surrounded by a thick line is a table used for transmission, indicating that it is a table subject to regular authentication, and the common key table surrounded by a thin line is a reception-only table. Yes, indicates that this is a semi-authentication target table. As described above, by operating the common key table, compatibility can be maintained and operation without contradiction can be realized.

  FIG. 33 is a diagram for explaining addition or update of a common key table. In this embodiment, the common key table to be added or updated is generated by the system operation management apparatus 300 of the system operation management organization. The system operation management apparatus 300 encrypts the common key table with the table update key. The table update key is also stored in the common key table. Furthermore, information on the unauthorized terminal device 10 is also collected in the system operation management apparatus 300, and the system operation management apparatus 300 also generates the above-described device negative list.

  The system operation management apparatus 300 provides the above-described device negative list, encrypted common key table, and table update key to the road-to-vehicle service provider terminal device 400 of the road-to-vehicle service provider and the service factory terminal device 450 of the service factory, respectively. To do. The road-to-vehicle service provider terminal device 400 provides the base station device 20 with the device negative list, encrypted common key table, and table update key received from the system operation management device 300. The service factory is mainly a facility for maintaining automobiles. The service factory terminal device 450 of the service factory provides the device negative list, the encrypted common key table, and the table update key received from the system operation management device 300 to the low-power base station device 451 installed in the facility.

  The low power base station device 451 is not a roadside device that notifies the terminal device 10 of real-time road information, but is a dedicated device that wirelessly transmits information related to system operation such as a common key table to a specific terminal device 10. In addition, you may provide the information regarding system operation to a terminal device 10 from a service factory via a recording medium.

  The base station device 20 that has received the device negative list, the encrypted common key table, and the table update key from the road-to-vehicle service provider terminal device 400 acquires the device ID and the table ID from the terminal device 10. Then, the table update key received from the road-to-vehicle service provider terminal device 400 is added to the device ID and the table ID, and they are encrypted. The base station apparatus 20 broadcasts a packet signal that stores the encrypted device ID, table ID, and table update key. In addition, the base station device 20 notifies the encrypted common key table received from the road-to-vehicle service provider terminal device 400. Note that when the device ID of the terminal device 10 registered in the device negative list is received, these processes are not executed.

  Similarly to the base station apparatus 20, the low-power base station apparatus 451 also transmits the encrypted common key table received from the service factory terminal apparatus 450 and the table update key to the terminal apparatus 10. Note that in the low power base station apparatus 451, since the range in which radio waves reach is limited, it is not necessary to encrypt and transmit the table update key, and the table update key may be transmitted without encryption. .

  The terminal device 10 decrypts the encrypted common key table received from the base station device 20 or the low power base station device 451 with the table update key received in the same manner. The details of the procedure for adding or updating the encryption common key table between the base station apparatus 20 and the terminal apparatus 10 will be described later. In FIG. 33 as well as FIG. 27, between the system operation management organization and the road-to-vehicle service provider, between the system operation management organization and the service factory, between the road-vehicle service provider and the base station device 20, and between the service plant and the terminal device 10. The exchange of the common key table and the table update key is performed using a back infrastructure other than the communication system 500.

  FIG. 34 is a diagram for explaining a common key table addition or update procedure in road-to-vehicle communication using the communication system 500 according to the second embodiment. In FIG. 34, it is assumed that the base station apparatus 20 (roadside device) holds an encryption common key table for addition or update, its table update key, and a device negative list. The base station device 20 receives a packet signal storing the device ID (L) and the table ID (k) from the terminal device 10 (vehicle equipment L). Here, the table ID (k) indicates the table ID of the latest common key table currently used.

  The key update unit 258 of the base station device 20 checks whether or not the device ID (L) stored in the received packet is registered in the device negative list. If registered, the subsequent processing is not executed. If not registered, the encryption unit 257 concatenates the table update key (m) to the device ID (L) and the table ID (k) received from the terminal device 10, and the latest common key table currently in use. The table update key (k) is used for encryption. The encrypted data is stored in the packet signal. The packet signal is notified to the outside as road-to-vehicle communication. At the same time, an encrypted common key table (m) corresponding to the encrypted table update key (m) is also stored in the packet signal and is notified to the outside by road-to-vehicle communication.

  In the terminal device 10, the encrypted device ID (L), table ID (k), and table update key (m) are extracted from the received packet signal, and the decryption unit 157 uses them as the table update key (k). Decrypt. Also, the encrypted common key table (m) is extracted from the other received packet signal, and the decryption unit 157 decrypts the encrypted common key table (m) with the table update key (m). The key update unit 158 adds or updates the decrypted common key table (m) to the table storage area as the latest common key table. When the MAC is added to the common key table (m), the MAC is verified with the table update key (m), and is added or updated on the condition that the MAC is successful.

  As described above, since the common key table has a large amount of data, it is effective to use not only road-to-vehicle communication but also a dedicated base station apparatus for addition or update. Moreover, risk distribution can be achieved by using the table update key that the terminal apparatus 10 and the base station apparatus 20 actually hold. Further, by using the device negative list, provision of a new common key table to an unauthorized terminal device can be avoided, and the risk of message leakage can be reduced.

  As described above, according to the second embodiment, in the communication system using the common key encryption method, the security of the entire communication system is efficiently improved by using different operation methods for road-to-vehicle communication and vehicle-to-vehicle communication. Can be improved. More specifically, the packet signal broadcast from the base station apparatus is encrypted by an operation method with a higher security level than the packet signal broadcast from the terminal apparatus. The former packet signal has a relatively large data size, but the latter packet signal has a small margin. In addition, the former packet signal often includes data that requires higher reliability than the latter packet signal.

  Thus, by using the common key encryption method for both road-to-vehicle communication and vehicle-to-vehicle communication, the processing load can be reduced, and a low-cost communication system can be constructed while ensuring real-time performance. In this communication system, an efficient security system can be constructed by changing the operation method of encryption depending on the transmission source of information.

  Moreover, although the road-to-vehicle master key used in road-to-vehicle communication has been described as one, a common key table may be used in the same manner as the communication key used in vehicle-to-vehicle communication. At this time, it is desirable to select different keys for the inter-vehicle communication key and the road-vehicle master key used for road-vehicle communication. In order to specify the common key table, the key ID in FIG. Furthermore, although the table update key is updated every time the common key table is updated, the table update key shared in advance may not be updated. In this case, if a unique table update key is held for each terminal device 10, safety is ensured. The second embodiment has been described above. This embodiment is an exemplification, and it will be understood by those skilled in the art that various modifications can be made to the combination of each component and each processing process, and such modifications are also within the scope of the present invention. .

  The common key table operation method described with reference to FIGS. 32 to 34 basically provides the common key table to the terminal device 10 one by one. In the modification described below, a plurality of common key tables are provided to the terminal device 10 at a time, and the terminal device 10 holds the provided plurality of common key tables. Then, the terminal device 10 sequentially switches and uses the plurality of common key tables until there is no usable common key table. When the terminal device 10 has no available common key table, the terminal device 10 receives one or more new common key tables and holds them. In response to a request from a management system (not shown), one or more new common key tables are provided and held.

(Example 3)
FIGS. 35A and 35B are diagrams illustrating a common key table held in the terminal device 10 according to the third embodiment (part 1). FIGS. 36A and 36B are diagrams illustrating the common key table held in the terminal device 10 according to the third embodiment (part 2). In the third embodiment, the road-to-vehicle master key used in road-to-vehicle communication is also selected from the common key table in the same manner as the communication key used in vehicle-to-vehicle communication. Hereinafter, an example in which the terminal apparatus 10 has a storage area (hereinafter referred to as a storage area) that can store eight common key tables and holds five common key tables will be described. In the third embodiment, the number of communication keys held in one common key table is eight. Note that the number of common key tables held in the terminal device 10 and the number of communication keys held in one common key table only need to be plural, and are not limited to the above numbers. The number of common key table storage areas may be equal to or greater than the number of common key tables held in the terminal device 10. That is, the number identified by the table ID and the number of storage areas of the common key table do not need to match, and may be more or less. Further, as described above, the present invention can be applied not only to the inter-vehicle communication key but also to the road-to-vehicle master key.

  The common key table is managed by version and table ID. The common key table specified by the same table ID with a different version is not used at the same time. The larger version is always used. The table ID is set as a remainder system of N (N is a natural number). In the third embodiment, N = 8. For example, the table IDs of the first common key table and the ninth common key table are 0. The version is incremented each time a new common key table with the same table ID is generated. Therefore, the former is 0, and the latter is 1.

  Of a plurality of common key tables held in the storage area, one is designated as a transmission common key table (hereinafter referred to as a transmission key table), and a plurality of reception is a common key table (hereinafter referred to as a reception key table). Specified). The plurality of reception key tables include a transmission key table, and include a common key table from the transmission key table to n (n is a natural number, n <N) generation future. The plurality of reception key tables may include common key tables up to m generations (m is 0 or a natural number, m + n <N). The table ID of the i-th generation common key table is {(transmission key table table ID + i) mod N}, and the table ID of the j-th generation common key table is {(transmission key table table ID-j). ) Mod N}. The version of the i-generation future common key table is at least when the table ID is larger than the table ID of the transmission key table, when the table ID is smaller than the version of the transmission key table, and smaller than the table ID of the transmission key table The value must exceed the version of the transmission key table. In addition, the version of the common key table in the past j generations is at least when the table ID is larger than the table ID of the transmission key table, less than the version of the transmission key table, and when the table ID is smaller than the table ID of the transmission key table. , It must be lower than the version of the transmission key table. When a plurality of common key tables having the same table ID held in the storage area are held, those having a small version value (old ones) are treated as invalid (not held).

  Even if the system operation management apparatus 300 instructs to switch the transmission key table, the transmission key table is not switched simultaneously in all the terminal apparatuses 10. There is a time difference in the timing at which the transmission key table is switched between the terminal devices 10. For example, in the terminal device 10 mounted on the vehicle 100 that has not been used for a long time, two or more past common key tables may be set in the transmission key table. When this vehicle 100 is used, the terminal device 10 mounted on another vehicle 100 receives the packet signal processed by the common key table of two generations in the past. In operation of the encryption system, the narrower the range of the reception key table, the higher the security. However, there are many cases where transmission data from the legitimate terminal device 10 cannot be decrypted. The range of the reception key table is set in consideration of both requests.

  When the switching cycle of the transmission key table is long (for example, several years), the reception key table may be composed of the transmission key table and the next common key table (n = 1). When the transmission key table switching cycle is short (for example, within one year), the reception key table includes the transmission key table, the next common key table (n = 1), and the subsequent common keys. And a table (n> 1). As the switching period is shorter, n is increased, and many common key tables may be incorporated into the reception key table. When the switching period is short, the transmission key table varies greatly among the plurality of terminal devices 10. On the other hand, mismatching of the transmission key table can be reduced by increasing the number of common key tables incorporated in the reception key table. Further, m is suitably 1 or 0.

  FIG. 35A shows a common key table held by the terminal device 10 shipped from the start of operation of the encryption service using the common key table in inter-vehicle communication to the first year. FIG. 35B shows a common key table held by the terminal device 10 shipped in the second to third years. FIG. 36A shows a common key table held by the terminal apparatus 10 shipped in the 10th to 11th years. FIG. 36B shows a common key table held by the terminal device 10 shipped in the 12th to 13th years.

  From the start of operation to the first year, the common key table (version = 0, table ID = 0) is used as the transmission key table. Each terminal device 10 selects one communication key from the common key table (version = 0, table ID = 0) and uses it for inter-vehicle communication. In the second to third years, the common key table (version = 0, table ID = 1) is used as the transmission key table. In the fourth to fifth years, the common key table (version = 0, table ID = 2) is used as the transmission key table. As described above, in the third embodiment, the transmission key table is sequentially switched every two years. The switching of the common key table is uniformly managed by the system operation management apparatus 300.

  Since each terminal apparatus 10 holds five common key tables at the time of shipment, basically, each terminal apparatus 10 can use the encryption system without additional updating of the common key table for 8 to 10 years after shipment. However, in order to use this encryption system after the 8th to 10th years from the shipment, it is necessary to additionally update a new common key table before the lapse of 8 to 10 years. That is, it is necessary to add and update a new common key table before there is no usable common key table.

  FIGS. 37A and 37B are diagrams illustrating a state of switching of the common key table according to the third embodiment (part 1). It is a state of switching of the common key table in the terminal device 10 shipped according to FIG. FIGS. 38A and 38B are diagrams illustrating a state of switching the common key table according to the third embodiment (part 2). FIG. 36C shows how the common key table is switched in the terminal device 10 shipped. In FIG. 37A, the common key table (version = 0, table ID = 0) is designated as the transmission key table. When switching of the transmission key table is instructed in this state, the key updating unit 158 switches the transmission key table to the common key table (version = 0, table ID = 1) as shown in FIG. . In FIG. 38A, the common key table (version = 0, table ID = 7) is designated as the transmission key table. When switching of the transmission key table is instructed in this state, the key update unit 158 switches the transmission key table to the common key table (version = 1, table ID = 0) as shown in FIG. .

  Thus, when switching of the transmission key table is instructed, the key update unit 158 switches to the next value in the remainder system with the table ID of N (8 in the present embodiment 3). However, the version of the common key table after switching needs to be the same or +1. In the example shown in FIGS. 37A and 37B, the version is the same before and after switching. In the example shown in FIGS. 38A and 38B, the version is incremented by 1 before and after switching. When a plurality of versions of the common key table coexist in the storage area, it may be handled that there is no version of the common key table older than the version of the transmission key table in terms of implementation. If the switching is further performed three times after the switching of FIGS. 37A to 37B, the transmission key table is switched to the common key table (version = 0, table ID = 4). At this time, since the next generation future common key table is not held in the storage area, by adding a new generation future common key table, the terminal device 10 shipped according to FIG. The common key table can be updated. In addition, with a margin, the transmission key table may be updated when either the common key table (version = 0, table ID = 3) or (version = 0, table ID = 4). In the third embodiment, the update cycle by updating the common key table in the second embodiment is long (in the third embodiment, five times that in the second embodiment). Therefore, since the common key table can be updated by maintenance without using road-to-vehicle communication, there is an advantage that operation without reducing traffic of road-to-vehicle communication can be performed.

  FIGS. 39A and 39B are diagrams illustrating an emergency update state of the common key table according to the third embodiment. FIGS. 40A and 40B are diagrams illustrating a state of switching after the emergency update of the common key table according to the third embodiment. FIG. 35A is a state of emergency update of the common key table in the terminal device 10 to be shipped and switching after the emergency update according to FIG. In an emergency (for example, when a common key table is leaked), the key update unit 158 holds the future common key table generationally from the transmission key table at that time, regardless of the normal switching period. Update them. Also, the key update unit 158 adds a new common key table that is generationally future than the updated common key table. The common key table to be updated or added is provided from the system operation management apparatus 300. The version of the common key table to be updated or added is incremented by 1 to the version of the transmission key table. As is clear from the fact that the table ID is a residue system of N, the version of the generationally common key table is that the table ID of the generationally common key table is greater than the table ID of the transmission key table. When one is smaller, it is +2 to the version of the transmission key table.

  FIG. 39A shows an example of a case where leakage occurs when the common key table (version = 0, table ID = 2) is a transmission key table. An emergency update is performed for this leak. FIG. 39B shows the state of the storage area after the emergency update. In the example shown in FIG. 39B, the key update unit 158 converts the next common key table (version = 0, table ID = 3) of the transmission key table into the common key table (version = 1, table ID = 3). Rewrite and rewrite the next common key table (version = 0, table ID = 4) to a common key table (version = 1, table ID = 4). Further, a common key table (version = 1, table ID = 5) and a common key table (version = 1, table ID = 6) are added. That is, four new common key tables are stored in the future generationally from the transmission key table. In FIG. 39 (b), these four common key tables are drawn with bold lines.

  FIG. 40 (a) is the same as FIG. 39 (b). In FIG. 40B, after four new common key tables are updated and added, the transmission key table is changed from the common key table (version = 0, table ID = 2) in response to the instruction to switch the transmission key table. A state of switching to the common key table (version = 1, table ID = 3) is depicted.

  FIG. 41 is a diagram illustrating a first switching example of the transmission key table according to the third embodiment. The first switching example is applied when a transmission key table and past and future common key tables are incorporated in the reception key table. In the following description, it is assumed that one each of past and future common key tables is incorporated. That is, it is assumed that there are three reception key tables. A plurality of future common key tables may be incorporated.

  During normal times, the key update unit 158 switches the transmission key table every normal switching period (two years in the third embodiment). When an emergency occurs, the key updating unit 158 updates the future common key table to a new common key table provided from the system operation management device 300 while maintaining the current transmission key table. This update is referred to as an emergency update in this specification. This update period is set so that a period necessary for updating the transmission key table can be secured regardless of the remaining switching period of the normal switching period. For example, 80% of the terminal devices 10 of all the terminal devices 10 may be set to a period for completing the update. The remaining terminal devices 10 are individually updated as recall products.

  In the first switching example, the key update unit 158 invalidates the past common key table at the time of emergency update. The system operation management apparatus 300 issues a past common key table deletion command or provides a new common key table for rewriting all the common key tables stored in the terminal apparatus 10. In the latter case, the key update unit 158 overwrites all the stored common key tables with the new common key table.

  The first switching period (hereinafter referred to as an emergency switching period) of the transmission key table after the end of the emergency update period is set shorter than the normal switching period. That is, the use period of the first transmission key table used after the end of the emergency update period is set shorter than the normal use period. In the first switching example, the common key table that is one unit past the transmission key table is also included in the reception key table. Therefore, in the emergency switching period, reception of data encrypted using the common key table that was the transmission key table at the time of occurrence of an emergency situation is permitted. Since this common key table may be leaked or leaked, it is preferable to shorten the period during which reception is allowed as much as possible. Therefore, in the first switching example, the emergency switching period is set shorter than the normal switching period. In the switching period after the emergency switching period, the reception of data encrypted using a common key table that may be leaked or leaked is not allowed, and therefore the switching period after the emergency switching period is a normal switching period.

  FIG. 42 is a diagram illustrating a second switching example of the transmission key table according to the third embodiment. The second switching example is applied when a transmission key table and a future common key table are incorporated in the reception key table.

  During normal times, the key update unit 158 switches the transmission key table every normal switching period. When an emergency situation occurs, the key update unit 158 urgently updates the future common key table generationally than that while maintaining the current transmission key table. In the second switching example, the emergency switching period is not set as in the first switching example. In the second switching example, since the past common key table is not included in the reception key table from the transmission key table, reception of data encrypted using the common key table that may be leaked or leaked is permitted. do not do. Therefore, it is not necessary to make the first switching period after the emergency update period shorter than the normal switching period.

  FIG. 43 is a diagram for explaining addition or update of the common key table according to the third embodiment. The system operation management apparatus 300 of the system operation management organization generates a plurality of common key tables and provides them to the vehicle manufacturer's common key table setting apparatus 460. The common key table setting device 460 writes the provided plurality of common key tables in the terminal device 10 newly installed in the vehicle 100. The types of the plurality of common key tables to be written differ depending on the shipping time.

  The system operation management device 300 issues a table switching instruction to the road-to-vehicle service provider terminal device 400 when the transmission key table switching timing comes. The road-to-vehicle service provider terminal device 400 transmits the table switching instruction received from the system operation management device 300 to the base station device 20. The base station device 20 broadcasts the table switching instruction received from the road-to-vehicle service provider terminal device 400 through road-to-vehicle communication. The terminal device 10 already mounted on the vehicle 100 switches the transmission key table when receiving the table switching instruction. In addition, the terminal device 10 broadcasts the received table switching instruction through inter-vehicle communication. When receiving another table switching instruction, the other terminal device 10 switches the transmission key table. The table switching instruction from the system operation management apparatus 300 may be transmitted to the existing terminal apparatus 10 via the common key table setting apparatus 460 and the new terminal apparatus 10.

  Note that the switching timing of the transmission key table may be determined and switched by the terminal device 10. Here, the master key used in road-to-vehicle communication is also selected from the common key table in the same manner as the communication key used in vehicle-to-vehicle communication. The key ID in FIG. 23 is also used for road-to-vehicle communication. Note that the range of the communication key and the master key used in vehicle-to-vehicle communication may be divided in advance. In this case, the number of keys belonging to both the common key tables does not have to be the same, and the number of road-to-vehicle master keys may be smaller than the communication key from the viewpoint of key life.

  The system operation management device 300 issues a table switching instruction to the road-to-vehicle service provider terminal device 400 when the transmission key table switching timing comes. When receiving the table switching instruction from the system operation management apparatus 300, the road-to-vehicle service provider terminal apparatus 400 issues a table switching instruction for the transmission key table to the base station apparatus 20. Upon receiving the table switching instruction, the base station apparatus 20 switches the transmission key table used by itself. Then, a master key is selected from the switched common key table, and a packet signal including the encrypted data with authentication or the security frame of the data with authentication is notified.

  The terminal device 10 already mounted on the vehicle 100 performs reception processing when receiving the packet signal. The security processing unit 15 verifies the MAC of the security frame included in the received packet signal. If the verification is successful, the table ID is extracted from the key ID of the received security frame and compared with the table ID of its own transmission key table. When a future generation common key table is used rather than its own transmission key table, the transmission key table is switched to that. Moreover, you may make it switch based on the packet signal received by the vehicle-to-vehicle communication from the other terminal device 10. FIG.

  The terminal device 10 already mounted on the vehicle 100 performs reception processing when receiving the above-described packet signal. The security processing unit 15 verifies the MAC of the security frame included in the received packet signal. If the verification is successful, the table ID is extracted from the key ID of the received security frame, and if a future generation common key table is used from its own transmission key table, the table ID and the transmission source device ID are retained. To do. For example, when it is determined that the same common key table of the future generation is used from ten other terminal apparatuses 10, the key table for transmission is switched to that. Both switching judgments can be used together. Since the transmission key table of the new terminal device 10 is provided by switching in advance, the switching can be propagated even in a place where the base station device 20 is not present. That is, even if the vehicle moves in a place where the base station device 20 is not present, the vehicle is switched by receiving a packet signal from another terminal device 10 after switching. Note that MAC verification is performed based on successful verification of packet signals received from a plurality of (for example, ten) different base station devices 20 or other terminal devices 10 in view of the fact that the authenticity of the transmission source cannot be confirmed. Switch the trust key table. In addition, as in the first embodiment and the first to sixth modifications thereof, when the electronic signature is attached to the packet signal for road-to-vehicle communication, the received digital signal can be confirmed in consideration of the authenticity of the sender. The judgment criterion for switching between when the electronic signature verification is successful and when the MAC verification is successful may be changed. For example, when the verification of the electronic signature of the security frame included in the packet signal received from the base station apparatus 20 is successful, or the security included in the packet signal received from a plurality of (for example, ten) other terminal apparatuses 10 This is when the frame MAC is successfully verified.

  Further, when an emergency occurs, the system operation management device 300 transmits a new common key table to the existing terminal device 10 via the road-to-vehicle service provider terminal device 400 and the base station device 20, and the common key table setting device. 460 and the new terminal device 10 are transmitted to the existing terminal device 10. When updating the common key table, the technique shown in FIGS. 32 to 33 can be used.

  The common key table may be updated as follows. First, the terminal device 10 transmits an update request signal including its own device ID to the system operation management device 300. The system operation management apparatus 300 encrypts a new common key table with the public key corresponding to each device ID and transmits it to the terminal apparatus 10. Both communication may be performed via the road-to-vehicle service provider terminal device 400 and the base station device 20, or may be performed via another network. When the terminal device 10 receives the encrypted common key table, the terminal device 10 decrypts it with the unique secret key.

  Further, a common key corresponding to each device ID may be used instead of the public key corresponding to each device ID. The system operation management apparatus 300 receives each device ID, encrypts a new common key table using the common key corresponding to the device ID, and transmits it to the terminal device 10. At this time, the communication path between the terminal apparatus 10 and the system operation management apparatus 300 is not particularly limited.

  As described above, according to the third embodiment, a plurality of common key tables are provided to the terminal device 10 at a time, and the number of update additions of the common key table is reduced by switching and using the table according to the table switching instruction. it can. Therefore, the risk of leakage can be reduced. When leakage occurs, security can be ensured by urgently updating the common key table.

  10 terminal device, 11 antenna, 12 RF unit, 13 modem unit, 14 MAC frame processing unit, 15 security processing unit, 151 verification unit, 151a certificate verification unit, 151b message verification unit, 151c digest holding unit, 151d authentication key holding Unit, 151e status management unit, 152 decoding unit, 161 reception processing unit, 162 notification unit, 17 data generation unit, 18 storage unit, 19 control unit, 20 base station device, 21 antenna, 22 RF unit, 23 modulation / demodulation unit, 24 MAC frame processing unit, 25 security processing unit, 26 data generation unit, 251 signature unit, 252 encryption unit, 27 network communication unit, 28 storage unit, 29 control unit, 100 vehicle, 202 area, 204 area outside, 500 Communication system, 156 encryption / decryption unit, 157 decryption unit, 158 key update unit, 256 encryption / decryption unit, 257 encryption unit, 258 key update unit, 27 network communication unit, 28 storage unit, 29 control unit, 300 system operation management device, 400 Road-to-vehicle service provider terminal device, 450 Service factory terminal device, 451 Low power base station device.

  The terminal device according to the present invention can be used for ITS.

The present invention relates to a communication technique, and more particularly to an on- vehicle device that transmits and receives a signal including predetermined information.

Claims (10)

A receiver that receives a plurality of packet signals broadcast from the wireless device;
A first verification unit for verifying a certificate including a public key included in the packet signal;
Comprising: information for specifying a certificate included in the packet signal verified by the first verification unit; and a digest holding unit that holds a public key.
When the packet signal including the certificate specified by the information specifying the certificate held in the digest holding unit is received, the first verification unit receives the certificate including the public key included in the packet signal. A terminal device characterized by skipping verification. A second verification unit for verifying a signed message included in the packet signal;
A status management unit for holding a verification result in the second verification unit for a packet signal including a certificate specified by information specifying a certificate held in the digest holding unit;
When the second verification unit verifies the packet signal including the certificate specified by the information specifying the certificate held in the digest holding unit, the second verification unit holds the verification result in the status management unit, and further, the status The terminal device according to claim 1, wherein verification of a message with a signature of at least one of the packet signals is skipped while verification is held in the management unit.   The terminal according to claim 2, wherein the second verification unit determines that the signed message is approved when the verification of the signed message of at least one of the packet signals is skipped. apparatus. Among a plurality of packet signals received during a wireless device signal reception period from one wireless device, the certificate is included in at least the first packet signal of the wireless device signal reception period, and specific information for identifying the certificate Is included in a packet signal that does not include the certificate,
The second verification unit, when the verification of the signed message included in the first packet signal among a plurality of packet signals received in one wireless device signal reception period is successful, is a proof specified by the specific information 3. The terminal device according to claim 2, wherein the verification of the signed message of the received packet signal including the specific information or the specific information is skipped. Among a plurality of packet signals received from one wireless device during the wireless signal reception period, the electronic signature is included in at least the first packet signal of the wireless device signal reception period, and the message authentication code is at least the wireless device signal reception period. Included in the packet signal other than the first packet signal of
The terminal device includes a second verification unit for verifying a message with an electronic signature included in a packet signal;
A third verification unit for verifying a message with a message authentication code included in a packet signal other than the packet signal;
The terminal device according to claim 1, further comprising: A receiver that receives the encrypted packet signal;
A decoding unit for decoding the packet signal,
The packet signal is encrypted by a common key encryption method, and is encrypted by a different operation method between a packet signal broadcast from a base station device and a packet signal broadcast from another terminal device. Terminal device to do.   The terminal apparatus according to claim 6, wherein the packet signal broadcast from the base station apparatus is encrypted by an operation method having a higher security level than the packet signal broadcast from the other terminal apparatus. The packet signal broadcast from the base station device is encrypted with a communication key generated each time a packet is transmitted,
7. The packet signal broadcast from the other terminal device is encrypted with any one of communication keys in a key table including a plurality of communication keys shared between the terminal devices. Or the terminal device of 7. A master key is shared between the base station device and the terminal device,
The packet signal broadcast from the base station device includes a communication key encrypted with the master key,
The terminal device according to claim 8, wherein the packet signal broadcast from the other terminal device includes identification information of a communication key selected from the key table.   10. The terminal apparatus according to claim 6, wherein an electronic signature encrypted by a public key cryptosystem is added to a message included in a packet signal broadcast from the base station apparatus. .