Network Working Group X. Lyu Internet-Draft X. Yao Intended status: Standards Track D. Ma Expires: November 14, 2021 R. Hou J. Cao X. Mao Xidian University May 13, 2021 PEAA: Privacy-Enhanced Access Authentication Scheme in 5G draft-lyu-privacy-enhanced-5g-aka-00 Abstract Authentication and Key Agreement (AKA) protocol aims to enable mutual authentication between networks and a phone equipped with a Universal Subscriber Identity Module(USIM) card. 5G AKA introduces Subscription Permanent Identifier (SUPI) and Elliptic Curve Integrated Encryption Scheme (ECIES) to preserve user identity privacy. However, when the authentication server becomes an unsecure entity due to malwares or malicious attacks, these existing schemes cannot effectively protect user identity privacy at the server-end. For a small number of important users with high demand for identity privacy and security, comprehensive identity privacy protection is one of their important security requirements. Based on a security assumption that the server is trustworthy within a limited time, this document proposes a privacy-enhanced access authentication scheme (PEAA) which is compatible with 5G AKA. This scheme not only achieves user anonymity on wireless channels by dynamic temporary pseudonyms, but also ensures that the server authenticates users without their permanent identities. In the context of hierarchical security requirements, PEAA scheme and the existing 5G AKA can respectively provide different user identity privacy protection services for users with different security requirements. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Lyu, et al. Expires November 14, 2021 [Page 1] Internet-Draft PEAA May 2021 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 14, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Acronyms and Symbols . . . . . . . . . . . . . . . . . . . . 5 3. Proposed Scheme . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. System Architecture . . . . . . . . . . . . . . . . . . . 6 3.2. Security Assumptions . . . . . . . . . . . . . . . . . . 7 3.2.1. Adversary . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. Communication Entities . . . . . . . . . . . . . . . 7 3.3. Security Requirements . . . . . . . . . . . . . . . . . . 8 3.4. Privacy-Enhanced Access Authentication Scheme . . . . . . 9 3.4.1. System Initialization . . . . . . . . . . . . . . . . 10 3.4.2. Offline Registration . . . . . . . . . . . . . . . . 10 3.4.3. Real-time Authentication . . . . . . . . . . . . . . 10 3.5. Apply PEAA scheme to Real Service Scenarios . . . . . . . 11 4. Security Analysis . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Identity Authentication . . . . . . . . . . . . . . . . . 12 4.2. User Identity Privacy . . . . . . . . . . . . . . . . . . 12 4.2.1. User Identity Privacy on Wireless Channels . . . . . 12 4.2.2. User Identity Privacy at the Server-end . . . . . . . 13 4.3. Confidentiality of system master key s . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Lyu, et al. Expires November 14, 2021 [Page 2] Internet-Draft PEAA May 2021 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction As one of the most widely used Internet access interfaces, mobile communication networks have shown great success in many aspects, such as communicating with others, paying with mobile phones and supporting the Internet of Things (IoT). Users are connected to mobile networks by devices equipped with their own USIM cards, which is achieved by variants of AKA protocol in 3G and 4G mobile networks. The 5th Generation mobile networks (5G) and telecommunication standard are currently under development, and are nearly finalized. The identity authentication in 5G system is based on new versions of AKA protocols, which are included in [TS33501], notably the new 5G AKA protocol. 5G AKA protocol, which involves User Equipment(UE), Serving Network(SN), and Home Network(HN), is an evolution of the AKA variants used in 3G and 4G, and it aims to implement mutual authentication between UE and HN and complete session key agreement between UE and SN. UE communicates with SN through insecure wireless channels, while SN communicates with HN through secure wired channels. The overall architecture of 5G AKA is as follows: +---------+ +---------+ +---------+ | User |insecure wireless| Serving | secure wired | Home | |Equipment|<--------------->| Network |<-------------->| Network | | (UE) | channels | (SN) | channels | (HN) | +---------+ +---------+ +---------+ Figure 1: Overall Architecture of 5G AKA Due to the openness of wireless channels, leaking user identity is possible during the authentication process [Ahlawat18]. Once an adversary obtains a UE's unique identity------International Mobile Subscriber Identity (IMSI), he/she can get the UE's moving trajectory and keep track of the UE or even forge the UE's request. In recent years, how to effectively protect user identity privacy has become an important research hotspot in the field of mobile communication authentication [Ferrag18] [Khan18], and 3GPP is gradually improving user identity privacy-preserving mechanism. 3G system introduces Temporary Mobile Subscriber Identity (TMSI) to protect UE's real identity IMSI. However, a UE's TMSI is only valid in a given Visitor Location Register (VLR). When the current TMSI expires or the UE needs to access a new VLR because of UE's updated location, the UE needs to send its IMSI to the current VLR to get a new TMSI. In this process, there is a security risk of identity leakage. Based on the idea of TMSI in 3G system, 4G system adopts Globally Unique Temporary Lyu, et al. Expires November 14, 2021 [Page 3] Internet-Draft PEAA May 2021 Identifier (GUTI). However, UE needs to send its IMSI for authentication and obtain its GUTI when UE accesses networks for the first time. In this process, UE's IMSI may be leaked. In order to meet the requirements of protecting user identity privacy, 5G system replaces IMSI with Subscription Permanent Identifier (SUPI) [TS33501], that is, SUPI is the permanent real user identity in 5G system. Considering the privacy of SUPI, 5G system utilizes ECIES, an asymmetric cryptographic algorithm, to preserve user identity privacy. In the ECIES-based scheme, UE and HN use public/private key pairs and other parameters to complete key agreement, and then generate a symmetric encryption key. UE uses the key to encrypt SUPI to obtain Subscription Concealed Identifier (SUCI) and then sends SUCI to HN. HN uses the key to decrypt SUCI to get SUCI. So 5G AKA can protect user identity privacy on wireless channels. But this scheme still needs improvement: Only when HN acquires a UE's real identity SUPI, can it verify whether the UE is legal or not. However, there may be some security risks when HN knows UE's real identity, because HN is not always in a secure and reliable state [FRoE17], for example, it is possible that HN is implanted with malicious malware, which may leak out UE's SUPI. In this case, this scheme cannot protect user identity privacy at the server-end. In addition, [Gharsallah19] pointed out that the introduction of asymmetric cryptographic algorithm ECIES requires Public Key Infrastructure (PKI), which may increase the computational overhead of users and authentication servers. In order to solve these problems, this document proposes a privacy- enhanced access authentication scheme (PEAA), the key points are as follows: o PEAA scheme can ensure that HN can authenticate a UE without knowing the UE's unique permanent identity SUPI. It means that the scheme can preserve user identity privacy at the server-end. o User identity privacy at the server-end can still be protected under typical attacks (e.g., replay attacks), even if the server- end is invaded by a malicious adversary during the process of authentication. o PEAA scheme is compatible with 5G AKA. In the context of hierarchical security requirements, PEAA scheme and the existing 5G AKA can respectively provide different user identity privacy protection services for users with different security requirements. For users with general requirements for identity privacy-preserving, the existing 5G authentication scheme can be used to focus on protecting user identity privacy on wireless channels; for a few important users with high-level security Lyu, et al. Expires November 14, 2021 [Page 4] Internet-Draft PEAA May 2021 requirements, PEAA scheme can effectively and comprehensively protect user identity privacy. o PEAA scheme can complete user identity authentication without additional authentication processes or authentication entities (e.g., PKI). In this document, Section 2 introduces the involved acronyms and the meaning of some symbols. Section 3 introduces PEAA scheme in detail, including system architecture, security assumptions, security requirements, detailed authentication process and so on. Section 4 analyzes the security of PEAA scheme. 2. Acronyms and Symbols This document uses the following acronyms: 3GPP 3rd Generation Partnership Project 5G 5th Generation mobile network AKA Authentication and Key Agreement DCDH Divisible Computation Diffie-Hellman Assumption ECIES Elliptic Curve Integrated Encryption Scheme GUTI Globally Unique Temporary Identity HN Home Network HSS Home Subscriber Server IAP Identity Authentication Pair IMSI International Mobile Subscriber Identity IoT Internet of Things PEAA privacy-enhanced access authentication scheme PKI Public Key Infrastructure SN Serving Network SUCI Subscription Concealed Identifier SUPI Subscription Permanent Identifier TMSI Temporary Mobile Subscriber Identity UE User Equipment USIM Universal Subscriber Identity Module VLR Visitor Location Register In this document, "<-" stands for "belong to". For example, "a <- A", which means that element a belongs to set A. The meaning of "!=" is "not equal to". "^" stands for exponential operation, and "Zp*" implies a multiplicative group {1, 2, 3, ..., p-1}. 3. Proposed Scheme In this section, PEAA scheme is introduced in detail. This section first emphasizes the system architecture and the security assumptions of this scheme, then introduces the detailed authentication process Lyu, et al. Expires November 14, 2021 [Page 5] Internet-Draft PEAA May 2021 of PEAA scheme, and finally considers some practical application scenarios. 3.1. System Architecture To ensure that the scheme is compatible with the existing 5G AKA, the communication entities included in PEAA scheme are all defined according to 5G standard. The entities included in this scheme are User Equipment (UE), Serving Network (SN), and Home Subscription Server (HSS). o User Equipment (UE): A device that allows a user to access network services. Each UE has its own SUPI which is stored in UE's USIM card. In this document, UE has the same meaning as user for convenience. o Service Network (SN): A transit site that provides UE with network services. According to 3GPP standard, UE communicates with SN through wireless channels, while SN communicates with HN through secure wired channels. Considering that SN plays a role of transmitting authentication information in the authentication process, SN does not affect encryption operations and decryption operations in the authentication process. So this scheme only considers UE and HSS in the subsequent discussion. o Home Subscriber Server (HSS): The core server that stores users' data (e.g., user identity) and authentication information. In this scheme, HSS authenticates user identity, and it is equivalent to the server-end or the above-mentioned HN. This scheme mainly includes three stages: o System Initialization: HSS selects system parameters required for identity authentication; o Offline Registration: UE performs identity registration at the HSS-end and obtains required information for identity authentication from HSS; o Real-time Authentication: When UE needs the services provided by SN, SN initiates user identity authentication, and HSS verifies the legitimacy of the user identity authentication request. In the first two stages, USIM card has not been allocated to UE; after UE obtains its USIM card from the mobile network service provider, the subsequent identity authentication process is performed. Lyu, et al. Expires November 14, 2021 [Page 6] Internet-Draft PEAA May 2021 3.2. Security Assumptions This section will describe security assumptions from the following two aspects: adversary and communication entities. 3.2.1. Adversary A privacy-preserving scheme is designed to reduce the sensitive information acquired by adversaries while ensuring the quality of service to users. Based on the sensitive information that is available to an adversary, we defined two types of adversaries in this document: passive adversary and active adversary. o Passive Adversary: A passive adversary can only wiretap insecure channels. Although the adversary can get encrypted information by eavesdropping on insecure channels, he/she cannot decrypt it. Based on the eavesdropped information, he/she tries to infer some sensitive information of a particular user, such as user identity, sensitive locations. o Active Adversary: An active adversary can actively invade SN or HSS, and may obtain real identity of a target user through decryption if he/she has enough decrypted information. In this document, both passive adversary and active adversary aim to obtain users' real identities. Based on this security assumption, adversaries will only launch attacks with an ultimate goal of obtaining users' real identities. This scheme does not consider other attacks whose purpose is not to obtain users' real identities, for example, an adversary blocks a user's authentication request to disrupt the user's normal authentication process. 3.2.2. Communication Entities PEAA scheme relies on a security assumption that HSS is trustworthy within a limited time, so this section will clarify the security status of each communication entity in each authentication stage so as to facilitate subsequent security analysis. For the communication entities involved in this scheme, the security assumptions are as follows: o HSS is secure and trustworthy during the processes of System Initialization and Offline Registration. Since System Initialization and Offline Registration are completed before UE securely obtains its USIM card, HSS has unilateral control in these two stages. So this scheme assumes that HSS is trustworthy during System Initialization and Offline Registration; Lyu, et al. Expires November 14, 2021 [Page 7] Internet-Draft PEAA May 2021 o UE is secure during the processes of System Initialization and Offline Registration. USIM card has not been allocated to UE in these two stages. At this time, UE is in a state of securely receiving the necessary authentication information from HSS. So this scheme assumes that UE is secure during these two stages. o HSS is insecure during the process of Real-time Authentication. HSS is vulnerable to malicious attacks because HSS's identity, location, and other information are public. If an adversary invades HSS and obtains key authentication information, HSS will be in an insecure state and may reveal users' identities during the subsequent authentication process. PEAA scheme focuses on user identity privacy-preserving at the server-end, so this scheme assumes that HSS is in an insecure state during the process of Real-time Authentication; o UE is secure during the process of Real-time Authentication. If UE is in an insecure state during the process of Real-time Authentication, an adversary may invade UE and obtain its real identity. At this time, the focus of protecting user identity privacy is to enhance the security of preset authentication information in UE, not the security of identity authentication scheme. It is inconsistent with the focus of PEAA scheme, so this scheme assumes that UE is in a secure state during the process of Real-time Authentication. 3.3. Security Requirements A privacy-enhanced access authentication scheme should meet the following security requirements: o Identity authentication: It should be guaranteed that HSS can authenticate the legitimacy of UE's identity and authorize SN to provide legitimate UE with corresponding network services; o Variable temporary identities: It should be guaranteed that UE can use different dynamic temporary identities in different authentications. o Untraceability: It should be guaranteed that different temporary identities used by a UE in different authentication processes cannot be correlated, and the temporary identity and the UE's real identity cannot be correlated either. o User identity privacy-preserving on wireless channels: It should be guaranteed that an adversary cannot obtain UE's SUPI by eavesdropped authentication message on wireless channels. Lyu, et al. Expires November 14, 2021 [Page 8] Internet-Draft PEAA May 2021 o User identity privacy-preserving at the server-end: It should be guaranteed that HSS can verify the legitimacy of UE's identity without knowing UE's SUPI. 3.4. Privacy-Enhanced Access Authentication Scheme Compared with the existing authentication schemes, PEAA scheme not only pays attention to the security of user identity on wireless channels, but also preserves user anonymity at the server-end. PEAA scheme comprises three stages: System Initialization, Offline Registration, Real-time Authentication. The specific procedures of this scheme is shown in Figure 2. UE HSS (K,SUPI) (K,SUPI,s) | 1. System Initialization | | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | | |HSS selects generator g and system master key s| | | |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| | | | | 2. Offline Registration | | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | | |-------------------- SUPI, K -------------------->| | | |<------------------- g, SUPI^s, K^s ---------------------| | | |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | | | | | 3. Realtime Authentication | | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | | |1) UE selects secret parameter u and temporary mask r | | | | | | | |2) UE caculates AUTH_req and then send it to HSS. | | | |................................................... | | | |: AUTH_req = {SUPI^r, g^r, g^u, (Pi1,Pi2), Ts, h} : | | | |: h = H(SUPI^(s*r)||(Pi1,Pi2)||Ts) :------>| | | |: Pi1 = K^(u*s) + SUPI^(s*r),Pi2 = K^(u*(SUPI^r)) : | | | |................................................... | | | | | | | | 3) HSS performs integrity check: | | | | P = (SUPI^r)^s;h' = H(P||(Pi1,Pi2)||Ts);h' = h | | | | | | | | 4) HSS verifies the identity validity of UE: | | | | (Pi1-SUPI^(s*r))^(SUPI^r) = Pi2^s | | | |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ | | | | | <-------HSS verifies the identity validity of the UE---------| Figure 2: The Procedures of PEAA scheme Lyu, et al. Expires November 14, 2021 [Page 9] Internet-Draft PEAA May 2021 3.4.1. System Initialization Given a cyclic group G of prime order p. HSS selects a generator g <- G of group G, and chooses s <- Zp* as system master key. Then HSS makes the generator g public and keeps the system master key s secret. Note that s != 1 mod p and s != 0 mod p for security reasons. 3.4.2. Offline Registration Referring to Section 3.2.2, HSS is trustworthy during the process of Offline Registration, that is, UE can register at the HSS-end securely. o UE --> HSS: UE sends SUPI mod p and the corresponding pre-shared symmetric key {K mod p} to HSS; o HSS --> UE: HSS calculates SUPI^s mod p and K^s mod p, and sends the results to UE. Since all subsequent authentication operations are performed on the cyclic group G, the symbol "mod p" is omitted in order to simplify expression. 3.4.3. Real-time Authentication When UE obtains the identity authentication information and needs to use network services, SN forwards UE's authentication request, then HSS verifies the request and instructs SN whether to provide network services for UE. The specific authentication process is as follows: o UE selects parameters: UE selects a fixed secret parameter u <- Zp* (u != 1). Meanwhile, UE selects r <- Zp* (r != 1) as a temporary mask. o UE --> HSS: UE calculates SUPI^r as a temporary pseudonym and obtains AUTH_req according to Equation 1. Then UE sends AUTH_req to HSS. This document defines (Pi1, Pi2) as Identity Authentication Pair (IAP). +--------------------------------------------------------+ | AUTH_req = {SUPI^r, g^r, g^u, (Pi1,Pi2), Ts, h} | | | | h = H(SUPI^(s*r)||(Pi1,Pi2)||Ts) | | Equation 1 | | Pi1 = K^(u*s) + SUPI^(s*r) | | | | Pi2 = K^(u*(SUPI^r)) | +--------------------------------------------------------+ Lyu, et al. Expires November 14, 2021 [Page 10] Internet-Draft PEAA May 2021 o HSS performs integrity check: After receiving AUTH_req = {SUPI^r, g^r, g^u, (Pi1,Pi2), Ts, h} from UE, HSS calculates P=(SUPI^r)^s according to system master key s and the received SUPI^r, and then calculates h' = H(P||(Pi1,Pi2)||Ts). If h' != h, the received AUTH_req isn't integrate, so HSS ignores the authentication request and sends a failure signal to UE who sends AUTH_req; if h' = h, the received AUTH_req is integrate, and then HSS continues to perform the subsequent fourth step. o HSS verifies the identity validity of UE: HSS calculates (Pi1-SUPI^(s*r))^(SUPI^r) and judges whether it is equal to Pi2^s. If (Pi1-SUPI^(s*r))^(SUPI^r) != Pi2^s, it means that AUTH_req does not contain the legal user identity, and the authentication fails; if (Pi1-SUPI^(s*r))^(SUPI^r) = Pi2^s, it means that the temporary pseudonym SUPI^r contained in the authentication tuple represents the real identity of UE who sends AUTH_req, and HSS verifies the identity validity of the UE. SN is authorized to supply corresponding services to the legitimate UE who has the temporary pseudonym SUPI^r. 3.5. Apply PEAA scheme to Real Service Scenarios In a lot of real application scenarios, HSS needs to know stable identities of users so that it can provide services for UE, such as location-based services, call forwarding services, billing service. Especially for the billing service, HSS needs to link a fixed billing account with a UE, and determines whether to provide the UE with communication services based on the balance of UE's account. Thus there is a conflict, that is, UE wants to preserve user identity privacy at the HSS-end, but HSS needs to obtain UE's stable identity in order to provide corresponding services. To resolve this conflict, this scheme maps UE's SUPI to an anonymous fixed billing account. Shown in Section 3.4.3, Pi1 = K^(u*s) + SUPI^(s*r). When HSS receives Pi1 and SUPI^r, HSS can get UE's stable anonymous identity K^(u*s). Noted that getting fixed secret parameter u in the case of knowing K^(u*s) and system master key s is a Discrete Logarithm(DL) Problem. HSS can assign a stable billing account to the anonymous identity K^(u*s). By mapping UE's SUPI to K^(u*s), this scheme not only protects user identity privacy at the HSS-end, but also enables HSS to provide normal billing service without revealing UE's SUPI. 4. Security Analysis This section will analyze the security of PEAA scheme from three aspects: Identity Authentication, User Identity Privacy, Confidentiality of system master key s. Lyu, et al. Expires November 14, 2021 [Page 11] Internet-Draft PEAA May 2021 4.1. Identity Authentication By judging whether h' = H(P||(Pi1, Pi2)||Ts) is equal to h and (Pi1- SUPI^(s*r))^(SUPI^r) is equal to Pi2^s, HSS can check whether UE has SUPI^s and the corresponding K^s. According to the security assumption in Section 3.2.2, UE can keep its SUPI and the corresponding pre-shared symmetric key K secret, that is, USIM card has no security risks, and HSS can securely allocate SUPI^s and K^s to UE. If a UE can provide an IAP containing both SUPI^s and K^s, HSS can authenticate the UE's legitimacy, and then SN is authorized to provide network services for the UE. Otherwise, the authentication fails. 4.2. User Identity Privacy This section will analyze whether user identity privacy can be preserved from the following two aspects: one is user identity privacy on wireless channels, the other is user identity privacy at the server-end. Correspondingly, this section defines two types of adversaries: Adversary AI and Adversary AII. 4.2.1. User Identity Privacy on Wireless Channels Adversary AI is a passive adversary, who can eavesdrop on wireless channels with security risks and obtain a series of information exchanged by a target user with HSS during their authentication process. Assume that AI is also a legitimate user in the communication system, and performs normal identity authentication like other legitimate users. Based on the eavesdropped authentication information about the target user and the information exchanged by AI with HSS during their authentication process, AI tries to infer SUPI of the target user. For AI, the process to obtain these information is as follows: o Adversary AI performs normal identity authentication: * System Initialization: HSS selects generator g <- G of group G, and chooses s as system master key. Then HSS sends the generator g to Adversary AI and keeps the system master key s secret. * Offline Registration: Adversary AI sends his/her real identity SUPI_ad and the corresponding pre-shared symmetric key K_ad to HSS, HSS calculates SUPI_ad^s and K_ad^s, and sends the results to Adversary AI. * Real-time Authentication: Adversary AI sends AUTH_req_ad to HSS, and HSS returns the verification result of AUTH_req_ad; Lyu, et al. Expires November 14, 2021 [Page 12] Internet-Draft PEAA May 2021 o Adversary AI eavesdrops on wireless channels: Adversary AI can obtain the information exchanged between his/her target user and HSS during the process of Real-time Authentication by eavesdropping on wireless channels. The target user, whose real identity is SUPI, will send AUTH_req_user to HSS during the process of real-time authentication, that is, Adversary AI can obtain AUTH_req_user that is sent by the target user on wireless channels. In summary, Adversary AI has already obtained {g, SUPI_ad, SUPI_ad^s, K_ad, K_ad^s, AUTH_req_ad, AUTH_req_user}, and then AI tries to obtain the target user's real identity SUPI. Theorem 4.1. If adversary AI can extract real identity SUPI of the target user from {g, AUTH_req_user} with the probability P in time t, HSS can solve Divisible Computation Diffie-Hellman (DCDH) problem with the probability P' = P in time t' = t. PROOF. Referring to Section 3.4, g is the generator of G. Given (g, g^x, g^y), where x, y <- Zq*, the process of HSS calculating g^(x/y) is as follows: o HSS runs AI with {SUPI^r = g^x, g^r = g^y} to obtain SUPI of the target user, and the probability of success is P and time of the process is t; o Referring to Equation 1, HSS calculates like this: SUPI^r = g^x ==> SUPI = g^(1/r*x) ==> SUPI = g^(x/y), the probability of success is 1, and the time spent is ignored; o Finally, HSS uses (g, g^x, g^y) to obtain g^(x/y) with the probability P' = P*1 = P, and the total time is t'= t. Conclusion: For Adversary AI on wireless channels, obtaining real identity SUPI of the target user is equivalent to the process that HSS solve the DCDH problem. 4.2.2. User Identity Privacy at the Server-end Adversary AII is an active adversary. He/she can actively invade HSS and makes HSS be in an insecure state during the process of Real-time Authentication. At this time, Adversary AII can obtain the information stored by HSS, such as HSS's system master key s, authentication information sent by Adversary AII's target user to HSS and so on. Assume that AII is also a legitimate user in the communication system, and performs normal identity authentication like other legitimate users. Based on the information obtained by invading HSS and the information exchanged by AII with HSS during Lyu, et al. Expires November 14, 2021 [Page 13] Internet-Draft PEAA May 2021 their authentication process, AII tries to infer SUPI of the target user. For AII, the process to obtain these information is as follows: o Adversary AII performs normal identity authentication: This process is the same as the process described in Section 4.2.1, so this document won't repeat it here. o Adversary AII invades HSS: After invading HSS, Adversary AII can obtain the authentication information AUTH_req_user sent by the target user to HSS and the system master key s of HSS. In summary, Adversary AII has already obtained {g, s, AUTH_req_user}, and then AII tries to obtain the target user's real identity SUPI. It should be noted that legitimate users will send their SUPI and the corresponding pre-shared symmetric key K to HSS during the process of Offline Registration, which means that HSS stores all legitimate users' SUPI, corresponding pre-shared symmetric key K, and corresponding relationship between SUPI and K, which are called "SUPI-K Related Information" for convenience. Considering that HSS is invaded, SUPI-K Related Information may also be obtained by Adversary AII. Based on this assumption, if AII can obtain pre- shared symmetric key K of the target user on the premise of acquiring {g, s, AUTH_req_user}, AII can query SUPI-K related information to get SUPI of the target user. This document will analyze the situation where Adversary AII makes use of {g, s, AUTH_req_user} to obtain pre-shared symmetric key K of the target user. Theorem 4.2. If Adversary AII can extract pre-shared symmetric key K from {g, s, AUTH_req_user} with the probability P in time t, HSS can solve DCDH problem with the probability P' = P in time t' = t. PROOF. Referring to Section 3.4, g is the generator of G. Given (g, g^x, g^y), where x, y <- Zq*, the process of HSS calculating g^(x/y) is as follows: o HSS runs AII with {s, K^(u*s) = g^x, g^u = g^y} to obtain pre- shared symmetric key K of the target user, and the probability of success is P and time of the process is t; o Referring to Equation 1, HSS calculates like this: K^(u*s) = g^x ==> K^s = g^(1/u*x) ==> K^s = g^(x/y) ==> K = g^(x/(s*y)), the probability of success is 1, and the time spent is ignored; o Finally, HSS uses (g, g^x, g^y) to obtain g^(x/y) with the probability P' = P*1 = P, and the total time is t'= t. Lyu, et al. Expires November 14, 2021 [Page 14] Internet-Draft PEAA May 2021 Conclusion: For the adversary AII who invades HSS, obtaining the target user's pre-shared symmetric key K is equivalent to the process that HSS solve the DCDH problem. 4.3. Confidentiality of system master key s Referring to the security assumption about HSS in Section 3.2.2, HSS is in an insecure state due to being invaded by an adversary or being implanted with malwares in the stage of Real-time Authentication. At this point, the adversary can obtain the system master key s of HSS and has the ability to decrypt. He/she also has the ability to forge a series of AUTH_req and send them to HSS to launch Denial of Service(DoS) attacks. However, the security assumption in Section 3.2.1 clearly points out that adversaries will only launch attacks with an ultimate goal of obtaining users' real identities, and this scheme does not consider other attacks whose purpose is not to obtain users' real identities. So this document only considers whether a legitimate UE can obtain the system master key s of HSS by decrypting the existing authentication message without additional information. In other words, a legitimate UE holds {g, SUPI, K, SUPI^s, K^s}and wants to extract HSS's system master key s. For convenience, this document only considers the situation where the legitimate UE makes use of {g, SUPI, SUPI^s} to extract HSS's system master key s. Theorem 4.3. If a legitimate UE can extract HSS's system master key s from {g, SUPI, SUPI^s} with the probability P in time t, HSS can solve DCDH problem and DL problem with the probability P' = P in time t' = t. PROOF. Referring to Section 3.4, g is the generator of G. Given (g, g^x, g^y), where x, y <- Zq*, the process of HSS calculating g^(x/y) is as follows: o HSS runs UE with {g, SUPI = g^x, SUPI^s = g^y} to obtain the system master key s of HSS, and the probability of success is P and time of the process is t; o Referring to Equation 1, HSS calculates like this: g^y = g^(s*x) ==> g^s = g^(y/x). First, UE calculates g^(y/x) according to (g, g^x, g^y), and then calculates the system master key s according to (g, g^s); o Finally, HSS uses (g, g^x, g^y) to obtain system master key s with the probability P' = P, and the total time is t'= t. Lyu, et al. Expires November 14, 2021 [Page 15] Internet-Draft PEAA May 2021 Conclusion: For a legitimate UE with existing certification information, obtaining HSS's system master key s is equivalent to the process that HSS solve the DCDH problem and DL problem. 5. IANA Considerations There is no IANA consideration needed. 6. Security Considerations In order to resist replay attacks, this scheme uses a time stamp Ts, which describes the life cycle of the current authentication message, and defines the integrity check value h = H(SUPI^(s*r)||(Pi1, Pi2)||Ts), where SUPIs is part of UE's secret storage. Therefore, on the premise of only obtaining SUPI^r, it is difficult for an adversary to forge legal AUTH_req without changing integrity check value h. But according to the security assumption in Section 3.2.2, HSS may be in an insecure state, and the adversary may obtain HSS's system master key s. In this case, replay attacks cannot be avoided. However, UE's SUPI won't be leaked under replay attacks, and user identity privacy can be preserved without affecting the normal authentication of target users. In addition to replay attacks, an adversary may launch masquerading attacks, that is, he/she tries to extract IAP = (Pi1, Pi2) from the old legitimate authentication request of the target user. Referring to Equation 1, the adversary cannot obtain the legal IAP without HSS's system master key s. As with replay attacks, when the adversary obtains system master key s of HSS, the target user cannot avoid impersonation attacks, but user identity privacy still can be preserved. In summary, when HSS's system master key s is kept secret, PEAA scheme can resist replay attacks and masquerading attacks. PEAA scheme can protect user identity privacy at the HSS-end, but cannot resist these two attacks when HSS becomes insecure due to malwares or malicious attacks and the system master key s is leaked. As a consequence, the key to avoiding replay attacks and impersonation attacks is to protect HSS's system master key s. In this scheme, HSS regularly updates its system master key s. UE needs to perform Offline Registration regularly, and HSS is responsible for updating authentication-related information. Finally, an adversary may send a large number of authentication requests to consume computing resources and bandwidth resources of HSS as much as possible, thereby preventing other legitimate users from accessing. In this scheme, after receiving authentication request AUTH_req from UE, HSS performs exponentiation and hashing Lyu, et al. Expires November 14, 2021 [Page 16] Internet-Draft PEAA May 2021 operations to check the integrity of AUTH_req. Compared to asymmetric decryption, exponentiation and hashing operations are lightweight. After confirming the integrity of AUTHreq, HSS will proceed with subsequent heavyweight certification operations. Although the Denial of Service(DoS) attacks cannot be completely resisted, the impact of DoS attacks can be reduced with the preliminary integrity check. 7. References 7.1. Normative References [TS33501] 3rd Generation Partnership Project, "Security architecture and procedures for 5G system", Release 16, TS 33.501, September 2019. 7.2. Informative References [Ahlawat18] Ahlawat, A. and S. Kumar, "Investigating Various Possible Attacks and Vulnerabilties in LTE. International Journal of Computerences & Engineering, Vol. 6 (3).", 2018. [Ferrag18] Ferrag, M., Maglaras, L., Argyriou, A., Kosmanos, D., and H. Janicke, "Security for 4G and 5G cellular networks: A survey of existing authentication and privacy-preserving schemes. Journal of Network and Computer Applications", 2018. [FRoE17] 3rd Generation Partnership Project, "First response on ECIES for concealing IMSI or SUPI, 3GPP TSG SA WG3 (Security) Meeting", 2017. [Gharsallah19] Gharsallah, I., Smaoui, S., and F. Zarai, "A secure efficient and lightweight authentication protocol for 5G cellular networks: SEL-AKA. 2019 15th International Wireless Communications & Mobile Computing Conference (IWCMC)", June 2019. [Khan18] Khan, M., Niemi, V., and P. Ginzboorg, "IMSI-based Routing and Identity Privacy in 5G", 2018. Lyu, et al. Expires November 14, 2021 [Page 17] Internet-Draft PEAA May 2021 Authors' Addresses Xixiang Lyu Xidian University No.266 Xifeng Road Shanxi, Xi'an 710126 China Email: xxlv@mail.xidian.edu.cn Xinyue Yao Xidian University No.266 Xifeng Road Shanxi, Xi'an 710126 China Email: xyyaoo@stu.xidian.edu.cn Dong Ma Xidian University No.266 Xifeng Road Shanxi, Xi'an 710126 China Email: 1282844751@qq.com Ronghui Hou Xidian University No.266 Xifeng Road Shanxi, Xi'an 710126 China Email: rhhou@xidian.edu.cn Jin Cao Xidian University No.266 Xifeng Road Shanxi, Xi'an 710126 China Email: jcao@xidian.edu.cn Lyu, et al. Expires November 14, 2021 [Page 18] Internet-Draft PEAA May 2021 Xinhong Mao Xidian University No.266 Xifeng Road Shanxi, Xi'an 710126 China Email: 16145600@qq.com Lyu, et al. Expires November 14, 2021 [Page 19]