Content for TS 33.536 Word version: 18.0.0

5.1 General 5.2 Common security 5.2.1 General 5.2.2 Requirements 5.2.3 Procedures 5.3 Security for unicast mode 5.3.1 General 5.3.2 Requirements 5.3.3 Procedures 5.3.3.1 Securing the PC5 unicast link 5.3.3.1.1 General 5.3.3.1.2 Overview 5.3.3.1.3 Key establishment procedures
...

5 Security for V2X over NR based PC5 reference point p. 7

5.1 General p. 7

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.

5.2 Common security p. 7

5.2.1 General p. 7

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.

5.2.2 Requirements p. 7

5.2.2.1 Requirements for Cross-RAT control authorization indication p. 7

The 5G System shall provide means to manage the cross-RAT PC5 control authorization.

5.2.3 Procedures p. 7

5.2.3.1 Cross-RAT PC5 control authorization indication p. 7

The procedures for the cross-RAT PC5 control authorization indication are specified in clause 6.5 of TS 23.287.

5.3 Security for unicast mode p. 8

5.3.1 General p. 8

This clause describes the security requirements and the procedures that can be specifically applied for the NR based PC5 unicast mode.

5.3.2 Requirements p. 8

5.3.2.1 Requirements for securing the PC5 unicast link p. 8

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.

5.3.2.2 Identity privacy requirements for the PC5 unicast link p. 8

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.

5.3.3 Procedures p. 8

5.3.3.1 Securing the PC5 unicast link p. 8

5.3.3.1.1 General p. 8

The NR based PC5 unicast communication procedures are described in TS 23.287.

Clause 5.3.3.1 details how the security for this communication is established and used.

5.3.3.1.2 Overview p. 8

5.3.3.1.2.0 Security Context p. 8

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.

5.3.3.1.2.1 Key hierarchy p. 8

PC5 unicast link uses 4 different layers of keying material as shown in Figure 5.3.3.1.2.1-1.

Copy of original 3GPP image for 3GPP TS 33.536, Fig. 5.3.3.1.2.1-1: Key Hierarchy for PC5 unicast link

Figure 5.3.3.1.2.1-1: Key Hierarchy for PC5 unicast link
(⇒ copy of original 3GPP image)

The different layers of keys are the following:

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 5.3.3.1.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.

NOTE 1:
A KNRP-sess ID with a zero value indicates that no security is used and hence the UEs do not assign an all zero value of KNRP-sess ID when creating a security context.
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.

NOTE 2:
Whether the above keys (i.e. KNRP, KNRP-sess, NRPEK and NRPIK) are derived is based on the result of the security activation for the signalling security.

NOTE 3:
KNRP is used to derive the keys for a security context for a unicast link established between a pair of UEs and could be used to derive keys for additional links established between a certain pair of UEs. The KNRP and its accompanying KNRP ID values are not part of the security context for a unicast link and do not have to be deleted after unicast link release.

5.3.3.1.2.2 Security states p. 9

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 5.3.3.1.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.

5.3.3.1.2.3 High level flows for the security establishment p. 10

Figure 5.3.3.1.2.3-1 provides a high-level flow of a UE establishing a connection with other UE(s).

Copy of original 3GPP image for 3GPP TS 33.536, Fig. 5.3.3.1.2.3-1: High-level flow of connection establishment

Figure 5.3.3.1.2.3-1: High-level flow of connection establishment
(⇒ copy of original 3GPP image)

The flow proceeds as follow:

Step 1.

UE_1 sends a Direct Communication Request. This message may be received by multiple UEs.

Step 2a/3a/4a.

UE_2a chooses to respond to the message and may initiate the Direct Auth and Key Establishment procedure (if needed based clause 5.3.3.1.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.

Step 2b.

UE_2b chooses not to respond the UE_1

Step 2c/3c/4c.

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.

5.3.3.1.3 Key establishment procedures p. 11

5.3.3.1.3.1 General p. 11

Clause 5.3.3.1.3 provides the details on the establishment of KNRP. The key establishment procedures in clause 5.3.3.1.3.1 and 5.3.3.1.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.

5.3.3.1.3.2 Key establishment p. 11

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.

Copy of original 3GPP image for 3GPP TS 33.536, Fig. 5.3.3.1.3.2-1: Message flow for the establishment of PC5 security key using a generic container

Figure 5.3.3.1.3.2-1: Message flow for the establishment of PC5 security key using a generic container
(⇒ copy of original 3GPP image)

The steps are as follows and apply to establishment of the initial key or rekeying:

Step 1.

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.

Step 2.

This step is optional and may be run multiple times depending on the authentication method used.

UE_2 shall send a Direct Auth and Key Establish message including the Key_Est_Info to UE_1.
UE_1 shall send respond with a Direct Auth and Key Establish Response message including the Key_Est_Info to UE_2.

Step 3.

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.

Step 4.

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.