This clause contains the security and privacy requirements and specifies procedures that can achieve the requirements for V2X over NR based PC5 reference point except those for PC5 over E-UTRA which are given in TS 33.185.
This clause describes the security requirements and the procedures that are commonly applied for the all kinds of communication modes, i.e. unicast mode, groupcast mode and broadcast mode, which the NR based PC5 reference point supports.
The initiating UE shall establish a different security context for each receiving UE during the PC5 unicast link establishment if the security is activated.
PC5 unicast link security establishment between the initiating UE and each receiving UE shall be protected from man-in-the-middle attacks.
The system shall support confidentiality protection, integrity protection and replay protection of the user plane data of PC5 unicast.
The system shall support confidentiality protection, integrity protection and replay protection of signalling for PC5 unicast link.
The system shall support means of configuring the signalling and user plane security policies to UEs for a particular PC5 unicast link.
Signalling plane protection of the PC5 unicast link for a V2X service shall align with the PC5 signalling security policies of the communicating UEs.
User plane protection of the PC5 unicast link for a V2X service shall align with the PC5 user plane security policies of the communicating UEs.
The 5G System should provide means for mitigating trackability attacks on a UE during PC5 unicast communications.
The 5G System should provide means for mitigating link ability attacks on a UE during PC5 unicast communications.
The UE establishes a security context for each unicast link. The security context includes KNRP-sess, NRPEK (if applicable), NRPIK, the chosen confidentiality (if applicable) and integrity algorithms, and PDCP counters used with each bearer. The UE updates the security context associated to the unicast link when the unicast link is rekeyed. The UE deletes the security context associated to a unicast link once the unicast link is released.
Long term credentials: These are the credentials that are provisioned into the UE(s) and form the root of the security of the PC5 unicast link. The credentials may include symmetric key(s) or public/private key pair depending on the particular use case. Authentication signalling (see clause 188.8.131.52.3.2) is exchanged between the UEs to derive the KNRP.
KNRP: This is a 256-bit root key that is shared between the two entities that communicating using NR PC5 unicast link. It may be refreshed by re-running the authentication signalling using the long-term credentials. Nonces are exchanged between the UEs and used with the KNRP to generate a KNRP-sess (the next layer of keys). KNRP may be kept even when the UEs have no active unicast communication session between them. The 32-bit KNRP ID is used to identify KNRP.
KNRP-sess: This is the 256-bit key that is derived by UE from KNRP and is used derive keys that to protect the transfer of data between the UEs. The KNRP-sess is derived per unicast link. During activated unicast communication session between the UEs, the KNRP-sess may be refreshed by running the rekeying procedure. The actual keys (see next bullet) that are used in the confidentiality and integrity algorithms are derived directly from KNRP-sess. The 16-bit KNRP-sess ID identifies the KNRP-sess.
NRPEK and NRPIK: The NR PC5 Encryption Key (NRPEK) and NR PC5 Integrity Key (NRPIK) are used in the chosen confidentiality and integrity algorithms respectively for protecting PC5-S signalling, PC5 RRC signalling, and PC5 user plane data. They are derived from KNRP-sess and are refreshed automatically every time KNRP-sess is changed.
A UE may be in one of the three different security states with respect to another UE as follows:
Provisioned-security: This is where a UE just has its own long term keys.
Partial-security: This is where a UE has recently communicated with another UE and still has the KNRP that it used with the other UE, but no other derived keys.
Full-security: This is where a UE is actually communicating with another UE and has KNRP, and a security context per unicast link (see clause 184.108.40.206.2.0). Within a security context, the NRPEK and the chosen confidentiality algorithm may not exist if both signalling and user plane confidentiality are inactivated.
Once a UE ends its unicast communication session with another UE in Full-security state, it shall delete KNRP-sess, NRPEK, and NRPIK, the choice of algorithms and the counters, and may also delete KNRP.
UE_2a chooses to respond to the message and may initiate the Direct Auth and Key Establishment procedure (if needed based clause 220.127.116.11.3) to generate the key KNRP. UE_2a then runs the Direct Security Mode Command procedure with UE_1 to continue the connection establishment procedures. If this is successful, UE_2a sends the Direct Communication Accept message.
UE_2c responds to UE_1 using the same sequence of messages as UE_2a.
When each responder decides to activate signalling integrity protection and/or signalling confidentiality protection, each responder establishes a different security context with UE_1 that is not known to the other UEs, i.e. the security context used between UE_1 and UE_2a is not known to UE_2b and UE_2c.
The Direct Communication Request is always sent unprotected and only contains enough information for a secure connection to be established with the other UE. Any information UE_1 needs to send to the other UEs in order to establish the connection is included in the Direct Security Mode Complete message (sent as part of the Direct Security Mode procedure, see TS 23.287) from UE_1 as this message is both confidentiality and integrity protected under the condition of activated non-NULL signalling confidentiality protection of the link.
Clause 18.104.22.168.3 provides the details on the establishment of KNRP. The key establishment procedures in clause 22.214.171.124.3.1 and 126.96.36.199.3.2 shall be skipped if the receiving UE decides to not activate the signalling integrity protection of this PC5 unicast link. The long-term credentials and associated authentication method that are used to establish the keys used to protect the PC5 unicast link may either be specified in 3GPP specification or be a method described outside of 3GPP specifications. In the latter case, it is not practical for all cases to specify the signalling in individual IEs on the NR PC5 interface for all these applications, hence all the authentication is specified to be carried in a generic container (called Key_Est_Info in the following clause) on the NR PC5 interface. This allows, for example, an application to change the authentication method without affecting the NR PC5 interface.
At each step of the flow (and the possible multiple times that step 2 can be run), the Key_Est_Info contains the different data that is required for key establishment. Such data is transparent to the PC5 layer, i.e. the PC5 layer does not need to understand the content of Key_Est_info.
In the case, UE_1 determines it needs to establish a PC5 connection with another UE, UE_1 sends the Direct Communication Request message and this message is received by UE_2. In case of rekeying an existing connection with UE_2, UE_1 shall send a Direct Rekeying Request message to UE_2 instead of Direct Communication Request. The Direct Communication Request message shall include the Key_Est_Info unless UE_1's signalling integrity security policy is NOT NEEDED. In the former case, the message may include Key_Est_Info. The Direct Rekeying Request message shall include Key_Est_Info unless the Null integrity algorithm is currently in use.
In case the UE_2 decides to activate the signalling integrity protection, UE_2 shall calculate (if not already done) KNRP. UE_2 shall send a Direct Security Mode Command messages to UE_1. These messages may include Key_Est_Info if need by the authentication method being used and shall contain MSB of KNRP ID unless the Null integrity algorithm is selected by UE_2. The MSB of KNRP ID are chosen so that they uniquely identify KNRP at UE_2.
On receiving the Direct Security Mode Command, UE_1 shall calculate (if not already done) KNRP based on Key_Est_Info (if provided). UE_1 shall execute the following procedures unless the Null integrity algorithm is selected by UE_2: UE_1 shall choose the LSB of KNRP ID so that they uniquely identify KNRP at UE_1. UE_1 shall form KNRP ID from the received MSB of KNRP ID and its chosen LSB of KNRP ID and shall store the complete KNRP ID with KNRP.
UE_1 shall send a Direct Security Mode Complete message to UE_2 which shall contain the LSB of KNRP ID. UE_2 shall form KNRP ID from its chosen MSB of KNRP ID and the received LSB of KNRP ID and shall store the complete KNRP ID with KNRP.