Internet DRAFT - draft-lyu-privacy-enhanced-5g-aka
draft-lyu-privacy-enhanced-5g-aka
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]
