Huawei

lilun20@huawei.com

Huawei

liufei19@huawei.com

Security Post-Quantum Use In Protocols post-quantum cryptography PQC telecom use cases Telecommunications (Telecom) networks are important infrastructure. 3rd Generation Partnership Project (3GPP) provides security specifications for telecom networks, including network devices and user terminals. Meanwhile, the security protocols from IETF widely used in telecom systems. This docuemnt presents some post-quantum risks and assessments that exist in current telecom network, analyzes possible post-quantum migration cases and potential strategy in typical telecom network, the strategy includes the suggestion of related IETF protocols and profiles.

Cryptographic technologies are used throughout ICT(Information and communications technology) industry to authenticate the source and protect the confidentiality and integrity of information that we communicate and store. However, quantum computing technology poses significant threats to classical cryptography, especially to widely-used cryptographic algorithms. Today's 5G network widely uses both symmetric and asymmetric cryptography above across different layers of the network to ensure the security, privacy, and integrity of communications. The permanent identity of device (named Subscription Permanent Identifier, SUPI) is protected by asymmetric key encryption algorithms when the UE initially accesses the 5G systems. Then, symmetric key encryption (e.g., AES) is used to protect the signaling control and data when the UE (e.g., the cellphone) communicates with the network. In addition, a network entity (for example, a base station) uses IPsec tunnels to protect the user data and control plane. network functions in the core network use TLS connection for security transmission. The PRINS can be used to protect communications between different operator domains through SEPP. These are all related to both symmetric and asymmetric key cryptography In fact, servral procedures should considered be migrated to quantum-safe, becase quantum computers endanger both symmetric and asymmetric cryptography: For asymmetric encryption schemes, for example, ECIES (based on Elliptic Curve Cryptography), and IKEv2 (Dbased on iffie-Hellman key exchanges), Shor's algorithm , running on a sufficiently powerful quantum computer, can break these systems by making these hard mathematical problems easy to solve (e.g., ECC used in ECIES and Diffie-Hellman used in IKEv2 relying the difficulty of solving discrete logarithm problems). As a result, public-key cryptosystems that secure digital signatures, encrypted communications, and key exchanges would become vulnerable to quantum attacks. For symmetric encryption schemes, for example, AES (Advanced Encryption Standard) / SNOW-5G / ZUC and SHA-256 (hash functions), their vulnerability to quantum computing algorithm (e.g., Grover's algorithm) is still in active discussions in post-quantum cryptography research community. The major concern is that quantum computer can speed up the process of brute-forcing symmetric keys. Applying post quantum cryptography algorithms to telecom networks is called PQC migration, this document proposes the telecom use case for PQC migration, contains potential PQC risk, assessment and migration strategy. Some of the cases are referred from the guideline of GSMA . Further, this document points out the connections between the IETF protocols and the telecom system for the information of each WG in contributing the PQC protocol current design as well as in future.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This section is the core of this document. each introduced telecom scenarios may contain more than one risks and threats and it will link to the reference use cases in the next section.

Given the standardized process of certificate enrolment for base stations defined in 3GPP TS 33.310, we consider the procedure where a base station (e.g., 5G base station = gNB, or 4G base station = eNodeB) bootstraps and tries to apply a certificate from the operator's CA with a preconfigured certificate from the vendor CA.

| | |1a.Request for a | | | operator certificate | | | Atteching vendor certificate. | +------------------------------+| | | |1b.Verify atteched vendor cert|+ | | +------------------------------+| |<---------------------------------| | | 1c.Issue a operator | | | certificate to BS. | | |--------------------------------------------------------------------| | 2a.Communicate with Core netowrk and security | | GW with Operator certificate. | | | | +-----------------------------+ | | | |2b.authenticate the base | | | | |station using operator +-+ | | |cert and response the | | | | |request. | | | | +-----------------------------+ | | | | Figure 1 Scenario of the certificate enrolment of the base station]]>

As shown in Figure 1, the following steps are performed by gNB/eNodeB to initially establish a secure connection and depend on the certificate, which can be an example to show the quantum risk in the current telecom system: 0. The base station pre-installs vendor certificate from vendor CA (out of band). Then, the base station pre-establishes the IPsec tunnel connection with operator's CA. 1. The base station request to apply the operator's certificate through the IPsec Tunnel. 2. The base station communicate to core network through IPsec tunnel used the operator certificate. There are two risks related to the quantum computation attack that need to be considered in the above steps. Risk A: attacking the IPsec tunnel 1. The base station establishes the secure connection with operator's CA through IPsec Tunnel. During the establishment, the base station exchanges the session key with operator's CA using IKEv2/IPsec. 2. Attackers in Risk A eavesdropping and storing the traffic of IPsec tunnel can analyze and corrupted the key exchange packet in IKEv2 with quantum computing capabilities. 3. If the traffic is protected by quantum-resistant algorithm, the attacker will fail to derive the IPsec session key used for base station and operator CA. Risk B: attacking the certificates 1.The attacker in risk B establishes a connection with the operator CA and obtains the X.509 profile of a stolen vendor certificate from other entities. 2.The attacker attempts to forge a valid X.509 profile (including the certificate signature) of a vendor certificate. 3.If a quantum-resistant signature approaches is used in certificate; the attacker will fail to forge a valid vendor certificate with a valid signature. Risk A is non-quantum security protocols such as the CMPv2 and IPsec (e.g., secure key exchange procedure). Risk B is the non-quantum security X.509 certificate (e.g., ECC signatures in the certificate). Two possible quantum risks threaten the security of base station and requires PQC migration to defense the potential attacker.

This section is the core of this document. For each use case, we present a concise overview and highlight the features that can help to categorize it. This list is not exhaustive, and if you think we have missed some important use case please consider contributing to it.

In today's the 5G Telecom network, a variety of cryptographic algorithms and IETF protocols are used ,both symmetric and asymmetric cryptography, a summury is provided in Table 1. Summary of symmetric and asymmetric cryptography in 5G Telecom network

Migration Protocols	Usage in 5G	Symmetric Cryptography	Asymmetric Cryptography	Reference in Existing 3GPP specifications	Relative IETF WG
Key Derivation	Key agreement between UE and individual NF (e.g., K_AMF)	KDF based on symmetric cryptography	N/A	Annex A.1 in 3GPP TS 33.501, TS 33.220	N/A
Secure Key Exchange	Two entities (e.g., NF/RAN/Security gateway, etc.) to securely exchange keys over an insecure channel for deriving symmetric session keys	Integrity and confidential protection in IPsec	Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman (ECDH)	Clause 9 in 3GPP TS 33.501	IPSECME
Authentication	UE registration and authentication	5G-AKA and EAP-AKA'	EAP-TLS	Annex I.2 in 3GPP TS 33.501	EMU
Authentication for Network function	Two NFs mutual authentication	N/A	Digital Certificate and PKI	Clause 13 in 3GPP TS 33.501	Lamps
Identity Protection	Concealing SUPI by generating SUCI	N/A	Public key encryption (ECIES)	Clause 6.12 in TS 33.501, 3GPP TS 23.003	N/A
Data Confidentiality and integrity	Encryption to protect user plane data and/or control plane signaling	AES / SNOW-5G / ZUC	N/A	Clause 5.11 in 3GPP TS 33.501, TS 35.215, TS 35.221	CFRG
Public key Infrastructure	Signature of the certificate for security establishment, such as transport layer security	N/A	Signature algorithm, for example, ECC, etc.	3GPP TS 33.310	ACME /Lamps

As shown in the table, some common issues have been discussing in the relevant IETF WGs, but there are some unique characteristics, in terms of the deployment of telecom networks. Specific use cases are discussed in the following sections, which are proposed based on the scenario in section 3 to address the identified risks.

In the current telecom network, the base station and the core network need to transmit control signaling and the user's data. Control signaling is for example non-access stratum information of the UE, including important messages such as user authentication and authorization information. The user's data is for example, the communication data between the UE and the website of data network (aka., user plane data). The foregoing content is transmitted through interface N2 and N3 respectively. Generally, it can be concluded that N2 is used for control plane signaling, and N3 is used for user plane data. As described in the threat analysis in Section 2, both the secure connection of the N2 and the N3 use the IPsec protocol. Specifically, the core network uses a security gateway (SEG) as the endpoint of the IPSec tunnel, and the other end point is base station. As specified if 3GPP TS 33.501, When an IPsec tunnel is established, IKEv2 is executed and authenticated by the certificate with specified profile. For post-quantum migration of N2/N3, Although IPsec itself uses symmetric encryption for transmission, the current 3GPP recommended IKEv2 protocol version and certificate format do not include post-quantum considerations. In this use case of N2/N3, the post-quantum migration of IKEv2 should be considered.

From the perspective of IETF PQUIP and this use case, the following analysis can be considered. About key exchange: A pre-shared key may be considered as a way, for example, as specified in RFC 8784, which includes the pre-shared hybrid key, and the non-hybrid key (e.g, AES only). The reason is same as hybrid key exchange. Moreover, considering that base stations and SEGs are usually provided by different vendors, extra coordination may be required or the key pre-configuration can be implemented by operators during the deployment. Directly use the post-quantum algorithm to negotiate keys, which can be considered when the post-quantum algorithm is mature. Besides, some additional issues also need to be considered, such as increased payload size and IKE fragmentation. About authentication: PKIs that support post-quantum signatures need to be considered. Otherwise, certificate-based authentication may be risky between the base station and the SEG.

For other SDOs, 3GPP has not yet proposed post-quantum migration considerations. The GSMA proposed post-quantum migration guideline partially including the use case.

TODO

IANA Considerations This document has no IANA considerations.

TODO

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet Key Exchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. AT and T Bell Laboratories

Acknowledgments TODO