Current solutions for security vulnerabilities in inter-vehicle communication systems*
- Certification in VANET Systems
In the system called VANET, certification authorities, identification, hardware security module, and secure communication networks are mentioned. Especially in the wireless communication intensive system, the importance of offline protection and data integrity in the vehicle is also given importance.
Numerous certification authorities are envisaged in the system. These authorities shall be physically separated by zones and each authority shall be responsible for its territory. In order to be used in transit between the authorities, the authorities will certify each other with cross certification and these physical zones will be able to switch vehicles.
1.1. Long Term Identity and Certificate
Each vehicle will have a long term identity and will be licensed by a single certification authority. Long-term identity will be protected by a private open and closed key pair. All information including the certificate and the certificate will be included in the certificate. The type of vehicle, its physical characteristics, its equipment, and the power of operation are some of the information contained in this certificate. The certification authority will be fully responsible for the distribution of certificates and for the retrieval of certificates for any misuse. Since the vehicle is long-term, it will not be necessary for the vehicle to frequently connect to the network to renew the certificate and to load the network for certificate synchronization.
1.2. Hardware Security Module
The hardware security module basically performs two functions. The first function of this module is to physically store the information on the vehicle and protect it from online and offline attacks. If an attack is attempted to seize modular out-of-doors keys, the module will destroy all information in its contents and prevent them from being seized. The second function is to produce short-circuited certificates for use in communications. The hardware security module, separate from the vehicles communication unit on the vehicle as hardware, deals with digital signature generation and decryption of encrypted messages. If the certification authority cancels the certification of a hardware security module, an emergency shutdown key embedded in this module enters and all information in the memory is erased.
1.3. Short Term Pseudonym Certificates
Short-term certificates will be used to provide secure communication between long-term certificates as well as short-circuited Pseudonym certification systems and vehicles and road markers. Pseudonym certificates do not contain car information at all, but are produced by the hardware security module linked to long-running certificates and are used only once for very short periods. Once a short-term certificate is used, it is never used again. This method is important so that the messages produced from the vehicle cannot be related to each other. However, when used in conjunction with the public key certificate authority of the Pseudonym certificate, the closed key will be protected within the hardware security module and only one short key certificate will be allowed in any vehicle in a vehicle. Certificates will change with transitions between time limits or roadside markers. A vehicle module seized on this voucher will not be able to send messages to more than one sign with the same certificate, or the same sign will not appear as more than one vehicle. This will significantly limit the contamination within the system. [7]
Because these Pseudonym certifications are linked to long-term certification, and because these long-term certificates are also dependent on the certification authority of a particular region, a foreign vehicle traveling between the roadside markers will be at risk of being followed up easily. In order to overcome this problem, a certificate from the certificate authority of the new entry zone will be issued shortly and the pseudonym certificates will be produced with the certificate of this region. At this point, road markers will not know that the vehicle is foreign or local, and this information will not be transmitted to an attacker listening to the system.
2. Certification in SCMS Systems
When the certification methods of SCMS systems are mentioned, a summary can be made as follows. [4]:
· SCMS manager: works on the definition of misbehavior and the correctness of certificate revocation.
· Certification services: Describes device types and certification process to be certified.
· Revoked certificate list repository: maintains and distributes revoked certificates.
· Revoked certificate list broadcast: Announces the list to all vehicles thanks to road markers.
· Device: Vehicle on the vehicle is the name given to the communication module.
· Device setup manager: Applies and approves the change of the device’s network address or certificate.
· Certificate registrar: Pseudonym is the authority that approves certifications that describe the pseudonym certificate request permissions of the device during certificate request.
· Location concealment proxy: When the car makes a connection, the connection is made through a proxy server so that the location of the car is hidden.
· Misconduct authority: It is authorized to detect misconduct and revoke certificate. It holds a blacklist to be shared with other authorities.
· Pseudonym Certificate authority: Produces a pseudonym certificate. A particular region or vehicle manufacturer may be limited by features such as vehicle type.
· Registration authority: evaluates, approves, and transmits Pseudonym certificate requests to the Pseudonym certificate authority.
· Request editor: Allows a vehicle to not send more than one certificate request in a given period of time
It is very important to make certain predictions about the certificate supply in terms of size, connection load and attacks and to set the certificate times and numbers correctly accordingly. Setting up a model that slows the system’s operation or puts the system at risk will render the system inoperable. One of the predictions to be made is a conflict between certificate delivery and storage size. In order for the device to be able to change frequent certifications frequently, a large number of certificates must be kept in memory or the device must be frequently connected to install new certifications. Since the first method is expensive and the second method is physically challenging, an optimal point must be found between the two. Storing and distributing revoked certificates is a similar question, as well as an optimum point in this regard.
2.1. Butterfly Switch Expansion
The butterfly switch design is a system that is used to process a large number of certificates, each encrypted with its own open and closed key pair, with a single open key and with two expansion functions. At this point the vehicle does not send a separate clear key for each certificate, and the load on the network is severely reduced. In addition, the workload on the on-board device, which does not have to produce a public key for each certificate, is reduced.
*For the full text, please visit: https://www.preprints.org/manuscript/201706.0001/v1
References
[1] Itagaki S., Outline of safety support systems for intersections and NEC’s activity, NEC Technical Journal, March 2008.
[2] Le L., Baldessari A. F., Zhang R., V2X Communications and Intersection Safety, 2008, 97–107.
[3] Papadimitratos P., Buttlyan L., Holczer T., Schoch E., Freudiger J., Raya M., Secure Vehicular Comminication Systems: Design and Architecture. Topics in Automotive Networking, 2008, 100–109.
[4] Whyte W., Weimerskirch A., Kumar V., Hehn T., A Security Credential Management Systems for V2V Communications, Vehicular Networking Conference, 2013, 1–8
[5] Fuentes J., Gonzales-Tablas A., Ribagorda A., Overview of Security Issues in Vehicular Ad-hoc Networks, Handbook of Research on Mobility and Computing, 2010.
[6] Le L., Festag A., Baldessari R., Zhang W., Vehicular Wireless Short-Range Communication for Improving Intersection Safety, Topics in Aıtomotive Networking, 2009. 104–110
[7] Bismeyer N., Stübing H., Schoch E., Götz S., Stotz J. P., Lonc S., A Generic Public Key Infrastructure for Securing Car to X Communication, 2010.
[8] D. Aydinli, E. Koroglu, V. Erol, Abuse of Mobile Devices by Making Reverse Proxy Server. Preprints 2017, 2017050123 (doi: 10.20944/preprints201705.0123.v1), 2017.
[9] K. Imamoglu, V. Erol, G. Cetin, Enabling Secure Platforms with Trusted Computing, IEEE 2nd Conference on Homeland Safety and Security (TEHOSS 2006), 2006.