WO2011148744A1 - 通信システム、車載端末、路側装置 - Google Patents

通信システム、車載端末、路側装置 Download PDF

Info

Publication number
WO2011148744A1
WO2011148744A1 PCT/JP2011/059808 JP2011059808W WO2011148744A1 WO 2011148744 A1 WO2011148744 A1 WO 2011148744A1 JP 2011059808 W JP2011059808 W JP 2011059808W WO 2011148744 A1 WO2011148744 A1 WO 2011148744A1
Authority
WO
WIPO (PCT)
Prior art keywords
list
vehicle
certificate
roadside device
vehicle terminal
Prior art date
Application number
PCT/JP2011/059808
Other languages
English (en)
French (fr)
Inventor
英里子 安藤
健 長沼
大和田 徹
Original Assignee
ルネサスエレクトロニクス株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ルネサスエレクトロニクス株式会社 filed Critical ルネサスエレクトロニクス株式会社
Priority to EP11786444.7A priority Critical patent/EP2579498A4/en
Priority to US13/698,359 priority patent/US8819418B2/en
Priority to CN201180025801.8A priority patent/CN102907039B/zh
Priority to JP2012517200A priority patent/JP5261614B2/ja
Publication of WO2011148744A1 publication Critical patent/WO2011148744A1/ja
Priority to US14/310,423 priority patent/US9135820B2/en
Priority to US14/829,131 priority patent/US9601016B2/en

Links

Images

Classifications

    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/123Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096783Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is a roadside individual element
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84Vehicles

Definitions

  • the present invention relates to a communication technique for guaranteeing the validity of a message using a public key cryptosystem when communicating between roads and vehicles or between vehicles.
  • the public key cryptosystem is a scheme in which encryption / decryption is performed using two pairs of a secret key and a public key.
  • the secret key must be managed secretly, but the public key may be disclosed. Therefore, in an electronic signature using a public key cryptosystem, a message transmitting side transmits data obtained by encrypting a hash value of a message with a secret key as a signature together with the message.
  • the message recipient obtains the sender's public key and decrypts the signature.
  • the signature is verified based on whether or not the decrypted value is equal to the hash value generated from the received message.
  • a certificate authority gives a signature to a public key. If the certificate authority has a hierarchical structure, the higher-order certificate authority repeatedly signs the public key of the lower-order certificate authority.
  • the regional certification authority manages a plurality of roadside devices and issues certificates to the managed roadside devices. Further, the roadside device periodically transmits the certificate of the regional certification authority (regional certificate) to the in-vehicle terminal.
  • the in-vehicle terminal receives the message, the time required for verification can be shortened by trusting the regional certificate and verifying the signature of the message while receiving the same regional certificate.
  • An object of the present invention is to provide a technique for reducing certificate verification time in a communication system.
  • a certification authority that performs authentication, a roadside device arranged on the roadside, an in-vehicle terminal mounted on an automobile, a first server that collects position information of the in-vehicle terminal, a roadside device for which the certificate has expired, and information management of the in-vehicle terminal
  • a communication system is configured including the second server that performs the above.
  • the in-vehicle terminal transmits its position information to the first server.
  • the certificate authority obtains information on the in-vehicle terminal having a high possibility of appearing according to the place and time from the first server, and determines whether the certificate of the in-vehicle terminal obtained from the first server has been revoked.
  • FIG. 1 is a block diagram illustrating an example of the overall configuration of a communication system according to the present invention.
  • FIG. 2 is a block diagram illustrating a configuration example of a certificate authority in the communication system illustrated in FIG. 1.
  • FIG. 2 is a block diagram illustrating a configuration example of an in-vehicle terminal in the communication system illustrated in FIG. 1. It is a functional example block diagram of the roadside apparatus in the communication system shown by FIG.
  • FIG. 2 is a block diagram illustrating a configuration example of a certificate authority in the communication system illustrated in FIG. 1. It is a flowchart of creation and distribution of a white list and a black list. It is a data format explanatory drawing of a white list and a black list.
  • a communication system (10) includes an authentication station (100) that performs authentication, a roadside device (110) arranged on the roadside, and an in-vehicle terminal (120 ), A first server (130) for collecting location information of the in-vehicle terminal, a roadside device for which the certificate has expired, and a second server (140) for managing information on the in-vehicle terminal.
  • the in-vehicle terminal transmits its position information to the first server.
  • the certificate authority obtains information on the in-vehicle terminal having a high possibility of appearing according to the place and time from the first server, and determines whether the certificate of the in-vehicle terminal obtained from the first server has been revoked.
  • the first list (white list) of in-vehicle terminals whose certificates are valid for each location and time based on the confirmation result
  • the second list black list of in-vehicle terminals whose certificates have expired Is transmitted to the roadside device and the in-vehicle terminal device.
  • the roadside device and the in-vehicle terminal device verify the certificate using the received first list and second list.
  • authentication authority acquires the information of the vehicle-mounted terminal with high possibility of appearance according to a place and time from the said 1st server, and the certificate of the vehicle-mounted terminal acquired from the said 1st server is revoked.
  • the second server confirms whether the certificate is valid, and based on the confirmation result, the first list of in-vehicle terminals with valid certificates and the second list of in-vehicle terminals with invalid certificates are obtained for each location and time. Create it and send it to the roadside device and the in-vehicle terminal device. Since the roadside device and the in-vehicle terminal device can perform certificate verification using the received first list and second list, the certificate verification time can be shortened.
  • the roadside device and the in-vehicle terminal check the effective location and effective time of the first list and the second list, and if the device is outside the effective location or the effective time When the time has elapsed, the first list and the second list can be deleted. Thereby, it can avoid that the size of the 1st list and the 2nd list undesirably enlarges.
  • An in-vehicle terminal transmits and receives information to and from a roadside device or another in-vehicle terminal.
  • This in-vehicle terminal has received a message with a storage unit (126) storing a first list of in-vehicle terminals with valid certificates and a second list of in-vehicle terminals with invalid certificates for each location and time
  • the certificate verification is omitted and the message is discarded.
  • the certificate verification is omitted.
  • a signature generation / verification processing unit (124) for verifying the signature According to this configuration, an in-vehicle terminal suitable for the communication system can be obtained.
  • the roadside device (110) transmits and receives information to and from the in-vehicle terminal.
  • the roadside device includes a storage unit (116) in which a first list of in-vehicle terminals with valid certificates and a second list of in-vehicle terminals with invalid certificates are stored for each location and time, and a message from the in-vehicle terminals.
  • a storage unit (116) in which a first list of in-vehicle terminals with valid certificates and a second list of in-vehicle terminals with invalid certificates are stored for each location and time, and a message from the in-vehicle terminals.
  • the message sender is in the second list, the verification of the certificate is omitted and the message is discarded.
  • the certificate And a signature generation / verification processing unit (114) that performs signature verification by omitting verification.
  • the in-vehicle terminal when the in-vehicle terminal obtains the common key necessary for verifying the validity of the first list and the second list from the roadside device, the in-vehicle terminal and its surroundings
  • the roadside apparatus can be provided with a communication control processing unit (111) that transmits information necessary for authentication and key sharing.
  • a processing unit that confirms the valid times of the first list and the second list and deletes the first list and the second list when the valid time has passed ( 112) can be provided.
  • FIG. 1 shows an overall configuration example of a communication system according to the present invention.
  • the communication system 10 shown in FIG. 1 includes, but is not limited to, a certificate authority 100, a roadside device 110, an in-vehicle terminal 120, a location information collection / analysis server 130, and a CRL server 140.
  • the certificate authority 100 can communicate with the roadside device 110.
  • the roadside device 110 includes a plurality of roadside devices 110A, 110B, and 110C provided at predetermined intervals on the road side.
  • the certification authority 100 issues a roadside device certificate and an in-vehicle terminal certificate to the roadside device 110 and the in-vehicle terminal 120, respectively.
  • a certificate that conforms to ITU (International Telecommunication Union) X.509 can be used.
  • the certificate authority 100 issues itself a self-signed certificate authority certificate.
  • the certificate authority 100 can communicate with the location information collection / analysis server 130 and the CRL server 140 safely.
  • the communication between the certificate authority 100 and the roadside device 110, the certificate authority 100 and the location information collection / analysis server 130, and the certificate authority 100 and the CRL server 140 may be wireless communication or wired communication.
  • the location information acquisition / analysis server 130 collects location information of the in-vehicle terminal 120 and analyzes, for example, a traffic jam situation.
  • the information collected from the in-vehicle terminal 120 may collect not only the position information but also the speed, destination, route, etc. of the in-vehicle terminal 120.
  • the CRL server 140 performs information management of the roadside device 110 and the in-vehicle terminal 120 whose certificate has expired.
  • the roadside device 110 can communicate with the certificate authority 100 and performs wireless communication with the in-vehicle terminal 120 existing within the communication range.
  • the communication ranges of the individual roadside devices 110A, 110B, and 110C overlap each other, but they do not have to overlap.
  • the certificate authority 100 may have a hierarchical structure including a root certificate authority 200, an intermediate certificate authority 210, and a lower certificate authority 220 as shown in FIG. Further, the intermediate certificate authority 210 may have any number of layers. At this time, the root certificate authority 200 issues a certificate for the intermediate certificate authority 210, and the intermediate certificate authority 210 issues a certificate for the lower certificate authority 220. The root certificate authority 200 issues itself a self-signed root certificate authority certificate. Furthermore, as in the case where a plurality of organizations cooperate, a plurality of root certificate authorities may exist and a trust model such as a mesh model or a bridge model may be constructed.
  • FIG. 3 shows a configuration example of the in-vehicle terminal 120.
  • the in-vehicle terminal 120 includes a communication control processing unit 121, a white list / black list processing unit 122, a key sharing processing unit 123, a message signature generation / verification processing unit 124, a location information acquisition unit 125, and a security information storage unit 126.
  • the communication control processing unit 121 performs processing for communicating with the roadside device 110 and other in-vehicle terminals 120.
  • the white list / black list processing unit 122 performs processing when the white list and the black list are received from the roadside apparatus 110 and periodically checks the validity of the white list and the black list.
  • the key sharing processing unit 123 performs processing for acquiring a common key necessary for MAC (Message Authentication Authentication Code) verification for confirming the integrity of the white list and the black list from the roadside device 110.
  • MAC Message Authentication Authentication Code
  • the message signature generation / verification unit 124 checks whether the sender of the message exists in the whitelist / blacklist, and verifies the certificate. It is determined whether to omit or not to verify the signature, and perform processing according to the determination result.
  • the position information acquisition unit 125 acquires its own position information and requests the communication control processing unit 121 to transmit it.
  • the means for acquiring the position information may be acquired by mounting GPS (Global Positioning System) on the in-vehicle terminal 120, or may be acquired from other devices mounted on the vehicle such as car navigation. In addition, when other devices mounted on the car have a communication function, the position information may be transmitted to the position information acquisition / analysis server 130 without going through the in-vehicle terminal 120.
  • the security information storage unit 126 is used to store the in-vehicle terminal identification information 300, the in-vehicle terminal certificate 301, the secret key 302, the common key 303, the common key identification information 304, the white list 305, and the black list 306.
  • the in-vehicle terminal identification information 300 is an identifier (ID) indicating the in-vehicle terminal 120
  • the in-vehicle terminal certificate 301 is a certificate issued to the in-vehicle terminal 120 by the certification authority 100
  • a public key is also described.
  • the secret key 302 is a secret key that is paired with the public key described in the in-vehicle terminal certificate 301.
  • the common key 303 is used to verify the MAC of the white list and the black list received from the road side device, and is acquired from the road side device 110.
  • the common key identification information 304 is an identifier of the common key 303.
  • the in-vehicle terminal 120 manages a common key 303 and common key identification information 304 as a set, and can hold a plurality of common keys 303 and common key identification information 304.
  • the white list 305 is a list of in-vehicle terminals for which the certificate is valid, and is distributed from the certificate authority 100 via the roadside device 110 for each place and every time.
  • the in-vehicle terminal 120 can hold a plurality of white lists 305.
  • the black list 306 is a list of in-vehicle terminals whose certificates have been revoked.
  • the black list 306 is distributed from the certificate authority 100 via the roadside device 110 for each place and time.
  • the in-vehicle terminal 120 can hold a plurality of black lists 306.
  • FIG. 4 shows a configuration example of the roadside device 110A.
  • the other roadside devices 110B and 110C are configured similarly.
  • the roadside apparatus 110A includes a communication control processing unit 111, a white list / black list processing unit 112, a key sharing processing unit 113, a message signature generation / verification processing unit 114, and a security information storage unit 116.
  • the communication control processing unit 111 performs processing for communicating with the certificate authority 100 and the in-vehicle terminal 120.
  • the white list / black list processing unit 112 performs processing when the white list and black list are received from the certificate authority 100, processing for transmitting the white list and black list to the in-vehicle terminal 120, and effectiveness of the white list and black list. Check regularly.
  • the key sharing processing unit 113 performs processing for transmitting to the in-vehicle terminal 120 a common key required for MAC (Message Authentication Code) verification for confirming the integrity of the white list and the black list.
  • MAC Message Authentication Code
  • the message signature generation / verification unit 114 checks whether the sender of the message exists in the whitelist / blacklist, and determines whether to omit the certificate verification. It is determined whether or not to verify the signature, and processing according to the determination result is performed.
  • a signature for the message is created, the signature and the roadside device certificate are delivered to the communication control processing unit 111 together with the message, and the transmission of the message is requested.
  • the security information storage unit 116 is used to store the roadside device identification information 400, the roadside device certificate 401, the secret key 402, the common key 403, the common key identification information 404, the white list 405, and the black list 406.
  • the roadside device identification information 400 is an identifier indicating the roadside device 110A
  • the roadside device certificate 401 is a certificate issued by the certification authority 100 to the roadside device 110A.
  • the secret key 402 is a secret key that is paired with the public key described in the roadside device certificate 401.
  • the common key 403 is for verifying the MAC of the white list and the black list received from the certificate authority 100 and is acquired from the certificate authority 100.
  • the common key identification information 404 is an identifier of the common key 403.
  • the roadside device 110 manages a common key 403 and common key identification information 404 as a set, and can hold a plurality of common keys 403 and common key identification information 404.
  • the white list 405 is a list of in-vehicle terminals whose certificates are valid, and is distributed from the certificate authority 100 for each place and every time.
  • the roadside apparatus 110A can hold a plurality of white lists 405.
  • the black list 406 is a list of in-vehicle terminals whose certificates have been revoked, and is distributed from the certificate authority 100 every place and every hour.
  • the roadside apparatus 110A can hold a plurality of black lists 406.
  • FIG. 5 shows a configuration example of the certificate authority 100.
  • the certificate authority 100 includes a communication control processing unit 101, a white list / black list processing unit 102, a key generation processing unit 103, a certificate issuance / revocation processing unit 104, and an information storage unit 105.
  • the communication control processing unit 101 performs processing for communicating with the roadside device 110, the position information collection / analysis server 103, and the CRL server 104.
  • the whitelist / blacklist processing unit 102 periodically collects information on the in-vehicle terminal 120 that is highly likely to appear every hour from the location information collection / analysis server 130, and the certificate of the in-vehicle terminal 120 is revoked.
  • the CRL server 140 is inquired as to whether or not a whitelist / blacklist is created. Then, a MAC for the created white list / black list is generated and transmitted to the roadside apparatus 110 via the communication control processing unit 101.
  • a blacklist is created and a MAC is generated for the blacklist in real time.
  • the key generation processing unit 103 generates a common key used for whitelist / blacklist MAC generation.
  • the common key may be generated when the white list and the black list are generated, and may be transmitted to the road side device 110 together with the white list and the black list, or may be generated in advance and transmitted to the road side device 110.
  • the certificate issuance / revocation processing unit 104 performs certificate issuance and revocation processing for the roadside device 110 and the in-vehicle terminal 120.
  • the information storage unit 105 includes a roadside device management table 500, an in-vehicle terminal management table 510, a common key management table 520, a certificate authority certificate 530, and a private key 540 that is paired with a public key described in the certificate authority certificate 530. , White list 550 and black list 560 are recorded.
  • the roadside device management table 500 is a table for managing information on the roadside device 110, and includes roadside device identification information 501, an installation location 502, and a roadside device certificate 503.
  • the roadside device identification information 501 is an identifier indicating a roadside device.
  • the installation location 502 is information indicating the installation location of the roadside apparatus 110, for example, information on the latitude / longitude of the installation location.
  • the roadside device certificate 503 is a certificate issued by the certificate authority 100 to the roadside device 110.
  • the in-vehicle terminal management table 510 includes in-vehicle terminal identification information 511 for identifying the in-vehicle terminal and an in-vehicle terminal certificate 512 issued to the in-vehicle terminal 120 by the certificate authority 100.
  • the common key management table 520 is a table for managing a common key necessary for generating a whitelist / blacklist MAC, and includes common key identification information 521, a common key 522, and a distribution location 523.
  • the common key identification information 521 indicates a common key identifier.
  • the common key 522 is generated by the key generation processing unit 103 and used for whitelist / blacklist MAC generation.
  • the distribution location 523 represents the location where the white list / black list to which the MAC created using the common key 522 is assigned is distributed. For example, the distribution location 523 may be expressed by latitude / longitude, It may be represented by a list of identification information.
  • the certificate authority certificate 530 is a self-signed certificate authority certificate.
  • the secret key 540 is a secret key that is paired with the public key described in the certificate authority certificate 530.
  • the white list 550 is a white list created by the certificate authority, and a plurality of white lists can be held.
  • the black list 560 is a white list created by the certificate authority, and a plurality of black lists can be held.
  • FIG. 6 shows a flowchart for creating / distributing a white list / black list.
  • the certification authority 100 requests the position information collection / analysis server 130 to transmit the in-vehicle terminal identification information of the in-vehicle terminal 120 that is highly likely to appear every time for each place.
  • the location information acquisition / analysis server 130 transmits information corresponding to the request from the certificate authority 100 in step 602.
  • the certification authority 100 refers to the in-vehicle terminal management table 510 and acquires the in-vehicle terminal certificate 512 corresponding to the in-vehicle terminal identification information received from the location information acquisition / analysis server 130.
  • the CRL server 140 is inquired whether the in-vehicle terminal certificate 512 has been revoked.
  • the CRL server 140 confirms whether the in-vehicle terminal certificate 512 sent from the certificate authority 100 has been revoked, and transmits the result to the certificate authority 100.
  • the CRL server 140 is inquired about certificate revocation confirmation, but the CRL may be acquired from the CRL server 140 and confirmed by the certificate authority 100.
  • the certificate authority 100 that has received the result of the CRL server 140 creates a white list and a black list for each location and time based on the results acquired from the location information acquisition / analysis server 130 and the CRL server 140. .
  • the format of the white list and black list will be described later.
  • step 606 the distribution location 523 of the common key management table 520 is referred to, a MAC is generated using the corresponding common key 522, and the corresponding roadside device 110 together with the white list and the black list is generated.
  • the roadside device 110 performs the white list and black list reception processing in step 607, and then periodically transmits the white list and black list to the in-vehicle terminal 120.
  • step 608 the roadside apparatus 120 performs white list and black list reception processing. The white list and black list reception processing of the roadside device 110 and the in-vehicle terminal 120 will be described later.
  • Fig. 7 shows the format of the white list and black list.
  • the white list and the black list include a type 710, an effective location 720, an effective time 730, the number of in-vehicle terminals 740, an in-vehicle terminal list 750, common key identification information 760, and a MAC 770.
  • Type 710 is an identifier indicating a white list or a black list.
  • the effective location 720 indicates a range of locations where the white list or the black list is effective.
  • the valid time 730 indicates the time during which this white list or black list is valid.
  • the number of in-vehicle terminals 740 indicates the number of in-vehicle terminals described in the in-vehicle terminal list 750.
  • the in-vehicle terminal list 750 is a list of in-vehicle terminals 120 in which the in-vehicle terminal certificate is valid when the type 710 indicates a white list, and the in-vehicle terminal 120 in which the in-vehicle terminal certificate has been revoked when the type 710 indicates a black list. It is a list.
  • the in-vehicle terminal list 750 includes a set of in-vehicle terminal identification information 751 and a serial number 752 of the in-vehicle terminal certificate.
  • the common key identification information 760 is an identifier of the common key used for generating the MAC of this white list or black list
  • the MAC 770 is an authentication code for information from the type 710 to the common key identification information 760.
  • FIG. 8 shows a reception process flowchart of the white list and the black list in the roadside device 110 and the in-vehicle terminal 120.
  • step 810 it is confirmed whether the common key identification information 760 described in the white list exists in the common key identification information 404 of the security information storage unit 116. If not, a common key is obtained from the certificate authority 100 in step 820.
  • the communication path between the certification authority 100 and the roadside device 110 is safe, and security measures are not implemented in the communication path, but the secure communication between the roadside device 110 and the in-vehicle terminal 120 described later is safe. It is also possible to apply a key sharing mechanism.
  • step 810 When it is confirmed in step 810 that the common key identification information 760 exists, or when the common key is acquired in step 820, in step 830, the common key 403 corresponding to the common key identification information 760 is used, and a white list or black A MAC is generated for information from the list type 710 to the common key identification information 760. If the generated MAC does not match the white list or black list MAC 770, the white list or black list is discarded in step 860. If they match, it is confirmed in step 840 whether the same white list or black list is received, and if it is received, it is discarded in step 860. If not received, the received white list or black list is recorded in the white list 405 or black list 406 of the security information storage unit 116 in step 850.
  • step 810 to step 860 the processing from step 810 to step 860 is performed in the same manner as the white list or black list in the roadside device 110.
  • FIG. 9 shows a mechanism for acquiring a common key in step 820 in the in-vehicle terminal 120.
  • the in-vehicle terminal 120 transmits a common key acquisition request together with the in-vehicle terminal identification information 300 to the roadside device 110A.
  • the roadside apparatus 110A generates a random number for the in-vehicle terminal 120 and transmits the random number to the in-vehicle terminal 120.
  • the in-vehicle terminal identification information received from the in-vehicle terminal 120 and the generated random number are transmitted to the surrounding roadside device 110B via the certificate authority 100, and the surrounding roadside device 110B receives the in-vehicle terminal identification information and the random number received in step 940.
  • the in-vehicle terminal 120 moves and becomes out of the communication range of the roadside device 110 before the key sharing is completed. Even in this case, the surrounding roadside device 120 and the in-vehicle terminal 120 can continue to perform the key sharing process. Moreover, in this example, although it transmits to the surrounding roadside apparatus 110B via the certification authority 100, you may transmit directly to the surrounding roadside apparatus 110B.
  • step 930 the in-vehicle terminal 120 creates authentication data by encrypting the random number received from the road-side device 110 with its own secret key 302, and transmits it to the road-side device 110 together with the in-vehicle terminal certificate 301.
  • step 950 the roadside apparatus 110 verifies the in-vehicle terminal certificate, and then decrypts the authentication data using the public key described in the in-vehicle terminal certificate. If the decrypted value is the same as the random number created in step 920, it is recognized as a valid in-vehicle terminal, and the process proceeds to step 960. Otherwise, it is recognized as an unauthorized in-vehicle terminal and the process is terminated.
  • step 960 the common key 403 and the common key identification information 404 are encrypted with the public key described in the in-vehicle terminal certificate sent from the in-vehicle terminal 120, and the encrypted common key data is created.
  • the in-vehicle terminal identification information and the random number that have been transmitted to and stored are deleted.
  • the encrypted common key data is transmitted to the surrounding roadside device 110, and the surrounding roadside device 110
  • the encrypted common key data is broadcast, and the in-vehicle terminal identification information and the random number are deleted in step 990.
  • the in-vehicle terminal 120 When the in-vehicle terminal 120 receives the encrypted common key data in step 970, the in-vehicle terminal 120 decrypts the encrypted common key data with its own secret key 302, and stores the common key and the common key identification information in the common key 303 and the common key identification information 304 in the security information storage unit 126. Store and complete the sharing of the common key.
  • FIG. 10 shows a flowchart of processing when the roadside device 110 that has received the common key acquisition request from the in-vehicle terminal 120 performs key sharing with the in-vehicle terminal 120 in order to cooperate with the surrounding roadside devices.
  • the roadside device 110 that has received the common key acquisition request generates the random number in step 1000 and stores the generated in-vehicle terminal identification information and the generated random number, and then stores the in-vehicle terminal identification information in the in-vehicle terminal 120 and the surrounding roadside terminal 110. Send the generated random number.
  • the authentication data is received from the in-vehicle terminal 120, it is determined that the authentication data exists within its own communication range, and the authentication data is verified in step 1040. If verification fails, it is determined as an in-vehicle terminal, and in step 1070, the verification failure is notified to the other roadside device 110.
  • the in-vehicle terminal identification information and the random number recorded in step 1080 are deleted, and the key sharing process is terminated. To do.
  • step 1050 If the verification is successful, encrypted common key data is created in step 1050, and then the encrypted common key data is transmitted to the in-vehicle terminal 120 and the surrounding roadside device 110 in step 1060. Then, the in-vehicle terminal identification information and the random number recorded in step 1080 are deleted, and the key sharing process is terminated.
  • the authentication data is received from the other roadside terminal 110 without receiving the authentication data from the in-vehicle terminal 120, it is determined that the in-vehicle terminal 120 exists outside its communication range and has been authenticated by the surrounding roadside device 110; Proceeding to step 1060, the received encrypted common key data is broadcast, the in-vehicle terminal identification information and the random number recorded in step 1080 are deleted, and the key sharing process is terminated.
  • the encrypted common key data is broadcast in consideration of the case where the in-vehicle terminal 120 exists within the communication range of a plurality of roadside terminals and the wireless communication state is not stable. That is, the peripheral roadside device 110 has verified the authentication data and created the encrypted common key data, but the in-vehicle terminal 120 is again out of the communication range of the peripheral roadside device 110 and is within its own communication range. This is the case.
  • the authentication data from the in-vehicle terminal 120 and the encrypted common key data is not received from the other roadside device 110, the authentication data from the in-vehicle terminal 120 or the other roadside device 110 is received until a certain time elapses. Wait for reception of encrypted common key data.
  • step 1080 If a verification failure notification is received from another roadside device 110, or if nothing is received even after a predetermined time has elapsed, the in-vehicle terminal identification information and the random number are deleted in step 1080, and the key sharing process is terminated.
  • step 1010 When the common key acquisition request is not received from the in-vehicle terminal 120 and the in-vehicle terminal identification information and the random number are acquired from the other roadside device 110, the random number is not generated in step 1000, but the processing after step 1010 is This is the same as the roadside device 110 that has received the common key acquisition request.
  • FIG. 11 shows processing when a vehicle-mounted terminal whose certificate has been revoked is detected when communication is performed between the vehicle-mounted terminals 120A and 120B.
  • the in-vehicle terminal 120A transmits a message to another in-vehicle terminal 120B
  • a message and a signature for the message are created in step 1100, and the in-vehicle terminal certificate 301 is transmitted together with the message and the signature.
  • the in-vehicle terminal 120B that has received the message verifies the in-vehicle terminal certificate in step 1110 and detects that the certificate has been revoked.
  • the in-vehicle terminal 120B creates a revoked certificate detection message. Notify the certificate authority.
  • the revocation certificate detection message will be described later.
  • the certificate authority 100 receives the revoked certificate detection message, the certificate authority 100 creates a black list in step 1130 and distributes it to the roadside device 110 around the location where the revoked certificate is detected.
  • the in-vehicle terminal 120B that first detects the revoked certificate takes time to verify the certificate, but the other in-vehicle terminal 120 and the roadside device 110 receive the blacklist from the certificate authority 100 in real time. By doing so, the certificate verification time can be shortened.
  • a revoked certificate detection message is generated and notified to the certificate authority 100 in the same manner as when the in-vehicle terminal 120 detects a revoked certificate.
  • the certificate authority 100 can also notify the police.
  • FIG. 12 shows a format example of a revocation certificate detection message.
  • the revocation certificate detection message includes a type 1200, a detection location 1210, a detection time 1220, the number of detected revocation certificates 1230, a revocation certificate list 1240, common key identification information 1250, and a MAC 1260.
  • Type 1200 is an identifier indicating a revocation certificate detection message.
  • a detection location 1210 indicates a range of locations where a revoked certificate is detected.
  • the detection time 1220 indicates the time when a revoked certificate is detected.
  • the number of revoked certificates 1230 indicates the number of revoked certificates described in the revoked certificate list 1240.
  • the revoked certificate list 1240 is a list of information relating to revoked certificates, and the revoked certificate list 1240 is a list of revoked certificate serial numbers 1241 and in-vehicle terminal identification information 1242.
  • the common key identification information 1250 is an identifier of the common key used for generating the MAC of the revocation certificate detection message, and the MAC 770 is an authentication code for information from the type 1210 to the common key identification information 1250.
  • FIG. 13 shows a flowchart of a message verification process in the roadside device 110 and the in-vehicle terminal 120.
  • the roadside device 110 or the in-vehicle terminal 120 receives the signed message and the certificate, in step 1300, the roadside device 110 or the in-vehicle terminal 120 checks whether the serial number of the certificate exists in the black list. When it exists, it progresses to step 1310, discards a message, and complete
  • step 1310 the process is terminated as success, and if the verification is unsuccessful, the message is discarded in step 1310 and the process is terminated. If the serial number of the certificate does not exist in the white list in step 1320, the process proceeds to step 1330, where the certificate is verified. If the verification is successful, the process proceeds to step 1340. If the verification fails, the message is discarded in step 1310, and the process is terminated. If the certificate verification has failed because the certificate has been revoked in step 1330, a revocation certificate detection message is created and notified to the certificate authority 100.
  • the certificate authority 100 when it is detected that the certificate has been revoked, the certificate authority 100 is notified in real time and a blacklist is created. However, it is also applicable to creating a whitelist. In this way, by omitting the certificate verification of the in-vehicle terminals existing in the white list and the black list, the message verification time can be shortened.
  • the white list and black list have valid locations and valid times. Therefore, the in-vehicle terminal 120 checks the whitelist and blacklist valid locations 720 and valid times 730 that are regularly held, and if they exist outside the valid locations or have passed the valid times, the whitelist / The black list processing unit 122 deletes the white list and the black list. In the roadside device 110, as with the in-vehicle terminal 120, the whitelist / blacklist processing unit 112 can delete the whitelist and blacklist. However, since the roadside device 110 is fixed to the roadside, the confirmation of the effective location 720 may be omitted. As described above, since the white list and the black list are created every time for each place, the amount of used memory can be reduced by periodically checking the white list and the black list and deleting those that are not valid.
  • the present invention can be widely applied to communication technology that guarantees the validity of a message using a public key cryptosystem when communicating between roads and vehicles or between vehicles.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Atmospheric Sciences (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Traffic Control Systems (AREA)

Abstract

 通信システムにおいて証明書の検証時間を削減する。 通信システム(10)は、認証を行う認証局(100)、路側装置(110)、車載端末(120)、第1サーバ(130)、第2サーバ(140)を含む。上記車載端末は、自身の位置情報を上記第1サーバに送信する。上記認証局は、場所と時間に応じた出現可能性の高い車載端末の情報を上記第1サーバから取得し、上記第1サーバから取得した車載端末の証明書が失効されていないかを第2サーバで確認し、上記確認結果をもとに場所ごと時間ごとに証明書が有効な車載端末の第1リスト及び証明書が失効している車載端末の第2リストを作成して、それを上記路側装置及び上記車載端末装置に送信する。上記路側装置及び車載端末装置は、受信した第1リスト及び第2リストを用いて、証明書の検証を行う。これにより証明書の検証時間の短縮を図る。

Description

通信システム、車載端末、路側装置
 本発明は、路車間または車車間で通信を行う際に、公開鍵暗号方式を用いてメッセージの正当性を保証する通信技術に関する。
 近年、交通事故死者数削減を目指し、予防安全を目的とした路車間/車車間通信の検討が進められている。予防安全に関わるサービスでは、一つの誤ったメッセージから大事故につながる可能性が高いため、正しい路側装置または車載端末が送ったメッセージであること、及び、正しい路側装置または車載端末が送ったメッセージが、悪意ある者によって、改竄されていないことを確認すること、すなわちメッセージの完全性を確保することが重要である。
 メッセージの正当性を保証する仕組みとして、公開鍵暗号方式を用いた電子署名がある。公開鍵暗号方式は、秘密鍵と公開鍵という対になる二つの鍵を用いて暗号/復号化を行う方式である。秘密鍵は秘密に管理する必要があるが、公開鍵は公開してよいという特徴がある。したがって、公開鍵暗号方式を用いた電子署名では、メッセージを送信する側が、メッセージのハッシュ値を秘密鍵で暗号化したデータを署名として、メッセージとともに送信する。メッセージの受信者は、送信者の公開鍵を入手し、署名を復号する。復号した値と、受信したメッセージから生成したハッシュ値が等しいか否かで署名の検証を行う。
 公開鍵暗号を用いた電子署名においては、公開鍵の正当性検証が問題となる。一般的には、認証局が公開鍵に署名を付与する。認証局が階層構造になっている場合は、上位の認証局が、下位の認証局の公開鍵に署名をつけることを繰り返す。
 したがって、メッセージの署名検証は、署名の検証を繰り返し行うことになるため、時間がかかる。車のように高速に移動しながら通信するために高速な署名検証が求められるシステムに対応した仕組みとして、以下の特許文献がある。
特開2007-88737号公報
 特許文献1に記載された技術によれば、地域認証局が複数の路側装置を管理し、管理下の路側装置に対して証明書を発行する。また、路側装置は、地域認証局の証明書(地域証明書)を定期的に車載端末に送信する。車載端末がメッセージを受信した場合、同じ地域証明書を受信している間は、地域証明書を信頼し、メッセージの署名を検証することで、検証にかかる時間を短縮できる。
 しかしながら、上記方式を車車間通信に適用した場合、車車間では通信時間が短いため、つまり同じ証明書を受信する時間が短いため、署名の検証時間短縮につながらない。また、証明書を検証する際には、証明書が失効されていないかどうかを確認する必要があるが、車は台数が多い上、広範囲に移動するため、路側基地局や車載端末に配布するCRL(Certificate Revocation List)のサイズが大きくなるという課題がある。また、OCSP(Online Certificate Status Protocol)のように、CRLを保持しない方式もあるが、当該方式によれば、サーバへの問い合わせ回数が多くなる。
 本発明の目的は、通信システムにおいて証明書の検証時間を削減するための技術を提供することにある。
 本発明の上記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。
 本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。
 すなわち、認証を行う認証局、路側に配置された路側装置、自動車に搭載された車載端末、上記車載端末の位置情報を収集する第1サーバ、証明書が失効した路側装置及び車載端末の情報管理を行う第2サーバを含んで通信システムを構成する。上記車載端末は、自身の位置情報を上記第1サーバに送信する。上記認証局は、場所と時間に応じた出現可能性の高い車載端末の情報を上記第1サーバから取得し、上記第1サーバから取得した車載端末の証明書が失効されていないかを第2サーバで確認し、上記確認結果をもとに場所ごと時間ごとに証明書が有効な車載端末の第1リスト及び証明書が失効している車載端末の第2リストを作成して、それを上記路側装置及び上記車載端末装置に送信する。上記路側装置及び車載端末装置は、受信した第1リスト及び第2リストを用いて、証明書の検証を行う。
 本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば下記のとおりである。
 すなわち、本発明によれば、証明書の検証時間短縮が可能になる。
本発明にかかる通信システムの全体的な構成例ブロック図である。 図1に示される通信システムにおける認証局の構成例ブロック図である。 図1に示される通信システムにおける車載端末の構成例ブロック図である。 図1に示される通信システムにおける路側装置の機能例ブロック図である。 図1に示される通信システムにおける認証局の構成例ブロック図である。 ホワイトリスト及びブラックリストの作成及び配布のフローチャートである。 ホワイトリスト及びブラックリストのデータフォーマット説明図である。 上記路側装置及び上記車載端末でのホワイトリスト及びブラックリストの受信処理のフローチャートである。 上記路側装置と上記車載端末との間での共通鍵共有のフローチャートである。 上記路側装置と上記車載端末との間での共通鍵共有の別のフローチャートである。 証明書が失効された車載端末を検知した場合の処理フローチャートである。 失効証明書検知メッセージのフォーマット説明図である。 上記路側装置及び上記車載端末がメッセージを受信した場合の処理フローチャートである。
 1.実施の形態の概要
 先ず、本願において開示される発明の代表的な実施の形態について概要を説明する。代表的な実施の形態についての概要説明で括弧を付して参照する図面中の参照符号はそれが付された構成要素の概念に含まれるものを例示するに過ぎない。
 〔1〕本発明の代表的な実施の形態に係る通信システム(10)は、認証を行う認証局(100)、路側に配置された路側装置(110)、自動車に搭載された車載端末(120)、上記車載端末の位置情報を収集する第1サーバ(130)、証明書が失効した路側装置及び車載端末の情報管理を行う第2サーバ(140)を含む。上記車載端末は、自身の位置情報を上記第1サーバに送信する。上記認証局は、場所と時間に応じた出現可能性の高い車載端末の情報を上記第1サーバから取得し、上記第1サーバから取得した車載端末の証明書が失効されていないかを第2サーバで確認し、上記確認結果をもとに場所ごと時間ごとに証明書が有効な車載端末の第1リスト(ホワイトリスト)及び証明書が失効している車載端末の第2リスト(ブラックリスト)を作成して、それを上記路側装置及び上記車載端末装置に送信する。上記路側装置及び車載端末装置は、受信した第1リスト及び第2リストを用いて、証明書の検証を行う。
 上記の構成によれば、上記認証局は、場所と時間に応じた出現可能性の高い車載端末の情報を上記第1サーバから取得し、上記第1サーバから取得した車載端末の証明書が失効されていないかを第2サーバで確認し、上記確認結果をもとに場所ごと時間ごとに証明書が有効な車載端末の第1リスト及び証明書が失効している車載端末の第2リストを作成して、それを上記路側装置及び上記車載端末装置に送信する。上記路側装置及び車載端末装置は、受信した第1リスト及び第2リストを用いて、証明書の検証を行うことができるので、証明書の検証時間を短縮することができる。
 〔2〕上記〔1〕において、上記路側装置及び上記車載端末は、メッセージを受信した際に、メッセージ送信者が上記第2リストに存在する場合は、証明書の検証を省略してメッセージを破棄し、メッセージ送信者が上記第1リストに存在する際は、証明書の検証を省略して署名の検証を行うように構成することができる。メッセージを受信する毎に第2サーバに問い合わせる必要がないので、署名の検証時間の短縮を図ることができる。
 〔3〕上記〔2〕において、上記路側装置は、上記車載端末が上記第1リスト及び上記第2リストの正当性を検証するために必要な共通鍵を上記路側装置から取得する際に、上記車載端末及びその周辺の上記路側装置に認証及び鍵共有に必要な情報を送信するように構成することができる。情報の共有化により処理時間の短縮化を図ることができる。
 〔4〕上記〔3〕において、上記路側装置及び上記車載端末は、上記第1リスト及び上記第2リストの有効場所と有効時間を確認し、自身が有効場所外に存在する場合または有効時間を経過している場合に、上記第1リスト及び上記第2リストを削除するように構成することができる。これにより、第1リスト及び上記第2リストのサイズが不所望に肥大するのを回避することができる。
 〔5〕上記〔4〕において、車車間又は路車間通信を行っている際に、上記路側装置又は上記車載端末が、失効されている証明書を検知すると、上記情報を認証局にリアルタイムに通知し、認証局が第2リストを作成し、検知場所付近の路側装置及び車載端末に第2リストを送信するように構成することができる。これにより、第2リストが更新される。
 〔6〕本発明の代表的な実施の形態に係る車載端末は、路側装置又は他の車載端末との間で情報の送受信を行う。この車載端末は、場所ごと時間ごとに証明書が有効な車載端末の第1リスト及び証明書が失効している車載端末の第2リストが記憶された記憶部(126)と、メッセージを受信した際に、メッセージ送信者が上記第2リストに存在する場合は、証明書の検証を省略してメッセージを破棄し、メッセージ送信者が上記第1リストに存在する際は、証明書の検証を省略して署名の検証を行う署名生成/検証処理部(124)と、を含む。かかる構成によれば、上記通信システムに好適な車載端末を得ることができる。
 〔7〕上記〔6〕において、上記第1リスト及び上記第2リストの有効場所と有効時間を確認し、自身が有効場所外に存在する場合または有効時間を経過している場合に、上記第1リスト及び上記第2リストを削除する処理部(122)を設けることができる。
 〔8〕本発明の代表的な実施の形態に係る路側装置(110)は、車載端末との間で情報の送受信を行う。この路側装置は、場所ごと時間ごとに証明書が有効な車載端末の第1リスト及び証明書が失効している車載端末の第2リストが記憶された記憶部(116)と、車載端末からメッセージを受信した際に、メッセージ送信者が上記第2リストに存在する場合は、証明書の検証を省略してメッセージを破棄し、メッセージ送信者が上記第1リストに存在する際は、証明書の検証を省略して署名の検証を行う署名生成/検証処理部(114)とを含む。これにより、上記通信システムに好適な路側装置を得ることができる。
 〔9〕上記〔8〕において、上記車載端末が上記第1リスト及び上記第2リストの正当性を検証するために必要な共通鍵を上記路側装置から取得する際に、上記車載端末及びその周辺の上記路側装置に認証及び鍵共有に必要な情報を送信する通信制御処理部(111)を設けることができる。
 〔10〕上記〔9〕において、上記第1リスト及び上記第2リストの有効時間を確認し、有効時間を経過している場合に、上記第1リスト及び上記第2リストを削除する処理部(112)を設けることができる。
 2.実施の形態の詳細
 実施の形態について更に詳述する。
 図1には、本発明にかかる通信システムの全体的な構成例が示される。図1に示される通信システム10は、特に制限されないが、認証局100、路側装置110、車載端末120、位置情報収集/分析サーバ130、CRLサーバ140を含んで成る。認証局100は、路側装置110と通信可能である。路側装置110は、路側に所定間隔で設けられた複数の路側装置110A,110B,110Cを含む。認証局100は、路側装置110及び車載端末120に対して、それぞれ路側装置証明書及び車載端末証明書を発行する。証明書は、ITU(国際電気通信連合)X.509に準拠したものを用いることができる。認証局100は、自己署名した認証局証明書を自ら発行する。また、認証局100は、位置情報収集/分析サーバ130及びCRLサーバ140と安全な通信が可能である。認証局100と路側装置110、認証局100と位置情報収集/分析サーバ130、認証局100とCRLサーバ140との通信は、無線通信でも有線通信でもよい。位置情報取得/分析サーバ130は、車載端末120の位置情報を収集し、例えば渋滞状況などの分析を行う。車載端末120から収集する情報は、位置情報だけでなく車載端末120の速度、目的地、経路などを収集してもよい。CRLサーバ140は、証明書が失効した路側装置110及び車載端末120の情報管理を行う。路側装置110は、認証局100と通信可能であり、通信範囲内に存在する車載端末120と無線通信を行う。図1では、個々の路側装置110A,B,Cの通信範囲が互いに重なり合っているが、重なり合っていなくてもよい。
 認証局100は、例えば図2に示されるように、ルート認証局200、中間認証局210、下位認証局220を含む階層構造でもよい。また、中間認証局210の階層はいくつでもよい。このとき、ルート認証局200が中間認証局210の証明書を発行し、中間認証局210が下位認証局220の証明書を発行する。ルート認証局200は、自己署名したルート認証局証明書を自ら発行する。更に、複数の組織が連携する場合のように、複数のルート認証局が存在し、メッシュモデルやブリッジモデルのような信頼モデルを構築していてもよい。
 図3には、上記車載端末120の構成例が示される。
 車載端末120は、通信制御処理部121、ホワイトリスト/ブラックリスト処理部122、鍵共有処理部123、メッセージの署名生成/検証処理部124、位置情報取得部125、セキュリティ情報記憶部126を含んで成る。通信制御処理部121は、路側装置110や他の車載端末120と通信するための処理を行う。ホワイトリスト/ブラックリスト処理部122は、路側装置110からホワイトリスト及びブラックリストを受信した場合の処理とホワイトリスト及びブラックリストの有効性の定期的な確認を行う。鍵共有処理部123は、ホワイトリスト及びブラックリストの完全性を確認するためのMAC(Message Authentication Code)検証に必要な共通鍵を路側装置110から取得するための処理を行う。メッセージの署名生成/検証部124は、路側装置110または他の車載端末120からメッセージを受信した場合は、メッセージの送信者がホワイトリスト/ブラックリストに存在するかを確認し、証明書の検証を省略するか否か、署名の検証を行うか否かを判断し、その判断結果に従った処理を行う。メッセージを送信する場合は、メッセージに対する署名を作成し、通信制御処理部121にメッセージとともに署名、車載端末証明書を渡し、メッセージの送信を依頼する。位置情報取得部125は、自身の位置情報を取得し、通信制御処理部121に送信を依頼する。位置情報を取得する手段は、車載端末120にGPS(Global Positioning System)を搭載し取得してもよいし、カーナビゲーションなど車に搭載される他の機器から取得してもよい。また、車に搭載される他の機器に通信機能が備わっている場合は、本車載端末120を経由せずに、位置情報を位置情報取得/分析サーバ130に送信してもよい。セキュリティ情報記憶部126は、車載端末識別情報300、車載端末証明書301、秘密鍵302、共通鍵303、共通鍵識別情報304、ホワイトリスト305、ブラックリスト306を記憶するのに用いられる。車載端末識別情報300は車載端末120を示す識別子(ID)であり、車載端末証明書301は、認証局100が車載端末120に対して発行した証明書であり、公開鍵も記載されている。秘密鍵302は、車載端末証明書301に記載されている公開鍵と対になる秘密鍵である。共通鍵303は、路側装置から受信したホワイトリスト及びブラックリストのMACを検証するためのものであり、路側装置110から取得する。共通鍵識別情報304は、共通鍵303の識別子である。車載端末120は、共通鍵303と共通鍵識別情報304をセットで管理しており、複数の共通鍵303と共通鍵識別情報304を保持できる。ホワイトリスト305は、証明書が有効である車載端末のリストであり、場所ごと時間ごとに認証局100から路側装置110経由で配布される。車載端末120は、ホワイトリスト305を複数保持できる。ブラックリスト306は、証明書が失効されている車載端末のリストであり、場所ごと時間ごとに認証局100から路側装置110経由で配布される。車載端末120は、ブラックリスト306を複数保持できる。
 図4には、上記路側装置110Aの構成例が示される。尚、他の路側装置110B,110Cも同様に構成される。
 路側装置110Aは、通信制御処理部111、ホワイトリスト/ブラックリスト処理部112、鍵共有処理部113、メッセージの署名生成/検証処理部114、セキュリティ情報記憶部116を含んで成る。通信制御処理部111は、認証局100や車載端末120と通信するための処理を行う。ホワイトリスト/ブラックリスト処理部112は、認証局100からホワイトリスト及びブラックリストを受信した場合の処理、ホワイトリスト及びブラックリストを車載端末120に送信するための処理とホワイトリスト及びブラックリストの有効性の定期的な確認を行う。鍵共有処理部113は、ホワイトリスト及びブラックリストの完全性を確認するためのMAC(Message Authentication Code)検証に必要な共通鍵を車載端末120に送信するための処理を行う。メッセージの署名生成/検証部114は、車載端末120からメッセージを受信した場合は、メッセージの送信者がホワイトリスト/ブラックリストに存在するかを確認し、証明書の検証を省略するか否か、署名の検証を行うか否かを判断し、判断結果に従った処理を行う。メッセージを送信する場合は、メッセージに対する署名を作成し、通信制御処理部111にメッセージとともに署名、路側装置証明書を渡し、メッセージの送信を依頼する。セキュリティ情報記憶部116は、路側装置識別情報400、路側装置証明書401、秘密鍵402、共通鍵403、共通鍵識別情報404、ホワイトリスト405、ブラックリスト406を記憶するのに用いられる。路側装置識別情報400は路側装置110Aを示す識別子であり、路側装置証明書401は、認証局100が路側装置110Aに対して発行した証明書である。秘密鍵402は、路側装置証明書401に記載されている公開鍵と対になる秘密鍵である。共通鍵403は、認証局100から受信したホワイトリスト及びブラックリストのMACを検証するためのものであり、認証局100から取得する。共通鍵識別情報404は、共通鍵403の識別子である。路側装置110は、共通鍵403と共通鍵識別情報404をセットで管理しており、複数の共通鍵403と共通鍵識別情報404を保持できる。ホワイトリスト405は、証明書が有効である車載端末のリストであり、場所ごと時間ごとに認証局100から配布される。路側装置110Aは、ホワイトリスト405を複数保持できる。ブラックリスト406は、証明書が失効されている車載端末のリストであり、場所ごと時間ごとに認証局100から配布される。路側装置110Aは、ブラックリスト406を複数保持できる。
 図5には、上記認証局100の構成例が示される。認証局100は、通信制御処理部101、ホワイトリスト/ブラックリスト処理部102、鍵生成処理部103、証明書発行/失効処理部104、情報記憶部105を含んで成る。通信制御処理部101は、路側装置110、位置情報収集/分析サーバ103、CRLサーバ104と通信するための処理を行う。ホワイトリスト/ブラックリスト処理部102は、定期的に位置情報収集/分析サーバ130から場所ごと時間ごとに出現可能性が高い車載端末120の情報を収集し、その車載端末120の証明書が失効されているか否かをCRLサーバ140に問い合わせて、ホワイトリスト/ブラックリストを作成する。そして、作成したホワイトリスト/ブラックリストに対するMACを生成し、通信制御処理部101を介して路側装置110に送信する。また、証明書が失効された車載端末120を検知したというメッセージを路側装置110または車載端末120から受信した場合、リアルタイムにブラックリストの作成とブラックリストに対するMACの生成を行う。鍵生成処理部103は、ホワイトリスト/ブラックリストのMAC生成に使用する共通鍵を生成する。共通鍵の生成は、ホワイトリスト及びブラックリストを生成する際に作成し、ホワイトリスト及びブラックリストとともに路側装置110に送信してもよいし、事前に作成し路側装置110に送信してもよい。証明書発行/失効処理部104は、路側装置110及び車載端末120の証明書の発行及び失効処理を行う。情報記憶部105は、路側装置管理テーブル500、車載端末管理テーブル510、共通鍵管理テーブル520、認証局の証明書530、認証局証明書530に記載されている公開鍵と対になる秘密鍵540、ホワイトリスト550、ブラックリスト560を記録する。路側装置管理テーブル500は、路側装置110の情報を管理するテーブルであり、路側装置識別情報501、設置場所502、路側装置証明書503で構成する。路側装置識別情報501は路側装置を示す識別子である。設置場所502は路側装置110の設置場所を示す情報であり、例えば設置場所の緯度/経度の情報などである。路側装置証明書503は、認証局100が路側装置110に対して発行した証明書である。車載端末管理テーブル510は、車載端末を識別する車載端末識別情報511と、認証局100が車載端末120に対して発行した車載端末証明書512で構成する。共通鍵管理テーブル520は、ホワイトリスト/ブラックリストのMAC生成に必要な共通鍵を管理するテーブルであり、共通鍵識別情報521、共通鍵522、配布場所523で構成する。共通鍵識別情報521は共通鍵の識別子を示す。共通鍵522は、鍵生成処理部103で生成され、ホワイトリスト/ブラックリストのMAC生成に使用される。配布場所523は、共通鍵522を使用して作成したMACが付与されているホワイトリスト/ブラックリストが配布された場所を表すものであり、例えば、緯度/経度で表してもよいし、車載端末識別情報一覧で表してもよい。認証局証明書530は、自己署名した認証局の証明書である。秘密鍵540は、認証局証明書530に記載されている公開鍵と対になる秘密鍵である。ホワイトリスト550は、認証局が作成したホワイトリストであり、複数保持することができる。ブラックリスト560は、認証局が作成したホワイトリストであり、複数保持することができる。
 図6には、ワイトリスト/ブラックリストの作成/配布のフローチャートが示される。認証局100は、ステップ601で、位置情報収集/分析サーバ130に場所ごと時間ごとに出現可能性が高い車載端末120の車載端末識別情報を送信してもらえるよう依頼する。位置情報取得/分析サーバ130は、ステップ602で認証局100からの依頼に対応した情報を送信する。認証局100は、ステップ603で、車載端末管理テーブル510を参照し、位置情報取得/分析サーバ130から受信した車載端末識別情報に対応する車載端末証明書512を取得する。そして、車載端末証明書512が失効されているかをCRLサーバ140に問い合わせる。CRLサーバ140は、ステップ604で、認証局100から送られてきた車載端末証明書512が失効されているかを確認し、その結果を認証局100に送信する。本例では、証明書の失効確認をCRLサーバ140に問い合わせているが、CRLサーバ140からCRLを取得し、認証局100が確認してもよい。CRLサーバ140の結果を受信した認証局100は、ステップ605で、位置情報取得/分析サーバ130及びCRLサーバ140から取得した結果をもとに、場所ごと時間ごとにホワイトリスト及びブラックリストを作成する。ホワイトリスト及びブラックリストのフォーマットについては後述する。ホワイトリスト及びブラックリストを作成すると、ステップ606で、共通鍵管理テーブル520の配布場所523を参照し、該当する共通鍵522を使ってMACを生成し、ホワイトリスト及びブラックリストとともに該当する路側装置110に送信する。路側装置110は、ステップ607でホワイトリスト及びブラックリストの受信処理をおこなった後、ホワイトリスト及びブラックリストを定期的に車載端末120に送信する。路側装置120は、ステップ608でホワイトリスト及びブラックリストの受信処理を行う。路側装置110及び車載端末120のホワイトリスト及びブラックリストの受信処理については後述する。
 図7には、ホワイトリスト及びブラックリストのフォーマットが示される。ホワイトリスト及びブラックリストは、タイプ710、有効場所720、有効時間730、車載端末の数740、車載端末リスト750、共通鍵識別情報760、MAC770を含んで成る。タイプ710は、ホワイトリストまたはブラックリストを示す識別子である。有効場所720は、本ホワイトリストまたはブラックリストが有効となる場所の範囲を示す。有効時間730は、本ホワイトリストまたはブラックリストが有効となる時間を示す。車載端末の数740は、車載端末リスト750に記載される車載端末の数を示す。車載端末リスト750は、タイプ710がホワイトリストを示す場合、車載端末証明書が有効な車載端末120のリストであり、タイプ710がブラックリストを示す場合、車載端末証明書が失効された車載端末120のリストである。車載端末リスト750は、車載端末識別情報751と車載端末証明書のシリアル番号752のセットがリストになっている。共通鍵識別情報760は、本ホワイトリストまたはブラックリストのMAC生成に使用した共通鍵の識別子であり、MAC770は、タイプ710から共通鍵識別情報760までの情報に対する認証コードである。
 図8には、路側装置110及び車載端末120におけるホワイトリスト及びブラックリストの受信処理フローチャートが示される。
 路側装置110がホワイトリストまたはブラックリストを受信した場合、ステップ810で、ホワイトリストに記載されている共通鍵識別情報760がセキュリティ情報記憶部116の共通鍵識別情報404に存在するか確認し、存在しない場合は、ステップ820で、認証局100から共通鍵を取得する。本例では、認証局100と路側装置110との通信路は安全と仮定し、該通信路においてはセキュリティ対策を実施していないが、後述する路側装置110と車載端末120との間の安全な鍵共有の仕組みを適用することも可能である。ステップ810で共通鍵識別情報760が存在することを確認した場合、もしくはステップ820で共通鍵を取得すると、ステップ830で、共通鍵識別情報760に対応する共通鍵403を使って、ホワイトリストまたはブラックリストのタイプ710から共通鍵識別情報760までの情報に対するMACを生成する。生成したMACが、ホワイトリストまたはブラックリストのMAC770と一致しなかった場合は、ステップ860でホワイトリストまたはブラックリストを破棄する。一致した場合は、ステップ840で、同じホワイトリストまたはブラックリストを受信していないかを確認し、受信している場合はステップ860で破棄する。受信していない場合は、ステップ850で、セキュリティ情報記憶部116のホワイトリスト405またはブラックリスト406に受信したホワイトリストまたはブラックリストを記録する。
 車載端末120がホワイトリストまたはブラックリストを受信した場合も、路側装置110でのホワイトリストまたはブラックリストと同じようにステップ810からステップ860の処理を行う。
 図9には、車載端末120において、ステップ820における共通鍵取得の仕組みが示される。車載端末120が、ステップ910で、路側装置110Aに対して、共通鍵取得要求を車載端末識別情報300とともに送信する。路側装置110Aは、ステップ920で、車載端末120に対して乱数を生成し、車載端末120に送信する。また、認証局100を介して周辺の路側装置110Bに車載端末120から受信した車載端末識別情報と生成した乱数を送信し、周辺の路側装置110Bはステップ940で受信した車載端末識別情報と乱数を記憶するとともに、受信した情報をブロードキャストする。鍵共有に関する情報を周辺の路側装置110Aにも送信し、周辺の路側装置110もブロードキャストすることで、車載端末120が移動し、鍵共有が完了する前に該路側装置110の通信範囲外になった場合でも、周辺の路側装置120と車載端末120は引き続き鍵共有の処理を行うことができる。また、本例では、認証局100を介して周辺の路側装置110Bに送信しているが、周辺の路側装置110Bに直接送信してもよい。
 車載端末120は、ステップ930で、路側装置110から受信した乱数を自身の秘密鍵302で暗号化することで認証データを作成し、車載端末証明書301とともに路側装置110に送信する。路側装置110は、ステップ950で、車載端末証明書を検証した後、車載端末証明書に記載されている公開鍵を用いて認証データを復号する。復号した値がステップ920で作成した乱数と同じ場合は、正当な車載端末であると認識し、ステップ960に進む。そうでない場合は、不正な車載端末と認識し、処理を終了する。
 ステップ960では、車載端末120から送られていた車載端末証明書に記載されている公開鍵で、共通鍵403と共通鍵識別情報404を暗号化し、暗号化共通鍵データを作成し、車載端末120に送信し、記憶していた車載端末識別情報と乱数を削除する。ここでも、車載端末120が該路側装置110の通信範囲外になった場合も対応するため、周辺の路側装置110に暗号化共通鍵データを送信し、周辺の路側装置110は、ステップ980での暗号化共通鍵データのブロードキャストとステップ990での車載端末識別情報と乱数の削除を行う。
 車載端末120は、ステップ970で暗号化共通鍵データを受信すると、自身の秘密鍵302で復号し、共通鍵と共通鍵識別情報をセキュリティ情報記憶部126の共通鍵303と共通鍵識別情報304に記憶し、共通鍵の共有が完了する。
 図10には、車載端末120から共通鍵取得要求を受信した路側装置110が、周辺の路側装置と連携するため、車載端末120と鍵共有を行う際の処理のフローチャートが示される。
 共通鍵取得要求を受信した路側装置110は、ステップ1000で乱数の生成と、車載端末識別情報と生成した乱数の記憶をおこなった後、車載端末120及び周辺の路側端末110に車載端末識別情報と生成した乱数を送信する。車載端末120から認証データを受信すると、自身の通信範囲内に存在すると判断し、ステップ1040で認証データの検証を行う。検証に失敗した場合は、不正な車載端末と判断し、ステップ1070で他の路側装置110に検証失敗を通知し、ステップ1080で記録した車載端末識別情報と乱数を削除し、鍵共有処理を終了する。検証に成功した場合は、ステップ1050で暗号化共通鍵データを作成した後、ステップ1060で暗号化共通鍵データを車載端末120及び周辺の路側装置110に送信する。そして、ステップ1080で記録した車載端末識別情報と乱数を削除し、鍵共有処理を終了する。
 車載端末120から認証データを受信しないで、他の路側端末110から認証データを受信した場合は、車載端末120が自身の通信範囲外に存在し、周辺の路側装置110に認証されたと判断し、ステップ1060に進み、受信した暗号化共通鍵データをブロードキャストし、ステップ1080で記録した車載端末識別情報と乱数を削除し、鍵共有処理を終了する。暗号化共通鍵データをブロードキャストするのは、車載端末120が複数の路側端末の通信範囲内に存在し、無線通信状態が安定しない場合を考慮したものである。つまり、周辺の路側装置が110、認証データの検証と暗号化共通鍵データの作成を実施したが、再び車載端末120が周辺の路側装置110の通信範囲外になり、自身の通信範囲内になった場合である。
 車載端末120から認証データを受信しない上、他の路側装置110からも暗号化共通鍵データを受信しない場合、一定時間が経過するまでは車載端末120からの認証データまたは他の路側装置110からの暗号化共通鍵データの受信を待つ。
 他の路側装置110から検証失敗の通知を受けた場合もしくは一定時間経過しても何も受信しない場合は、ステップ1080で車載端末識別情報と乱数を削除し、鍵共有処理を終了する。
 車載端末120から共通鍵取得要求を受信せず、他の路側装置110から車載端末識別情報と乱数を取得した場合は、ステップ1000での乱数の生成はおこなわないが、ステップ1010以降の処理は、共通鍵取得要求を受信した路側装置110と同じである。
 図11には、車載端末120A,120B間で通信を行った際に、証明書が失効された車載端末を検知した場合の処理が示される。車載端末120Aが他の車載端末120Bにメッセージを送信する際には、ステップ1100でメッセージ、メッセージに対する署名を作成し、メッセージ及び署名とともに車載端末証明書301を送信する。メッセージを受信した車載端末120Bは、ステップ1110で車載端末証明書を検証し、証明書が失効されていることを検知すると、ステップ1120で失効証明書検知メッセージを作成し、路側端末110を介して認証局に通知する。失効証明書検知メッセージについては後述する。認証局100は、失効証明書検知メッセージを受信すると、ステップ1130でブラックリストを作成し、失効された証明書が検知された場所周辺の路側装置110に配布する。これにより、最初に、失効された証明書を検知した車載端末120Bは、証明書の検証に時間を要するが、その他の車載端末120及び路側装置110は、リアルタイムに認証局100からブラックリストを受信することにより証明書の検証時間を短縮できる。また、路側装置110が失効された証明書を検知した場合も、車載端末120が失効された証明書を検知したときと同様に、失効証明書検知メッセージを作成し、認証局100へ通知する。
 認証局100は、証明書の失効理由が盗難であると判明した場合は、警察などに通報することも可能となる。
 図12には、失効証明書検知メッセージのフォーマット例が示される。失効証明書検知メッセージは、タイプ1200、検知場所1210、検知時間1220、検知した失効証明書の数1230、失効証明書リスト1240、共通鍵識別情報1250、MAC1260を含んで成る。タイプ1200は、失効証明書検知メッセージを示す識別子である。検知場所1210は、失効された証明書が検知された場所の範囲を示す。検知時間1220は、失効された証明書が検知された時間を示す。失効証明書の数1230は、失効証明書リスト1240に記載される失効証明書の数を示す。失効証明書リスト1240は、失効された証明書に関する情報のリストであり、失効証明書リスト1240は、失効された証明書のシリアル番号1241と車載端末識別情報1242のセットがリストになっている。共通鍵識別情報1250は、失効証明書検知メッセージのMAC生成に使用した共通鍵の識別子であり、MAC770は、タイプ1210から共通鍵識別情報1250までの情報に対する認証コードである。
 図13には、路側装置110と車載端末120におけるメッセージの検証処理のフローチャートが示される。路側装置110または車載端末120は、署名付きメッセージ及び証明書を受信すると、ステップ1300で証明書のシリアル番号がブラックリストに存在しないかを確認する。存在する場合は、ステップ1310に進み、メッセージを破棄して処理を終了する。存在しない場合は、ステップ1320に進み、証明書のシリアル番号がホワイトリストに存在しないか確認する。存在する場合は、証明書の検証を省略し、ステップ1340の署名の検証に進む。検証に成功した場合は、成功として処理を終了し、失敗した場合は、ステップ1310のメッセージ破棄をおこなった後、処理を終了する。ステップ1320で証明書のシリアル番号がホワイトリストに存在しない場合は、ステップ1330に進み、証明書の検証をおこない、検証が成功するとステップ1340に進む。検証に失敗すると、ステップ1310のメッセージ破棄をおこなった後、処理を終了する。また、ステップ1330で証明書が失効されているため、証明書の検証に失敗した場合は、失効証明書検知メッセージを作成し、認証局100に通知する。
 本例では証明書が失効されていることを検知した場合、リアルタイムに認証局100に通知し、ブラックリストを作成したが、ホワイトリストの作成にも適用可能である。このように、ホワイトリスト及びブラックリストに存在する車載端末の証明書検証を省略することで、メッセージの検証時間を短縮することができる。
 また、ホワイトリスト及びブラックリストは、有効場所と有効時間がある。したがって、車載端末120は、定期的に保有しているホワイトリスト及びブラックリストの有効場所720及び有効時間730を確認し、有効場所外に存在するまたは有効時間を経過している場合は、ホワイトリスト/ブラックリスト処理部122によってホワイトリスト及びブラックリストを削除する。路側装置110においても車載端末120と同様に、ホワイトリスト/ブラックリスト処理部112によってホワイトリスト及びブラックリストの削除を行うことができる。ただし、路側装置110は路側に固定されているので、有効場所720の確認は省略してもよい。このように、場所ごと時間ごとにホワイトリスト及びブラックリストを作成するので、定期的にホワイトリスト及びブラックリストを確認し、有効でないものは削除することで、使用メモリ量を抑えることができる。
 以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
 本発明は、路車間または車車間で通信を行う際に、公開鍵暗号方式を用いてメッセージの正当性を保証する通信技術に広く適用することができる。
 10 通信システム
 100 認証局
 110 路側装置
 120 車載端末
 130 位置情報収集/分析サーバ
 140 CRLサーバ
 200 ルート認証局
 210 中間認証局
 220 下位認証局

Claims (10)

  1.  認証を行う認証局、路側に配置された路側装置、自動車に搭載された車載端末、上記車載端末の位置情報を収集する第1サーバ、証明書が失効した路側装置及び車載端末の情報管理を行う第2サーバを含み、上記路側装置と上記車載端末との間、または上記車載端末間で情報の送受信を行う通信システムであって、
     上記車載端末は、自身の位置情報を上記第1サーバに送信し、
     上記認証局は、場所と時間に応じた出現可能性の高い車載端末の情報を上記第1サーバから取得し、上記第1サーバから取得した車載端末の証明書が失効されていないかを第2サーバで確認し、上記確認結果をもとに場所ごと時間ごとに証明書が有効な車載端末の第1リスト及び証明書が失効している車載端末の第2リストを作成して、それを上記路側装置及び上記車載端末装置に送信し、
     上記路側装置及び車載端末装置は、受信した第1リスト及び第2リストを用いて、証明書の検証を行うことを特徴とする通信システム。
  2.  上記路側装置及び上記車載端末は、メッセージを受信した際に、メッセージ送信者が上記第2リストに存在する場合は、証明書の検証を省略してメッセージを破棄し、メッセージ送信者が上記第1リストに存在する際は、証明書の検証を省略して署名の検証を行う請求項1記載の通信システム。
  3.  上記路側装置は、上記車載端末が上記第1リスト及び上記第2リストの正当性を検証するために必要な共通鍵を上記路側装置から取得する際に、上記車載端末及びその周辺の上記路側装置に認証及び鍵共有に必要な情報を送信する請求項2記載の通信システム。
  4.  上記路側装置及び上記車載端末は、上記第1リスト及び上記第2リストの有効場所と有効時間を確認し、自身が有効場所外に存在する場合または有効時間を経過している場合に、上記第1リスト及び上記第2リストを削除する請求項3記載の通信システム。
  5.  車車間又は路車間通信を行っている際に、上記路側装置又は上記車載端末が、失効されている証明書を検知すると、上記情報を認証局にリアルタイムに通知し、認証局が上記第2リストを作成し、検知場所付近の路側装置及び車載端末に上記第2リストを送信する請求項4記載の通信システム。
  6.  路側装置又は他の車載端末との間で情報の送受信を行う車載端末であって、
     場所ごと時間ごとに証明書が有効な車載端末の第1リスト及び証明書が失効している車載端末の第2リストが記憶された記憶部と、
     メッセージを受信した際に、メッセージ送信者が上記第2リストに存在する場合は、証明書の検証を省略してメッセージを破棄し、メッセージ送信者が上記第1リストに存在する際は、証明書の検証を省略して署名の検証を行う署名生成/検証処理部と、を含むことを特徴とする車載端末。
  7.  上記第1リスト及び上記第2リストの有効場所と有効時間を確認し、自身が有効場所外に存在する場合または有効時間を経過している場合に、上記第1リスト及び上記第2リストを削除する処理部を含む請求項6記載の車載端末。
  8.  車載端末との間で情報の送受信を行う路側装置であって、
     場所ごと時間ごとに証明書が有効な車載端末の第1リスト及び証明書が失効している車載端末の第2リストが記憶された記憶部と、
     車載端末からメッセージを受信した際に、メッセージ送信者が上記第2リストに存在する場合は、証明書の検証を省略してメッセージを破棄し、メッセージ送信者が上記第1リストに存在する際は、証明書の検証を省略して署名の検証を行う署名生成/検証処理部と、を含むことを特徴とする路側装置。
  9.  上記車載端末が上記第1リスト及び上記第2リストの正当性を検証するために必要な共通鍵を上記路側装置から取得する際に、上記車載端末及びその周辺の上記路側装置に認証及び鍵共有に必要な情報を送信する通信制御処理部を含む請求項8記載の路側装置。
  10.  上記第1リスト及び上記第2リストの有効時間を確認し、有効時間を経過している場合に、上記第1リスト及び上記第2リストを削除する処理部を含む請求項9記載の路側装置。
PCT/JP2011/059808 2010-05-24 2011-04-21 通信システム、車載端末、路側装置 WO2011148744A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP11786444.7A EP2579498A4 (en) 2010-05-24 2011-04-21 Communication system, vehicle-mounted terminal, roadside device
US13/698,359 US8819418B2 (en) 2010-05-24 2011-04-21 Communication system, vehicle-mounted terminal, roadside device
CN201180025801.8A CN102907039B (zh) 2010-05-24 2011-04-21 通信***、车载终端、路侧装置
JP2012517200A JP5261614B2 (ja) 2010-05-24 2011-04-21 通信システム、車載端末、路側装置
US14/310,423 US9135820B2 (en) 2010-05-24 2014-06-20 Communication system, vehicle-mounted terminal, roadside device
US14/829,131 US9601016B2 (en) 2010-05-24 2015-08-18 Communication system, vehicle-mounted terminal, roadside device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010-118048 2010-05-24
JP2010118048 2010-05-24

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/698,359 A-371-Of-International US8819418B2 (en) 2010-05-24 2011-04-21 Communication system, vehicle-mounted terminal, roadside device
US14/310,423 Continuation US9135820B2 (en) 2010-05-24 2014-06-20 Communication system, vehicle-mounted terminal, roadside device

Publications (1)

Publication Number Publication Date
WO2011148744A1 true WO2011148744A1 (ja) 2011-12-01

Family

ID=45003736

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/059808 WO2011148744A1 (ja) 2010-05-24 2011-04-21 通信システム、車載端末、路側装置

Country Status (5)

Country Link
US (3) US8819418B2 (ja)
EP (1) EP2579498A4 (ja)
JP (1) JP5261614B2 (ja)
CN (1) CN102907039B (ja)
WO (1) WO2011148744A1 (ja)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012153530A1 (ja) * 2011-05-10 2012-11-15 三洋電機株式会社 端末装置
JP2016105570A (ja) * 2014-11-21 2016-06-09 住友電気工業株式会社 路側機、路側機が実行する方法、サービス提供者装置、移動局
WO2016208227A1 (ja) * 2015-06-22 2016-12-29 Kddi株式会社 管理システム、車両、管理装置、車載コンピュータ、管理方法、及びコンピュータプログラム
JPWO2014108993A1 (ja) * 2013-01-08 2017-01-19 三菱電機株式会社 認証処理装置、認証処理システム、認証処理方法および認証処理プログラム
JP2017046080A (ja) * 2015-08-24 2017-03-02 三菱電機株式会社 車載器、車載器プログラム、車車間通信支援装置および車車間通信支援プログラム
WO2017175592A1 (ja) * 2016-04-05 2017-10-12 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置
WO2017217070A1 (ja) * 2016-06-17 2017-12-21 Kddi株式会社 システム、認証局、車載コンピュータ、車両、公開鍵証明書発行方法、及びプログラム
WO2018003744A1 (ja) * 2016-06-28 2018-01-04 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置
JP2018019415A (ja) * 2017-09-19 2018-02-01 Kddi株式会社 システム、認証局、車載コンピュータ、公開鍵証明書発行方法、及びプログラム
WO2018110323A1 (ja) * 2016-12-14 2018-06-21 株式会社オートネットワーク技術研究所 路車間通信システム、路側通信装置、車載通信装置及び路車間通信方法
WO2018150546A1 (ja) * 2017-02-17 2018-08-23 三菱電機株式会社 車両通信システム、車両通信装置、失効情報発行装置、車両通信方法および車両通信プログラム
CN109040285A (zh) * 2018-08-24 2018-12-18 北京汽车集团有限公司 车载网络安全认证的方法、装置、存储介质及车辆
JP2019009788A (ja) * 2018-08-16 2019-01-17 三菱電機株式会社 車載器、車載器の処理方法および車車間通信支援装置
CN109462836A (zh) * 2018-11-09 2019-03-12 长安大学 融合区块链共识机制的车联网恶意节点检测***及方法
WO2020044667A1 (ja) * 2018-08-28 2020-03-05 パナソニックIpマネジメント株式会社 通信装置、通信システム、通信方法およびコンピュータプログラム

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2579498A4 (en) * 2010-05-24 2017-05-03 Renesas Electronics Corporation Communication system, vehicle-mounted terminal, roadside device
US9365188B1 (en) * 2011-04-22 2016-06-14 Angel A. Penilla Methods and systems for using cloud services to assign e-keys to access vehicles
CN103973760B (zh) * 2013-02-06 2017-12-01 电信科学技术研究院 一种消息证书的申请方法、设备及***
US9425967B2 (en) * 2013-03-20 2016-08-23 Industrial Technology Research Institute Method for certificate generation and revocation with privacy preservation
US20150088618A1 (en) * 2013-08-26 2015-03-26 Ims Solutions, Inc. Road tolling
CN104780141B (zh) 2014-01-10 2018-07-03 电信科学技术研究院 一种车联网***中的消息证书获取方法和设备
DE102014201234A1 (de) * 2014-01-23 2015-07-23 Siemens Aktiengesellschaft Verfahren, Verwaltungsvorrichtung und Gerät zur Zertifikat-basierten Authentifizierung von Kommunikationspartnern in einem Gerät
CN104901921B (zh) * 2014-03-03 2019-01-25 电信科学技术研究院 一种车联网***中的消息传输方法和设备
US9742569B2 (en) * 2014-05-05 2017-08-22 Nxp B.V. System and method for filtering digital certificates
KR101584001B1 (ko) * 2014-10-22 2016-01-08 현대자동차주식회사 V2x 통신을 위한 부정 행위 탐지 방법 및 시스템
JP6173411B2 (ja) * 2014-12-12 2017-08-02 Kddi株式会社 管理装置、車両、管理システム、管理方法、及びコンピュータプログラム
JP6262681B2 (ja) * 2015-03-26 2018-01-17 Kddi株式会社 管理装置、車両、管理方法、及びコンピュータプログラム
WO2017022821A1 (ja) * 2015-08-05 2017-02-09 Kddi株式会社 管理装置、管理システム、鍵生成装置、鍵生成システム、鍵管理システム、車両、管理方法、鍵生成方法、及びコンピュータプログラム
TWI543896B (zh) * 2015-08-26 2016-08-01 財團法人工業技術研究院 通訊裝置、通訊系統與其相關之通訊方法
CN106558210B (zh) * 2015-09-25 2021-02-12 中兴通讯股份有限公司 车联网信息传输方法及装置
CN105355071B (zh) * 2015-11-16 2017-09-29 北京握奇智能科技有限公司 一种车载终端实路动态定位精度的自动化评估***和方法
KR101759136B1 (ko) * 2015-11-17 2017-07-31 현대자동차주식회사 차량 헤드 유닛과 외부 기기 연동 시 차량 전용 데이터 채널 보안 서비스 제공 방법 및 그를 위한 장치
JP6190443B2 (ja) * 2015-12-28 2017-08-30 Kddi株式会社 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム
TWI600334B (zh) * 2016-03-23 2017-09-21 財團法人工業技術研究院 車輛網路節點之安全憑證管理方法與應用其之車輛網路節 點
JP6641241B2 (ja) * 2016-07-04 2020-02-05 株式会社日立製作所 情報共有システム、計算機、及び、情報共有方法
US9936440B2 (en) * 2016-07-12 2018-04-03 Coco Communications Corp. Systems and methods for automatic transmission rate control in a vehicle-based wireless network
FR3057973B1 (fr) * 2016-10-25 2018-11-30 Peugeot Citroen Automobiles Sa Procede d'installation d'un certificat dans un calculateur de vehicule, calculateur et systeme associes
US10432612B2 (en) * 2016-10-27 2019-10-01 Panasonic Avionics Corporation Methods and systems for remote access to a transporation vehicle system
CN108076016B (zh) * 2016-11-15 2021-07-02 ***通信有限公司研究院 车载设备之间的认证方法及装置
US10593198B2 (en) * 2016-12-06 2020-03-17 Flir Commercial Systems, Inc. Infrastructure to vehicle communication protocol
EP3337119B1 (en) 2016-12-13 2019-09-11 Nxp B.V. Updating and distributing secret keys in a distributed network
US10171953B2 (en) 2016-12-15 2019-01-01 At&T Mobility Ii Llc Vehicle event notification via cell broadcast
US11025607B2 (en) 2016-12-15 2021-06-01 At&T Mobility Ii Llc V2X certificate management
WO2018182198A1 (ko) * 2017-03-29 2018-10-04 엘지전자(주) V2x 통신 장치 및 그의 데이터 통신 방법
EP3624472A1 (en) * 2017-05-31 2020-03-18 Huawei Technologies Co., Ltd. Information processing method, device and system
EP3418998A1 (en) * 2017-06-22 2018-12-26 Nokia Technologies Oy Road traffic management
US11041279B2 (en) 2017-06-27 2021-06-22 James Darren KNIGHT Markers, culvert markers, location markers, combinations, and methods of use
WO2019066114A1 (ko) * 2017-09-29 2019-04-04 엘지전자(주) V2x 통신 장치 및 그의 키 위변조 검사 방법
US10645094B2 (en) 2018-02-16 2020-05-05 Integrity Security Services Llc Systems, methods, and devices for provisioning and processing geolocation information for computerized devices
US11303458B2 (en) 2018-04-09 2022-04-12 Blackberry Limited Method and system for reduced V2X receiver processing load using network based application layer message processing
US11050556B2 (en) * 2018-07-13 2021-06-29 Micron Technology, Inc. Secure vehicular communication
US10880812B2 (en) * 2018-07-23 2020-12-29 Blackberry Limited Vehicle-to-everything (V2X) service access
US11184178B2 (en) * 2018-09-28 2021-11-23 Blackberry Limited Method and system for intelligent transportation system certificate revocation list reduction
CN109523785A (zh) * 2018-11-29 2019-03-26 奇瑞汽车股份有限公司 车辆驾驶提示方法及***
US11088821B2 (en) 2019-03-25 2021-08-10 Micron Technology, Inc. Secure communication in a traffic control network
US11373527B2 (en) * 2019-03-25 2022-06-28 Micron Technology, Inc. Driver assistance for non-autonomous vehicle in an autonomous environment
CN111917685B (zh) * 2019-05-07 2022-05-31 华为云计算技术有限公司 一种申请数字证书的方法
CN110263526B (zh) * 2019-06-13 2023-08-18 惠州市德赛西威汽车电子股份有限公司 一种产线证书注入***及其方法
JP7298356B2 (ja) * 2019-07-16 2023-06-27 富士フイルムビジネスイノベーション株式会社 情報処理装置及び情報処理プログラム
CN110519053A (zh) * 2019-08-28 2019-11-29 深圳成谷科技有限公司 基于pc5接口长期密钥的安全保护机制设计方法和装置
CN110809250B (zh) * 2019-09-09 2022-07-12 天地融科技股份有限公司 读写终端与n个车载单元通信的方法及读写终端
CN112929174B (zh) * 2019-12-06 2022-07-22 华为技术有限公司 一种证书撤销列表更新方法及相关设备
CN111698650B (zh) * 2020-06-16 2022-02-11 郑州信大捷安信息技术股份有限公司 数字证书状态协作查询方法、通信方法及***
CN111711937B (zh) * 2020-06-16 2022-02-11 郑州信大捷安信息技术股份有限公司 用于车联网v2x通信的在线证书状态获取方法和***
CN114449513A (zh) * 2020-10-16 2022-05-06 中移(上海)信息通信科技有限公司 路侧设备的鉴权方法、装置、设备及计算机存储介质
CN112489458B (zh) * 2020-11-05 2021-11-09 暨南大学 基于v2x技术的可信、隐私保护的智能红绿灯方法及***
CN113709695B (zh) * 2021-08-04 2024-04-09 一汽解放汽车有限公司 车辆使用的授权方法及***
WO2023070465A1 (zh) * 2021-10-28 2023-05-04 华为技术有限公司 一种密钥传输方法和装置
CN114339680B (zh) * 2022-03-07 2022-06-07 高新兴智联科技有限公司 一种v2x***及安全认证方法
CN115297097A (zh) * 2022-07-07 2022-11-04 广州市大周电子科技有限公司 一种车载端一体机***及一体机
CN115694891B (zh) * 2022-09-23 2024-05-14 智己汽车科技有限公司 一种基于中央计算平台的路侧设备通信***及方法
CN116403297A (zh) * 2022-12-19 2023-07-07 广州柏瀚信息科技有限公司 一种高速公路黑名单车辆拦截方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007088737A (ja) 2005-09-21 2007-04-05 Toyota Infotechnology Center Co Ltd 路車間通信システム、車載端末、及び路車間通信方法
JP2008060789A (ja) * 2006-08-30 2008-03-13 Toyota Infotechnology Center Co Ltd 公開鍵配布システムおよび公開鍵配布方法
EP2034661A1 (en) * 2007-09-07 2009-03-11 Deutsche Telekom AG Method and system for distributed, localized authentication in the framework of 802.11

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7596606B2 (en) * 1999-03-11 2009-09-29 Codignotto John D Message publishing system for publishing messages from identified, authorized senders
JP4758095B2 (ja) * 2004-01-09 2011-08-24 株式会社リコー 証明書無効化装置、通信装置、証明書無効化システム、プログラム及び記録媒体
WO2005116794A1 (en) * 2004-05-28 2005-12-08 Koninklijke Philips Electronics N.V. License management in a privacy preserving information distribution system
EP1756694B1 (en) 2004-06-04 2016-03-30 Koninklijke Philips N.V. Authentication method for authenticating a first party to a second party
US20070187491A1 (en) * 2006-02-13 2007-08-16 Godwin Bryan W Processing Cashless Transactions of Remote Field Assets
CN101051419A (zh) * 2006-04-05 2007-10-10 中国科学院电子学研究所 基于无线传感器网络的车路交互***和方法
US8171283B2 (en) * 2007-03-19 2012-05-01 Telcordia Technologies, Inc. Vehicle segment certificate management using short-lived, unlinked certificate schemes
US8214895B2 (en) * 2007-09-26 2012-07-03 Microsoft Corporation Whitelist and blacklist identification data
US8090949B2 (en) * 2008-03-13 2012-01-03 GM Global Technology Operations LLC Certificate assignment strategies for efficient operation of the PKI-based security architecture in a vehicular network
US9461827B2 (en) * 2008-04-11 2016-10-04 Toyota Motor Engineering & Manufacturing North America, Inc. Method for distributing a list of certificate revocations in a vanet
US8230215B2 (en) * 2008-04-11 2012-07-24 Toyota Motor Engineering & Manufacturing North America, Inc. Method for allocating multiple authentication certificates to vehicles in a vehicle-to-vehicle communication network
JP5223625B2 (ja) * 2008-11-26 2013-06-26 富士通株式会社 通信システム、基地局装置、及び通信方法
CN101582200B (zh) * 2009-05-31 2011-10-05 杭州全动科技有限公司 全天候行车管理***及管理方法
CN101616165B (zh) * 2009-07-28 2013-03-13 江苏先安科技有限公司 一种新型x509数字证书白名单发布查询验证的方法
US8973129B2 (en) * 2009-08-31 2015-03-03 Tt Government Solutions, Inc. System and method for detecting and evicting malicious vehicles in a vehicle communications network
US8627073B2 (en) * 2010-03-24 2014-01-07 GM Global Technology Operations LLC Adaptive certificate distribution mechanism in vehicular networks using forward error correcting codes
EP2579498A4 (en) * 2010-05-24 2017-05-03 Renesas Electronics Corporation Communication system, vehicle-mounted terminal, roadside device
TWI433558B (zh) * 2011-12-05 2014-04-01 Ind Tech Res Inst 動態調整憑證撤銷清單更新頻率的方法及系統
KR101592788B1 (ko) * 2014-11-19 2016-02-18 현대자동차주식회사 이상 차량 처리 방법 및 이를 수행하는 v2x 통신 시스템

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007088737A (ja) 2005-09-21 2007-04-05 Toyota Infotechnology Center Co Ltd 路車間通信システム、車載端末、及び路車間通信方法
JP2008060789A (ja) * 2006-08-30 2008-03-13 Toyota Infotechnology Center Co Ltd 公開鍵配布システムおよび公開鍵配布方法
EP2034661A1 (en) * 2007-09-07 2009-03-11 Deutsche Telekom AG Method and system for distributed, localized authentication in the framework of 802.11

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2579498A4

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012153530A1 (ja) * 2011-05-10 2012-11-15 三洋電機株式会社 端末装置
JPWO2014108993A1 (ja) * 2013-01-08 2017-01-19 三菱電機株式会社 認証処理装置、認証処理システム、認証処理方法および認証処理プログラム
US9667616B2 (en) 2013-01-08 2017-05-30 Mitsubishi Electric Corporation Authentication processing apparatus, authentication processing system, authentication processing method and authentication processing program
JP2016105570A (ja) * 2014-11-21 2016-06-09 住友電気工業株式会社 路側機、路側機が実行する方法、サービス提供者装置、移動局
WO2016208227A1 (ja) * 2015-06-22 2016-12-29 Kddi株式会社 管理システム、車両、管理装置、車載コンピュータ、管理方法、及びコンピュータプログラム
JP2017046080A (ja) * 2015-08-24 2017-03-02 三菱電機株式会社 車載器、車載器プログラム、車車間通信支援装置および車車間通信支援プログラム
WO2017175592A1 (ja) * 2016-04-05 2017-10-12 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置
JP2017188774A (ja) * 2016-04-05 2017-10-12 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置
WO2017217070A1 (ja) * 2016-06-17 2017-12-21 Kddi株式会社 システム、認証局、車載コンピュータ、車両、公開鍵証明書発行方法、及びプログラム
JP2018006875A (ja) * 2016-06-28 2018-01-11 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置
WO2018003744A1 (ja) * 2016-06-28 2018-01-04 株式会社オートネットワーク技術研究所 通信システム及び車載通信装置
WO2018110323A1 (ja) * 2016-12-14 2018-06-21 株式会社オートネットワーク技術研究所 路車間通信システム、路側通信装置、車載通信装置及び路車間通信方法
JP2018097668A (ja) * 2016-12-14 2018-06-21 株式会社オートネットワーク技術研究所 路車間通信システム、路側通信装置、車載通信装置及び路車間通信方法
WO2018150546A1 (ja) * 2017-02-17 2018-08-23 三菱電機株式会社 車両通信システム、車両通信装置、失効情報発行装置、車両通信方法および車両通信プログラム
JP2018019415A (ja) * 2017-09-19 2018-02-01 Kddi株式会社 システム、認証局、車載コンピュータ、公開鍵証明書発行方法、及びプログラム
JP2019009788A (ja) * 2018-08-16 2019-01-17 三菱電機株式会社 車載器、車載器の処理方法および車車間通信支援装置
CN109040285A (zh) * 2018-08-24 2018-12-18 北京汽车集团有限公司 车载网络安全认证的方法、装置、存储介质及车辆
CN109040285B (zh) * 2018-08-24 2023-06-20 北京汽车集团有限公司 车载网络安全认证的方法、装置、存储介质及车辆
WO2020044667A1 (ja) * 2018-08-28 2020-03-05 パナソニックIpマネジメント株式会社 通信装置、通信システム、通信方法およびコンピュータプログラム
CN109462836A (zh) * 2018-11-09 2019-03-12 长安大学 融合区块链共识机制的车联网恶意节点检测***及方法

Also Published As

Publication number Publication date
JPWO2011148744A1 (ja) 2013-07-25
JP5261614B2 (ja) 2013-08-14
CN102907039B (zh) 2016-03-16
EP2579498A1 (en) 2013-04-10
US8819418B2 (en) 2014-08-26
US9135820B2 (en) 2015-09-15
US9601016B2 (en) 2017-03-21
CN102907039A (zh) 2013-01-30
EP2579498A4 (en) 2017-05-03
US20130067220A1 (en) 2013-03-14
US20150358170A1 (en) 2015-12-10
US20140303881A1 (en) 2014-10-09

Similar Documents

Publication Publication Date Title
JP5261614B2 (ja) 通信システム、車載端末、路側装置
JP5587239B2 (ja) 車車/路車間通信システム
US7734050B2 (en) Digital certificate pool
JP4680730B2 (ja) 路車間通信システム、車載端末、及び路車間通信方法
JP5967822B2 (ja) 車載通信システム及び装置
JP5895216B2 (ja) 車載器
KR101837338B1 (ko) Vanet을 위한 클라우드 지원 조건부 프라이버시를 보호하는 인증 방법 및 시스템
US7742603B2 (en) Security for anonymous vehicular broadcast messages
CN102027705B (zh) 车载网络中基于pki安全架构的有效操作的认证分配策略
US20130195272A1 (en) Base station apparatus for transmitting or receiving a signal containing predetermined information
JP2013513256A (ja) 限られた数のインフラ・サーバを有する自動車ネットワーク向け公開鍵インフラに関する方法
KR20200091689A (ko) 차량 통신을 위한 보안 관리 시스템, 그것의 동작 방법, 및 그것을 포함하는 차량 통신 서비스 제공 시스템의 메시지 처리 방법
CN104053149A (zh) 一种实现车联网设备的安全机制的方法及***
JP2021510481A (ja) デジタル認証書の撤回のための活性化コードを用いた暗号化方法及びそのシステム
CN109196817B (zh) 通信***以及车载通信装置
KR20190056661A (ko) 차량 네트워크에서 기지국 기반 보안 통신 방법
JP2016119543A (ja) 無線通信装置、サーバ、移動局、及びそれらに関する方法
CN111698650B (zh) 数字证书状态协作查询方法、通信方法及***
Klaassen et al. Security for V2X
JP4540681B2 (ja) 通信セキュリティ保持方法及びその実施装置並びにその処理プログラム
CN111711938B (zh) 基于数字证书的车联网安全通信方法及***
CN111865607B (zh) 用于v2x的加密证书状态在线查询方法、通信方法及***
CN111711937A (zh) 用于车联网v2x通信的在线证书状态获取方法和***

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180025801.8

Country of ref document: CN

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

Ref document number: 11786444

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012517200

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2011786444

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13698359

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE