In this section, the following aspects of the proposed VCC-SSF are discussed in detail: the VCC-SSF Architecture, Application Service Layer, and Security Layer.
3.1. Architecture of VCC-SSF
VCC-SSF for the VCC environment is composed of three layers: Core Technology, Security, and Application Services. Figure 1
shows the architecture of VCC-SSF.
Architecture of VCC-SSF.
Architecture of VCC-SSF.
The Core Technology Layer is the layer handling the V2X of vehicle computing and Cloud Computing technologies, i.e., the core technology of VCC-SSF. The V2X comprises the V2V, V2I, IVN, and V2N technologies, and it facilitates communication between vehicles and between the vehicle and infrastructure. In addition, its technologies are related to Cloud Computing, such as storage virtualization, server virtualization, and cloud storage management.
The Security Layer is the layer providing functions such as authentication, encryption, access control, and privacy protection. Furthermore, it authenticates stationary and driving vehicles and encrypts personal identification and sensitive information (e.g., location, payment, traffic, and accident information). In addition, it provides access control to the internal and external systems of the vehicle for permitted objects, and protects personal privacy such as video and voice data in the vehicle black box, payment information, personal identification information, location information, etc.
The Application Service Layer provides services to the driver or user utilizing V2X communication to access the collected data in a VCC environment. Two services are provided: Payment Service and Accident Management Service. The Payment Service allows the user to automatically pay for desired goods and consumables inside the vehicle in advance. The Accident Management Service prevents accidents that may occur on the road, provides response when an accident occurs, and provides management for vehicles involved in the accident.
3.2. Application Service Layer
We discuss the proposed Payment and Accident Management Services provided by the VCC-SSF in this subsection.
In the proposed Payment Service, Product Management receives the user’s purchase requirements or utilizes sensor information inside the vehicle to automatically list the goods to purchase. It then finds nearby shops and searches their inventory. In addition, it checks the information inside the vehicle using the sensors and automatically asks for confirmation by the user before making payment. Product Management carries out the goods purchase and payment in the VCC environment, using V2I communication to receive the user’s receipt. The receipt lists the purchased goods information (groceries, home appliances, meats, clothes, vegetables, etc.
), vehicle consumables information (fuel in the vehicle, engine oil, brake oil, tire wear conditions, drive belt, battery, etc.
), or reservation information (hotel, parking lot, hospital reservations, etc.
). Only authenticated users can use the Payment Service, and the registered private information, payment information, and payment list are protected by encryption. In addition, to verify transaction and payment actions and prevent denial of the transaction, the communication is verified through hash algorithms and digital signatures. Figure 2
shows the concept of a payment service.
Accident Management Service:
The Accident Management Service protects the life of accident victims by enabling quick first aid responses when a traffic accident occurs. Furthermore, it eases traffic congestion by managing the accident vehicle, and, in many cases, can prevent the fundamental cause of accidents. Using active accident management, it notifies nearby vehicles of the accident occurrence and conditions in real time, and when an emergency vehicle requires access, it broadcasts this communication to all vehicles. Figure 1
shows the architecture of the proposed Accident Management Service.
The proposed Accident Management Service uses VCC. It has two modes: before and after an accident. Before an accident occurrence, it utilizes a human body detection sensor inside the vehicle to monitor the health status and driving capability of the driver. In addition, using V2V and V2I communication during driving, it periodically checks the maintenance of the traffic lane and status of the vehicle. In addition, V2V communication is utilized to recognize vehicles approaching at a certain distance and, by notifying the driver, it helps to prevent a secondary accident occurrence.
After an accident occurs, it checks the driver for injuries, and through communication inside the vehicle such as the Electronic Control Unit (ECU), it determines the damage status. This information is sent to the traffic control center, and, by connecting to the nearest hospital and police station, it supports quick dispatch of emergency services and takes action for transportation to a nearby hospital according to the status of the accident victim. These processes, from active response and action to the management of the accident vehicle, are carried out utilizing VCC. The architecture of Accident Management System is shown in Figure 3
Architecture of accident management system.
Architecture of accident management system.
3.3. Security Layer
As vehicle computing advances, vehicles are also able to process sensitive information such as vehicle location and unique information as well as driver personal information and health status through the sensors. If the information is extorted or manipulated by a malicious attacker, it may cause financial or physical damage to the user. In this subsection, we discuss the Security Layer, which is a core part of the proposed framework. The Security Layer is composed of Authentication, Data Integrity, Encryption, Access Control, and Privacy Protection. We define the terms used in Table 1
for security layer.
Authentication: Vehicle authentication can prevent malicious attacks such as Denial of Service (DoS), Distributed Denial of Service (DDoS), and black hole attacks. When a person tries to access information inside the vehicle or the driver’s personal information, this information should be provided only to users with permission. Vehicle authentication is considered separately depending on whether the vehicle is stationary or moving. The reason for this is that Storage as a Service (SaaS) and Computing as a Service (CompaaS) only utilize the storage and computing resources of a stationary or parked vehicle using vehicle authentication in shopping malls and parking lots. In addition, services to provide real time information such as Emergency or Accident Management Services need to send information to the police station, hospital, or other vehicles very quickly.
Definition of terms.
Definition of terms.
|VS/VM||Stationary vehicle/Moving vehicle|
|CA/U/SP||Certificate Authority/User/Service Provider|
|RSU/ECU||Road Side Unit/Electronic Control Unit|
|Hash ( )/Shift ( )||Hash Algorithm/Circular Shift Operation|
|Ex ( )/Dy ( )||Encryption algorithm using x key/Decryption algorithm using y key|
|Sigx ( )/Veryy ( )||Signature algorithm using x key/Verification algorithm using y key|
|C/P/Cert||Encrypted Message/Plain Text/Certificate|
|Kx_prv/Kx_pub||Private Key of X/Public Key of X|
|PVID/RID||Pseudo Vehicular ID/Road Side Unit ID|
|DN/VN||Driver Number/Vehicle Number|
|X_TS||Time Stamp Values of X|
|ET||Expiry Time of Certificate|
|AcNo||Number of Accesses|
The definition of stationary and moving vehicles is as follows. The boundary of an RSU is defined as RSUn
, …, RSUn
], n = 1, 2, 3, …, n. If the vehicle is stationary, the Vehicular Time Stamp (V_TS) value becomes 0. If the vehicle is moving, V_TS value has a value of 1 or greater. The V_TS is the time the vehicle passes each RSU. Using the difference of V_TS values, the RSU determines the movement of the vehicle. The V_TS value is used to authenticate a moving vehicle. The areas within which each RSU recognizes the vehicle overlap, and hence vehicle authentication is possible without network disconnection.
V_TS = V_TSRSUn − V_TSRSUn-1
Authentication procedure: Vehicle authentication utilizes V2I communication. Using the Pseudo Vehicular ID (PVID) and driver’s Driver Number (DN) issued by the RSU, certificates are issued from the Certificate Authority (CA). The issued certificates are signed with Kca_prv, and the vehicle verifies the certificate with Kca_pub.
If (V_TS = 0) then
Deliver CA → VS: Cert VS = [Hash(PVID ⊕ DN), C_TS, ET, RID, AcNo] Kca_prv
Deliver CA → VM: Cert VM = [Hash(PVID ⊕ DN), RID, C_TS, ET, RID, AcNo] Kca_prv
If V_TS is 0, the vehicle is considered to be stationary. The stationary vehicle is marked as VS, and the CA issues the certificate to VS. The certificate includes the PVID and DN hash value, Time Stamp values of Certificate (C_TS), Expiry time of Certificate (ET), Road Side Unit ID (RID), and the Number of Accesses (AcNo). The C_TS is the time when the certificate is issued, and the ET is the expiration time of the certificate. The RID is the unique ID of the previous RSU, and by storing the IDs of RSU that vehicle has already passed, the system can verify the previous route. AcNo is the number of authentication attempts allowed. If there are more than AcNo access attempts, access and authentication to the corresponding vehicle is restricted.
Information encryption, along with integrity, should be provided. Hash functions and digital signatures are used to provide data integrity.
Data integrity procedure: Data integrity is provided for the Critical Info (i.e., Personal Information, Payment Information, Location, User Information, and User State), which is sensitive information used both inside and outside the vehicle. This procedure is as follows.
Signing VS, VM → RSU: Sig Kv_prv (Hash(Critical Info)) || P
To maintain data integrity inside the vehicle, the user hashes the Critical Info and signs it with Kv_prv to generate a hash value. This is then sent to the RSU along with the original information P.
Verifying RSU: H = Very Kv_pub (Hash(Critical Info))
The signed data is verified using Kv_pub, registered in the CA. In addition, the hash value is compared with hashing P. Hash value H is obtained after the mutual verification to check whether data integrity is guaranteed.
In VCC, sensitive information inside the vehicle, such as the private information and financial payment information as well as the ECU information that is collected using the On Board Unit (OBU) and On Board Equipment (OBE), should be protected through encryption.
Encryption of the information inside the vehicle: The Drive System, Braking System, Steering System, etc. inside the vehicle are controlled through the ECU. This information is frequently used inside the vehicle for service or function, and hence fast encryption is required. In this system, a symmetric key encryption method is used. Key generation is as follows:
Generate Key = Shift(VN) ⊕ RK
The 128-bit unique number (VN) assigned by the manufacturer is used as the key for the symmetric key encryption. We perform a circular shift operation by seven bits on the VN, and eXclusive-OR the result with RK, generated using a random number generator inside the vehicle, to generate the final key.
Encrypt OBD, OBU → U: C = EKey (VC_Int_Info)
VC_Int_Info (i.e., Speed, Fuel, Oil Pressure, Tire Condition, GPS, Temperature, etc.) is displayed to the user inside the vehicle by the OBD. The OBU is also encrypted using a symmetric key encryption algorithm.
Encryption for information using infrastructure: In the Application Layer, services are frequently provided through infrastructure, and the VC_Ext_Info (i.e., Personal Information, Payment Information, Location, User Information, and User State) is encrypted using a public key encryption algorithm.
Encrypt VS, VM → RSU: C = E Ksp_pub (Hash(VC_Ext_Info))
VC_Ext_Info is sent to an RSU by encrypting the hash value obtained by hashing the key of the Service Provider (SP) Ksp_pub. Key Ksp_pub is managed in the CA.
SP decrypts the encrypted data using Ksp_prv, and hashes it to finally obtain and use VC_Ext_Info.
Decrypt RSU → SP: P = D Ksp_prv (Hash(VC_Ext_Info))
In the VCC environment, access to sensitive information should be restricted when there is no legitimately granted authority. The access control monitors attempts to access the vehicle information system from inside and outside the vehicle in VCC.
Access control for the internal system:
The internal system displays the sensor information visually to the user through the OBU. There are various subjects that attempt to access this information. For example, car mechanics attempting to repair the vehicle, the vehicle owner, drivers other than the owner, and malicious attackers. When objects try to access this information, the role-based access controls access according to the situation information. In addition, we consider the time and place. No subjects except the vehicle owner can access the personal identification information. The example of role-based access control for time and location is shown in Table 2
Example of role-based access control for time and location.
Example of role-based access control for time and location.
|Time||R1: 06:00–24:00||P1, P2, P3|
|R2: 00:00–06:00||P1, P2 (Optional)|
|Location||R3: Parking lot||P1, P2 (Optional)|
|R4: Road||P1, P2 (Optional)|
|R5: Repair shop||P1, P3|
Role-based access control that takes into account situation information permits access to information inside the vehicle from 6:00–24:00 h by all subjects except others. Access control information for each subject is listed in Table 3
. The vehicle owner has permission P1 to access all information. A guest driver is provided with P2 permission, and is given only the information required for driving the vehicle. A car mechanic has the P3 rights, and is provided only the information required for maintenance. Others have P4 rights, the lowest level of permission, and cannot access any information. For example, the vehicle owner can register a guest driver on the system, and access is limited to the location or traffic information required for the driving. A car mechanic can access the information during R1 hours, since this type of work is done during the day, and the information is limited to start-up, steering, or braking system information as required for vehicle repair. Finally, persons who are not registered by the vehicle owner are considered to be “others,” and they have no authority. The owner and guest drivers have access to their allowed information at any hour.
Access control information for each object.
Access control information for each object.
|Vehicle owner||P1||Can access all information|
|Guest driver||P2||Driving information, traffic information|
|Car mechanic||P3||Information of Drive System, Braking System, Steering System, etc.|
Role-based access control considers three locations: parking lot, road, and repair shop. For example, in a parking lot or on the road, only the vehicle owner and the guest driver can access information. In contrast, in the repair shop, only the car mechanic and owner have access to information.
Access control for outside the vehicle: From outside the vehicle, using V2V and V2I communication, traffic infrastructure and external vehicles also attempt to access the internal information. The traffic infrastructure attempts to access the location for traffic analysis or vehicle authentication. External vehicles attempt to access the information for services such as collision prevention or traffic lane maintenance as well as V2V communication. In both cases, the corresponding vehicle should also control the access of the traffic infrastructure and external vehicles. Only correctly authenticated vehicles can exchange information, but the other vehicles cannot access the information without permission.
Access control from outside the vehicle.
Access control from outside the vehicle.
|Authentication completed||A1: Full access permitted||Can access all information|
|A2: Only authenticated vehicles inside the cluster can access the information (e.g., location, destination, and traffic information sharing)||Information can be shared only within the cluster|
|A3: Only the authenticated traffic infrastructure can access the information||Information transmission to the traffic infrastructure|
|Partial authentication completed||P1: Information is shared with emergency vehicles||First aid, rescue, police vehicles, etc.|
|Authentication is not possible||N1: Cannot access the information||Vehicles without permission cannot access any information|
Access control from outside the vehicle is divided into access for subjects that complete authentication and access for subjects that cannot. Table 4
shows the access control from outside the vehicle. For example, only when authenticated subjects with roles A1, A2, or A3 and partially authenticated subjects (first aid, rescue, police, etc.
) try to access the information is the access to the vehicle location or traffic information permitted. Unauthenticated subjects take on role N1; for them, access to all information is restricted. For role A1, access to all information is permitted for vehicles that complete authentication. For role A2 in the VANET environment, a small logical cluster is generated and V2V communication between subjects inside the cluster is possible. However, only location, destination, traffic, and entertainment information can be shared inside the cluster. The VN or DN of each vehicle cannot be accessed. For role A3, because of the characteristics of the VCC environment, communication with nearby RSUs is frequent. In this case, an RSU requests access or sends data to the vehicle for authentication or traffic information collection. The corresponding vehicle checks the RID of the requesting RSU, bestows A3 authority, and blocks access to the DN. It permits access to other information for traffic analysis. However, access is restricted for unauthenticated RSUs.
Among the information transmitted in the VCC environment, privacy protection should be considered for the driver or user identification information, vehicle location information, video or voice recorded by the vehicle black box, payment information used in Payment Services, etc.
This information is used for the convenience of the driver or the user, but when it is exposed to malicious attackers, this could cause the user financial damage or defamation. We address privacy protection in the following two ways:
Privacy protection with a vehicle alias ID: In the VCC environment, the vehicle authentication process uses the PVID. Instead of using the VN, we use a PVID assigned by an RSU during authentication. The VN is the unique number of each vehicle. Hence there is a risk of exposure of the vehicle owner’s personal information through inquiry to the management system. However, if a PVID is used, authentication can be performed without exposing the VN.
Privacy protection with data encryption: An invasion of privacy occurs when the private identification information, location information, or video captured by the black box inside the vehicle are exposed to others. However, if this information is encrypted inside or outside the vehicle and not displayed to others, invasion of privacy does not occur. As mentioned above, the privacy of the DN, payment information, location information, and data in the black box can be protected using encryption.
3.4. Analysis of VCC-SSF
In this section, we analyze VCC-SSF to compare with methods that are proposed in previous studies based on security concerns—Confidentiality, Integrity, Availability, and Privacy Protection in the VCC environment. The security comparison is shown in Table 5
|Classification||Wan et al. ||Wan et al. ||Ma et al. ||Hussain and Oh ||Sur et al. ||VCC-SSF|
Data are generated through many sensors in the vehicle. In addition, private identification information, payment information, location information, etc.
are provided from or sent to the traffic infrastructure. In this case, only permitted vehicles should be able to receive services, and user access to important information should be separated through access control. In addition, the information should be encrypted to prevent exposure to external users. The VCC-SSF system proposed in this paper can separate users via role-based access control inside and outside the vehicle along with the vehicle authentication to control information usage. In addition, the data sent from inside or outside the vehicle is encrypted to defend against tapping, falsification, or other malicious activities. The framework proposed in [17
] comprises context-aware vehicular security mechanisms (CVSMs), and collects data from sensors. The information is protected through encryption, authentication, and access control. The system proposed in [12
] protects location or map information, but the protection of other important information is limited. The framework proposed in [21
] protects vehicle speed, location, and personal information based on GeoLock. The framework proposed in [22
] uses hashed ElGamal encryption to encrypt vehicle location and personal information. The framework in [18
] does not mention any technology to provide confidentiality.
Integrity should be provided for private identification information, payment information, and location information. Just as for important information extortion, integrity invasion also causes financial damage to the user. VCC-SSF disables the identification of the vehicle or the user by hashing the unique information or ID of the object. In addition, integrity is provided for important information such as Personal Information, Payment Information, etc.
, through the hash function. However, in the framework in [12
], the information for which data integrity is provided is limited. Integrity is applied only to geographical or location information, and details for other information such as personal identification or payment is limited. The framework in [21
] uses beacons to provide the integrity. A beacon includes the current time, location, and speed, and it uses HMAC to periodically transmit it. The frameworks in [17
] are undergoing development for integrity protection.
In the VCC environment, it is important to provide services without network disconnection. Because of the characteristics of wireless network environments, attacks that degrade availability such as Denial of Service (DoS), Distributed Denial of Service (DDoS), or black hole attacks may occur. VCC-SSF only provides services between the vehicle and infrastructure and between vehicles to permitted vehicles in order to defend against these attacks. The number of authentication attempts is limited to block access attempts from external malicious users. In cases of the existing frameworks [12
], studies on attacks against availability are undergoing.
Privacy protection is a very important element in the VCC environment. VCC-SSF authorizes using a PVID for the vehicle. It does not use the VN or user unique identification, hence exposure of additional personal information does not occur. In addition, VCC-SSF encrypts important data to prevent leakage. In [12
], privacy protection is considered, but the protected data is limited to location or map information. In [17
] data is encrypted for possible privacy protection, and [18
] is still undergoing development with respect to privacy protection.