# 5G V2X System-Level Architecture of 5 GCAR Project
## 3 Overall 5 GCAR Architecture Design
### End-To-End Security  
Two key requirements for V2X communication and applications are security and privacy, considering also the impact that procedures and mechanisms adopted to handle security and privacy might have on the communications. For instance, concerns might be associated with some security operations that may introduce additional latency or introduce further traffic in the communication. An example of such possible implications is signing all messages with a hardware security module (or USIM--universal subscriber identity module). Signing or verifying a signature, encrypting or decrypting a message also requires CPU-intensive cryptographic operations that might negatively impact latency, even if cryptographic hardware accelerators and hardware security modules (HSMs) are used. Another example is authentication, authorization, and accounting that might require a  
Figure 3: The 5G Communication Automotive Research and innovation (5 GCAR) enhancements for the end-to-end system architecture, highlighting the areas the different enhancements refer to. signature and its associated certificate to be attached to some (or all) messages. This may increase the length of a message of a few hundred bytes with a consequent overhead impact. To mitigate the impacts discussed above, session-based communications introduce benefits, for instance, authentication and authorization are performed once at the beginning of the session. Then session keys are exchanged and/or derived to encrypt remaining exchanges. Nevertheless, this approach works fine for vehicle-to-network (V2N, i.e., UE to V2X server application), or one-to-one V2V/I2V/V2I applications but it is not suitable for one-to-many V2V or I2V/V2I applications (for instance, for exchanging awareness messages). To overcome this limitation, one approach, which is used in Intelligent Transportation System (ITS) for (Common Awareness Messages) CAM, DENM, MAP, SPaT, or IVI messages over ITS-G5, is to sign every single message. In this case, two drawbacks associated with the limitations discussed above should be highlighted: (i) Signing every message with an HSM has a latency penalty, and (ii) every receiving UE needs to go through all consistency and relevance verification checks introducing further processing delay. A second approach is to rely on a central entity in charge of performing authentication and authorization checks, and to provide a session key for the group of communicating UEs, as for instance considered in 3 GPP for ProSe one-to-many security communication [9]. On this topic of one-to-many end-to-end security, 5 GCAR evaluated the feasibility for V2X use cases of the usage of (strong) authentication and authorization performed against a central entity, where the security is handled on a service-basis (i.e., each V2X application wanting to join a certain service will need a group of keys devoted to the specific application considered). The main principles are now discussed. A central entity acting as a key manager and managing the security for a certain application/service is introduced. We refer to this central entity as the \"Key Manager\". The approach is agnostic of who is responsible for this entity (MNOs, public administrations, OEMs, OTT-like entities, etc.). Multiple Key Managers may be deployed, each one operating in a given geographical area. The connection to the central entity is secured by using the UE pseudonym certificates which could be provided in the same way as it is done in the current ITS solution. The requirements are a secure process for the UE certificate enrolment and the trust of the authority chain by the central entity. The central entity may be located in the back office, or as part of road infrastructure, or replaced by one vehicle that plays a specific role in the scope of one specific V2X application (such as the lead vehicle in a platoon). Figure 4a depicts how the Key Manager generates a high number of keys, called Z, which are then used as shared secret keys by all vehicles wishing to participate in a given V2X service.