PC5 unicast link uses 4 different layers of keying material as shown in figure 220.127.116.11.2.1-1.
[not reproduced yet]
Figure 18.104.22.168.2.1-1: Key Hierarchy for PC5 unicast link
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 22.214.171.124.3.2) is exchanged between the UEs to derive the K NRP.
K NRP: 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. In order to generate a K NRP-sess (the next layer of keys), nonces are exchanged between the UEs. K NRP may be kept even when the UEs have no active unicast communication session between them. The K NRP ID is used to identify K NRP.
K NRP-sess: This is the 256-bit key that is the root of the actual security context that is being used (or at least in the process of being established) to protect the transfer of data between the UEs. During activated unicast communication session between the UEs, the K NRP-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 K NRP-sess. The 16-bit K NRP-sess ID identifies the K NRP-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 K NRP-sess and are refreshed automatically every time K NRP-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 K NRP 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 K NRP, K NRP-sess, NRPEK (if applicable) and NRPIK, the chosen confidentiality (if applicable) and integrity algorithms and PDCP counters used with each bearer. 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 K NRP-sess, NRPEK, and NRPIK, the choice of algorithms and the counters. It may also delete K NRP.
UE_2a choose to respond to the message and may initiate the Direct Auth and Key Establishment procedure (if needed based clause 126.96.36.199.3) to generate the key K NRP. 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 188.8.131.52.3 provides the details on the establishment of K NRP. The key establishment procedures in this clause shall be skipped if signalling integrity protection is not activated based on the decision of receiving UE 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.
[not reproduced yet]
Figure 184.108.40.206.3.2-1: Message flow for the establishment of PC5 security key using a generic container
The steps are as follows and apply to establishment of the initial key or rekeying:
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.
UE_2 shall calculate (if not already done) K NRP. 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 K NRP ID. The MSB of K NRP ID are chosen so that they uniquely identify K NRP at UE_2.
On receiving the Direct Security Mode Command, UE_1 shall calculate (if not already done) K NRP based on Key_Est_Info (if provided). UE_1 shall choose the LSB of K NRP ID so that they uniquely identify K NRP at UE_1. UE_1 shall form K NRP ID from the received MSB of K NRP ID and its chosen LSB of K NRP ID and shall store the complete K NRP ID with K NRP.
UE_1 shall send a Direct Security Mode Complete message to UE_2 which shall contain the LSB of K NRP ID. UE_2 shall form K NRP ID from its chosen MSB of K NRP ID and the received LSB of K NRP ID and shall store the complete K NRP ID with K NRP.
Clause 220.127.116.11.4.2 describes the security policy and how the UEs handle the policy. There are two different cases when an overall security context may be established; to set up a new connection and to re-key an ongoing connection. These cases are described in clauses 18.104.22.168.4.3 and 22.214.171.124.4.4 respectively. Clause 126.96.36.199.4.5 describes the establishment of security for a user plane bearer.
The PC5 unicast link shall support activation or deactivation of security based on the security policy similar to Uu, as defined in TS 33.501. The security policy shall be provisioned for PC5 unicast link as well, as detailed in clause 188.8.131.52.4.2.2 of the present document and handled as detailed in clause 184.108.40.206.4.2.3 of the present document.
For selectively activating or deactivation the security of the PC5 unicast link, the PCF may provision the security policy per V2X service, during service authorization and information provisioning procedure as defined in TS 23.287.
User plane integrity protection: REQUIRED/PREFERRED/NOT NEEDED
User plane confidentiality protection: REQUIRED/PREFERRED/NOT NEEDED
REQUIRED means the UE shall only accept the connection if a non-NULL confidentiality or integrity algorithm is used for protection of the traffic.
NOT NEEDED means that the UE shall only establish a connection with no security.
PREFFERED means that the UE may try to establish security but may will accept the connection with no security. One use of PREFERRED is to enable a security policy to be changed without updating all UEs at once.
The handling of signalling security policy proceeds as follows:
At initial connection, the initiating UE includes its signalling security policy in the Direct Communication Request message. The receiving UE(s) takes this into account when deciding whether to accept or reject the request and when deciding the agreed security policy to be sent back in the Direct Security Mode Command message. The initiating UE can reject the Direct Security Mode Command if the algorithm choice does not match its policy (see clause 220.127.116.11.4.3 for full details of the handling).
All the UP data of PC5 unicast link shall have the same security.
The handling of the user plane security policy proceeds as follows:
At initial connection, the UE that sent the Direct Communications Request shall include the user plane security policy for the service in the Direct Security Mode Complete message.
The receiving UE shall reject the Direct Communication Request when the following cases occur: 1) if the received user plane security policy had either confidentiality/integrity set to NOT NEEDED and its own corresponding policy is set to REQUIRED or, 2) if the received user plane security policy had either confidentiality/integrity set to REQUIRED and its own corresponding policy is set to NOT NEEDED.
Otherwise, the receiving UE may accept the Direct Communication Request and the response message shall include the configuration of user plane confidentiality protection based on the agreed user plane security policy, set as follows:
User plane confidentiality protection set to off if the received user plane security policy had either confidentiality set to NOT NEEDED and/or its own user plane security policy for the service is set to NOT NEEDED; or
User plane confidentiality protection set to on if the received user plane security policy had either confidentiality set to REQUIRED and/or its own user plane security policy for the service its own corresponding policy is set to REQUIRED; or
User plane confidentiality protection set to off or on otherwise (i.e. when both the received user plane security policy and its own user plane security policy for the service had the confidentiality set to PREFERRED).
User plane integrity protection set following the same rules as confidentiality protection but based on the received and its own user plane integrity protection policy for the service.
At link modification for adding a new V2X service to an existing PC5 unicast link, if the signalling and user plane security policies of the new V2X service are satisfied by the security in use for the PC5 unicast link, the initiating UE shall send the Link Modification Request to the receiving UE. The receiving UE shall reject the Link Modification Request if the security in use does not match its signalling and user plane security policies for the new V2X service.
The V2X layer of the UE shall pass the security configurations to its AS layer. The security configurations are mutually agreed by both sides' UEs, including the configuration of confidentiality and integrity protection.
UE_1 has sent a Direct Communication Request to UE_2. This message shall include UE_1's security capabilities (the list of algorithms that UE_1 will accept for this connection) and UE_1's signalling security policy. The UE_1 shall also include Nonce_1 (for session key K NRP-sess generation), and the most significant 8-bits of the K NRP-sess ID in this message if UE_1's signalling integrity protection policy is either "REQUIRED" or "PREFERRED". The most significant 8-bits of the K NRP-sess ID shall be chosen such that UE_1 will be able to locally identify a security context that is created by this procedure. The message may also include a K NRP ID if the UE_1 has an existing K NRP for the UE that it is trying to communicate with. The absence of the K NRP ID parameter indicates that UE_1 does not have a K NRP for UE_2. The message also contains Key_Est_Info (see clause 18.104.22.168.3.2).
UE_2 shall reject the Direct Communication Request if UE_1's signalling security policy is "NOT NEEDED" while UE_2's security policy is "REQUIRED". UE_2 shall also reject the Direct Communication Request if UE_1's signalling security policy is "REQUIRED" while UE_2's security policy is "NOT NEEDED". UE_2 may initiate a Direct Auth and Key Establish procedure with UE_1. This is mandatory if the UE_2 does not have the K NRP and K NRP ID pair indicated in step 1, and signalling is needed to establish the keys for the particular use case.
UE_2 shall send the Direct Security Mode Command message to UE_1. This message shall only contain the MSB and of K NRP ID and optionally Key_Est_Info if a fresh K NRP is to be generated (see clause 22.214.171.124.3). UE_2 shall include the Chosen_algs parameter to indicate which security algorithms the UEs will use to protect the data in the message. The Chosen-algs may only indicate the use of the NULL integrity algorithm if UE_2's signalling integrity security policy is either NOT NEEDED or PREFERRED. UE_2 shall also return the UE_1's security capabilities and UE_1's signalling security policy to provide protection against bidding down attacks. In the case that the NULL integrity algorithm is chosen, the NULL confidentiality algorithm shall also be chosen and UE_2 shall set the KNPR-sess ID of this security context to the all zero value.
The following procedures in step 3 shall only be executed if the UE_2 decides to at least activate the integrity security protection for this connection: UE_2 shall also include Nonce_2 to allow a session key to be calculated, as well as the least significant 8-bits of K NRP-sess ID in the messages. These bits are chosen so that UE_2 will be able to locally identify a security context that is created by this procedure. UE_2 shall calculate K NRP-sess from K NRP and both Nonce_1 and Nonce_2 (see clause A.3) and then derive the confidentiality (if applicable) and integrity keys based on the chosen algorithms (clause A.2). UE_2 shall integrity protect the Direct Security Mode Command before sending it to UE_1. UE_2 is then ready to receive both signalling and user plane traffic protected with the new security context. UE_2 shall form the K NRP-sess ID from the most significant bits it received in step1 and least significant bits it sent in step3.
On receiving the Direct Security Mode Command, the UE_1 shall first check the Chosen_algs and shall accept the NULL integrity algorithm only if its security policy for signalling integrity protection is either NOT NEEDED or PREFERRED. Then UE_1 shall check the returned UE_1's security capabilities and UE_1's signalling security to avoid bidding down attacks if NULL integrity algorithm is selected for signalling integrity protection. If the above check passes, UE_1 shall send unprotected Direct Security Mode Complete message to UE_2. UE_1 shall set the KNPR-sess ID of this security context to the all zero value.
Under the condition of non-NULL integrity algorithm indicated in the Chosen_algs, UE_1 shall first check that the received LSB of KNPR-sess ID is unique, i.e. has not been sent by another UE responding to this Direct Communication Request. If the LSB of KNPR-sess ID is not unique, then UE_1 shall respond with a Direct Security Mode Reject message including a cause value to specify that the LSB of KNPR-sess ID is not unique. The peer UE-2 receiving a Direct Security Mode Reject message shall inspect the cause value and, if the cause is related to the session identifier uniqueness then, the UE-2 shall generate a new LSB of KNPR-sess ID and reply to UE-1 again (i.e., UE-2 shall send a Direct Security Mode Command message with the new LSB of KNPR-sess ID). UE_2 shall associate the new LSB of K NRP-sess ID with the security context that is created in step 3. UE-2 shall erase the former LSB of KNPR-sess ID from its memory. On receiving this new Direct Security Mode Command, UE_1 shall process the message from the start of step 4.
If the LSB of KNPR-sess ID is unique, UE_1 shall calculate K NRP-sess and the confidentiality and integrity keys in the same way as UE_2. UE_1 shall check that the returned UE_1 security capabilities and UE_1's signalling security policy are the same as those it sent in step 1. UE_1 shall also check the integrity protection on the message. If both these checks pass, then UE_1 is ready to send and receive signalling and user plane traffic with the new security context. UE_1 shall send integrity protected and confidentiality protected Direct Security Mode Complete message to UE_2. UE_1 shall form the K NRP-sess ID from the most significant bits it sent in step1 and least significant bits it received in step3.
If the Chosen_algs in step 3 includes non-NULL integrity algorithm, UE_2 checks the integrity protection on the received Direct Security Mode Complete. If this passes, UE_2 is now ready to send user plane data and control signalling protected with the new security context. UE_2 deletes any old security context it has for UE_1.
By rekeying, the UEs ensure fresh session keys K NRP-sess are used. Optionally the rekeying can also enforce refresh of K NRP. Either UE may rekey the connection at any time. This shall be done before the counter for a PDCP bearer repeats with the current keys. A rekeying operation shall refresh the K NRP-sess and NRPEK and NRPIK, and may refresh K NRP. There is no benefit in running the rekeying procedure if the NULL integrity algorithm is in use, hence it is recommended not to trigger it when using the NULL integrity algorithm. A rekeying operation follows the flows given in figure 126.96.36.199.4.4-1.
[not reproduced yet]
Figure 188.8.131.52.4.4-1: Security establishment during rekeying
UE_1 sends a Direct Rekey Request to UE_2. This message shall include UE_1 security capabilities (the list of algorithms that UE_1 will accept for this connection). In addition, if a non-Null integrity algorithm is in use, the message shall include Nonce_1 (for session key generation) and the most significant 8-bits of the K NRP-sess ID. These bits are chosen such that UE_1 will be able to locally identify a security context that is created by this procedure. The message may also include a Re-auth Flag if UE_1 wants to rekey K NRP. The message also contains Key_Est_Info (see clause 184.108.40.206.3.2).
This step is the same as step 3 in clause 220.127.116.11.4.3 except that the chosen integrity algorithm shall only be NULL if and only if the NULL integrity algorithm is currently in use, the chosen confidentiality algorithm shall only be NULL if and only if the NULL confidentiality algorithm is currently in use and UE_1's signalling security policy is not included in this message.
This step is the same as step 4 in clause 18.104.22.168.4.3 except that UE_1 shall only accept the NULL integrity algorithm if and only if the NULL integrity algorithm is currently in use, UE_1 shall only accept the NULL confidentiality algorithm if and only if the NULL confidentiality algorithm is currently in use, and UE_1 does not check the returned signalling security policy (as it is not sent in this case).
The UEs handle the user plane security policies as described in clauses 22.214.171.124.4.2.3.
The UE initiating the establishment of a user plane bearer shall select an LCID whose associated value of Bearer for input to the security algorithms (see clauses 126.96.36.199.5.2 and 188.8.131.52.5.3) has not been used with the current keys, NRPEK and NRPIK. If this is not possible the UE shall initiate a re-keying (see clause 184.108.40.206.4.4) before establishing the user plane bearer.
When establishing or re-configuring the user plane bearer, the initiating UEs shall ensure the configuration of confidentiality and integrity protection in the PC5-RRC message matches the agreed UP security policies for traffic that will be sent on the bearer. The confidentiality and/or integrity protection algorithms are same as those selected for protecting the signalling bearers if confidentiality and/or integrity protection are required for both signalling and user plane.
Both UEs shall ensure that the user plane for each V2X service is only sent or received (e.g. dropped if received on a bearer with incorrect security) on user plane bearers with the necessary security if security protection of this link is activated.
Protection for the signalling and user plane data between the UEs is provided at the PDCP layer. As the security is not preserved through a drop of the connection, all signalling messages that need to be sent before security is established for a connection may be sent with no protection. The PC5-S signalling messages that can be sent and processed unprotected are given in TS 24.587. Once security is established for a connection all signalling messages for that connection are sent integrity protected and confidentiality protected with the chosen algorithms except the Direct Security Mode Command which is sent integrity protected only.
UEs shall implement NIA0, 128-NIA1 and 128-NIA2 and may implement 128-NIA3 for integrity protection of the unicast link. The algorithm identifiers from clause 220.127.116.11 of TS 33.501 are reused for PC5-S, PC5-RRC, and PC5-U.
These integrity algorithms are as specified in TS 33.501 and are reused with the following modifications:
The key used is NRPIK;
Direction is set to 1 for direct link signalling transmitted by the UE that sent the Direct Security Mode Command for this security context and 0 otherwise;
Bearer to Bearer are set to 5 LSB of LCID;
COUNT to COUNT are filled with counter value (see clause 6.3.5 of TS 38.323).
The receiving UE ensures that received protected signalling messages and user plane data that is integrity protected are not replayed.
UEs shall implement NEA0, 128-NEA1 and 128-NEA2 and may implement 128-NEA3 for ciphering of the unicast link. The algorithm identifiers from clause 18.104.22.168 of TS 33.501 are reused for PC5-S, PC5-RRC, and PC5-U.
These ciphering algorithms are as specified in TS 33.501 and are used with the following modifications:
The key used in NRPEK;
Direction is set as for integrity protection (see 22.214.171.124.5.2);
Bearer to Bearer are set to 5 LSB of LCID;
COUNT to COUNT are filled with counter value.
The Key ID and least significant bits of the counter are carried in the PDCP header, along with any MAC that is needed for integrity protection. The key ID is used to signal which security context is being used and shall be set to K NRP-sess ID.
This is illustrated in Figure 126.96.36.199.5.4-1.
[not reproduced yet]
Figure 188.8.131.52.5.4-1: Security parameters in the PDCP header for NR based PC5 unicast mode