The present document specifies the security aspects of V2X features in LTE, including security architecture, security requirements on the network entities that are used to support V2X services, as well as the procedures and solutions which are provided to meet those requirements.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
V2X service contains three types of vehicular communication services V2V (vehicle to vehicle), V2I (vehicle to infrastructure), V2N (vehicle to network), and V2P (vehicle to pedestrian) for both safety and non-safety aspects.
The overall architecture describing LTE enhancements for V2X services is given in TS 23.285. Both LTE-Uu based architecture (e.g. eMBMS) and PC5 based architecture are used for supporting V2X services, but they may be used by a UE independently for transmission and reception, e.g. a UE can use eMBMS for reception without using LTE-Uu for transmission.
The security for interfaces given in the overall architecture (TS 23.285) is provided in clause 6, in detail these are the interfaces between network entities (clause 6.2), between UE and V2X Control Function (clause 6.3), and between V2X AS and 3GPP system (clause 6.4). Clause 6.5 discusses security of V2X application data. Clause 6.6 is providing details to privacy in V2X services.
The V2X network entities shall be able to authenticate the source of the received data communications.
The transmission of data between V2X network entities shall be integrity protected.
The transmission of data between V2X network entities shall be confidentiality protected.
The transmission of data between V2X network entities shall be protected from replays.
The V2X enabled UE and its HPLMN V2X Control Function shall mutually authenticate each other.
The transmission of configuration data between the V2X Control Function and the UE shall be integrity protected.
The transmission of configuration data between the V2X Control Function and the UE shall be confidentiality protected.
The transmission of configuration data between the V2X Control Function and the UE shall be protected from replays.
The transmission of UE identity should be confidentiality protected on the V3 interface.
The V2X system entities should be able to authenticate and verify that the sender of the received data communications was authorized to send the data.
The transmission of data between different V2X entities in the V2X system should be integrity protected.
The transmission of data between different V2X entities in the V2X system should be protected from replays.
The transmission of data between two different V2X entities in the V2X system should be confidentiality protected if needed for the V2X application.
As specified in TS 22.185 the following PC5 privacy related requirements apply:
Subject to regional regulatory requirements and/or operator policy for a V2X application, the data sent in the PC5 transmission should not allow UE identity to be tracked or identified by any other UE or non-V2X entity beyond a certain short time-period required by the V2X application.
Subject to regional regulatory requirements and/or operator policy for a V2V/V2I application, the data sent in the PC5 transmission should not allow a single party (operator or third party) to track a UE identity in that region.
In addition, the following PC5 related requirements are given in the present specification:
The identifiers in the V2X messages should minimize the risk of leaking the UE or user permanent identities.
UE pseudonymity should be provided to conceal personal data from attackers.
The application layer UE identity in the V2X messages should be protected from eavesdropping.
For V2X services relying on access networks within the scope of TS 33.401, the 3GPP authentication, key agreement, associated subscriber credentials and associated subscriber identities used to access the network should reside on USIM within the V2X enabled UE.
For V2X services relying on access networks within the scope of TS 33.402, the 3GPP authentication, key agreement, associated subscriber credentials and associated subscriber identities used to access the network should reside on UICC within the V2X enabled UE, except for terminals that do not support 3GPP access capabilities and where 3GPP does not specify where the credentials used with EAP-AKA and EAP-AKA' reside.
This clause contains a description of the various security features that are available for V2X services. All V2X services do not have the same security requirements and hence may not require the use of all the described features. It is up to the deployment of the feature to ensure that all the appropriate security aspects are addressed.
The UE has interactions with the V2X Control Function over the V3 in the V2X services as described in TS 23.285. The V3 interface can be secured in the same way as the PC3 interface, as in TS 33.303, clause 5.3.
After deployment of the UE the configuration parameters stored in the UICC may need to be updated to reflect the changes in the configuration applied.
In case that configuration data of V2X-enabled UE are stored in the UICC, the UICC OTA mechanism (as specified in ETSI TS 102 225  / TS 102 226  and TS 31.115 / TS 31.116) shall be used to secure the transfer of the configuration data to be updated in the UICC.
This subclause describes procedures for protecting data transfer between UE and V2X Control Function.
Between the UE and network function, for UE initiated messages:
PSK TLS with GBA including the option of the co-located BSF and NAF is used as specified in TS 33.303, subclause 184.108.40.206) for UE initiated messages between the UE and ProSe Function with the V2X Control Function playing the role of the ProSe Function.
and for network initiated messages one of the following mechanisms shall be used:
If a PSK TLS connection has been established as a part of a pull message and is still available, the available PSK TLS session shall be used.
Otherwise, PSK TLS with GBA push based shared key-based mutual authentication between the UE and the network function shall be used. GBA push is specified in TS 33.223. The network function (pushNAF) shall request USSs from the BSF when requesting a GPI, and the network function shall check in the USS if the USIM is authorized to be used for V2X services. If the authorization in the network function fails, then the network function shall refrain from establishing PSK TLS with GBA push.
V2X application data is sent by vehicle UEs in periodic or event-driven broadcast messages, and can occur either on the PC5 interface or on the LTE-Uu interface.
V2X applications aim to improve road safety and travel mobility, by issuing timely warnings to the driver, or providing information about road hazards and congestion, emergency vehicles, etc. It is therefore of utmost importance that the safety messages broadcast by UEs are trusted as having been issued from a legitimate/well-functioning device.
For the PC5 mode, the recipients of these messages (i.e. vehicle UEs that are within communication range of the sending UE) are not known in advance to a transmitting vehicle UE, and hence a priori (e.g., network assisted) security association establishment between UEs is not feasible to be supported. This is the nature of this point to multipoint communication within a dynamically changing set of UEs. Therefore, neither current LTE security nor ProSe one-to-many communication security is applicable.
Though the security requirements applicable to V2X communications are all satisfied by employing application-layer security as defined in other SDOs, (e.g. IEEE  or ETSI ITS ), such use of the application-layer security to secure V2X communications is outside the scope of 3GPP.
For PC5 communication, the data frames inherit the format of the PC5 one-to-many communication, although no security is applied at this layer. They contain fields relating to group keys. These fields are all set to zero for PC5 based V2X communications.
For LTE-Uu communications, the LTE security mechanism for air interface confidentiality shall be used (see TS 33.401).
If a UE is using the same identity in several broadcast messages, it is possible to track the vehicle and compromise its privacy. Whether such privacy concerns exist for a V2X service will likely depend on regional regulatory requirements and/or operator policy, hence the PC5 privacy feature is optional to use. For example, a service that is mandated for use by a regulator may not provide an "opt out" option.
No additional privacy features beyond the regular LTE privacy features (see TS 33.401) are supported for Uu mode V2X communications.
Privacy may be supported at the application layer by employing identifiers and credentials that are not linked to long-term UE or user identifiers. These credentials would be refreshed periodically. The change of application layer identities and credentials for using the V2X service is out of scope in 3GPP.
The UE shall change and randomize the source Layer-2 ID, and the source IP address (in case of IP-based V2X communication) when indicated by the V2X application that the application layer identifier has changed. The UE shall also provide indication to the V2X application layer when the source Layer-2 ID, or/and the source IP address (in case of IP-based V2X communication) are changed.