Security Consideration in 5G

Security Consideration in
5G
From User Authentication Perspective

Outline
2
1. 5G Service Scenarios
2. 5G Security – Core Areas
3. A USIM compatible 5G AKA protocol with perfect forward secrecy
4. Secure Authentication Protocol for 5G Enabled IoT Network
5. Lightweight Handover Authentication Scheme for 5G-based V2X
Communications
6. References

5G Service Scenarios
Key Scenarios to be Addressed throughout the Multiple Stages of 5G
Development
3

5G Security – Core Areas
Flexible and scalable security
architecture
• Virtualization and dynamic
configuration for 5G promotes new
dynamic and flexible security
architecture
• Security for RAN signaling could be
located close to the access (e.g.,
virtualization) with a higher degree of
independence to the user plane
security, allowing more robust security
(key distribution, key isolation, etc.)
5G radio network security
• Attack resistance of radio networks to
threats such as Denial of Service from
potentially misbehaving devices
• Adding mitigation measures to radio
protocol design
• Utilize available trusted computing
technologies
Virtualization security (ETSI NFV
SEC)
• Network virtualization with high assurance
of VNF isolation to simplify the handling of
diverse security requirements in common
infrastructure
• Use existing trusted computing tools (TCG)
and concepts for Virtualized Platform
Integrity
root of trust
remote attestation
device integrity monitoring
secure storage
• Cloud-friendly data encryption
(homomorphic encryption, allowing
operations on encrypted data).
Identity management
5G open identity management
architecture
• Billions of heterogeneous end-devices,
sensors, network nodes with variable
security capabilities, device attributes, and
policies
• Allow enterprises with an existing IDM
solution to reuse it for 5G access.
• New ways to handle device/subscriber
identities with network slicing, enabling
different IDM solutions per slice
Energy-efficient security
• Most constrained, and battery-
dependent devices with a long life time
might be separated in specialized
energy-efficient lightweight network
slice
• Need to compare energy cost of
encrypting one bit vs. transmitting one
bit and consider hardware acceleration
benefits
Security assurance
• Deployment of heterogeneous
hardware and software components
creates greater need for security
certification
• System state attestation needs to be
communicated between entities to
provide assurance in platform
integrity
• Multi-layer security certification
scheme is needed to efficiently create
and traverse certification records
4

1- A USIM compatible 5G AKA protocol with perfect
forward secrecy
5
• 3GPP uses Authentication and Key Agreement (AKA) to define the security properties for user
authentication.
• Recent reports of compromised long term pre-shared keys used in AKA, specially when there is a weaker
trust model, indicate a need to look into better solutions.
• The authors present constructions for 3GPP Authentication and Key Agreement (AKA) that provides Perfect
Forward Secrecy for the session key.
• The constructs prevents an attacker, with access to the long-term pre-shared key, from simply
eavesdropping the challenge RAND in the AKA run, and use the RAND and long-term pre-shared key to
derive the session key.
• The constructions maintain the interface between the Universal Subscriber Identification Module (USIM)
and the mobile terminal intact. As a consequence, there is no need to roll out new credentials to existing
subscribers.

1- A USIM compatible 5G AKA protocol with perfect forward secrecy
3GPP Authentication and Key Agreement (3G AKA)
6
Trust model for 3GPP AKA:
• No attacker is assumed to have access to the ME USIM
interface.
• Neither ME nor MME is trusted with pre-shared key “K”.
The key K is kept secret in the USIM and the HSS.
• The communication between HSS and MME is assumed to
be integrity, replay and confidentiality protected. The link
between the MME and the ME is assumed to be without
any kind of protection.
• Therefore confidentiality and integrity of K, have to be
ensured when it is provisioned into HSS and USIM.
• This implies that if K is compromised, then an attacker
only needs to eavesdrop RAND to be able to derive the
encryption and integrity key (the session key) for the air-
link protection.
• It is a goal of this paper to prevent this passive attack.

3GPP Authentication and Key Agreement (3G AKA)
7
The 3G AKA protocol is a challenge-response protocol based on symmetric key cryptography; it involves
multiple parties.
1. The MME initiates AKA by sending a request for an Authentication
Vector (AV) associated with a particular subscriber to the HSS.
2. The HSS responds with an AV consisting of the tuple (RAND, AUTN,
XRES, KASME), where RAND is a random value, AUTN is a network
authentication token, XRES is the expected response from the ME and
KASME is the session key that will be established in the ME and MME on
completion of the AKA run. The AUTN, XRES and KASME are derived
from the RAND and the pre-shared key K present in the HSS and in the
USIM. As an intermediate step in the derivation of KASME, keying
material named CK/IK is produced.
3. When the MME receives the AV, it can initiate the authentication
procedure with the ME by forwarding the RAND and AUTN.
4. The ME sends the RAND and AUTN to the USIM, which verifies the
authenticity and freshness of the AUTN parameter. If the verification
succeeds, the USIM derives a response parameter RES and keying
material CK/IK from K stored in the USIM and the received parameters.
5. The USIM then forwards the RES and keying material CK/IK to the ME.
6. The ME derives KASME from the CK/IK and sends RES to the MME.
7. The MME verifies that RES is equal to XRES and accepts the
authentication if so. Otherwise the MME rejects the authentication.

Enhancements To 3G AKA
8
• The enhancements presented are compatible with the signaling flow and other basic structures of AKA.
• The enhancements are based on new properties for the K'ASME compared to the properties of the KASME.
• Perfect forward secrecy (PFS) is defined as the property that a session key remains secret even though the
long-term key is compromised in the future.
• Two main options, A and B, based on Diffie-Hellman (DH) exchange. Option A requires no modification to
the HSS, whereas option B does.
Option A (Enhanced 3G AKA, No modification to HSS)
1. In option A, the MME request a regular AV from the HSS. The
MME then generates an ephemeral DH-parameter 𝑔 𝑥
and
calculates a Message Authentication Code (MAC𝑔 𝑥
) over the
𝑔 𝑥
using KASME as a key.
2. The MME next sends 𝑔 𝑥
and MAC𝑔 𝑥
together with the RAND
and AUTN from the AV to the ME.
3. The ME forwards the RAND and AUTN to the USIM, which
verifies the AUTN and calculates the keying material CK/IK and
the response parameter RES; these parameters are then
forwarded to the ME.
4. Next, the ME calculates the KASME and generates 𝑔 𝑦
and a
corresponding MAC𝑔 𝑦
. The ME concludes by sending the RES
and MAC𝑔 𝑦
to the MME so that the MME can verify the RES.
Both the ME and MME now calculate a K'ASME from the DH-key
𝑔 𝑥𝑦
. The K'ASME can at this point be used as a basis for a key
hierarchy. Before using the K'ASME, both parties verify the MAC
of the other party's ephemeral DH-parameter.

Enhancements To 3G AKA
9
Option B (Enhanced 3G AKA, with modification to HSS in order to reduce load on wireless interface MME-ME)
1. The MME requests a different type of AV from the HSS. This
type of AV also contains an x generated by the HSS, and the
RAND value is generated by computing a hash over 𝑔 𝑥
.
Because the HSS includes x in the AV, the MME will be able to
calculate (𝑔 𝑦
) 𝑥
in step 5.
2. Upon receipt of the AV, the MME transmits the RAND, AUTN
and 𝑔 𝑥
to the ME.
3. The ME forwards the RAND and AUTN to the USIM which
verifies the AUTN, calculates CK/IK and RES, before
forwarding these to the ME.
4. Since the AUTN is calculated in dependence of the RAND,
which in turn contains the hash of 𝑔 𝑥
, this provides
authentication of 𝑔 𝑥
to the USIM, and hence indirectly to the
ME based on the trust model.
5. Next, the ME generates 𝑔 𝑦
, calculates the corresponding
MAC𝑔 𝑦
, and sends the 𝑔 𝑦
, MAC𝑔 𝑦
and RES to the MME. The
ME and MME calculates a K'ASME from the 𝑔 𝑥𝑦
as in option A.

2 - Secure Authentication Protocol for 5G Enabled IoT Network
• 5G is becoming an integral part of IoT services. As the figure depicts, there can be various types of services, such as M2M
communication, Vehicular Communication, Mobile Communication, available from a 5G enabled IoT network. A User
Equipment (Vehicle or Machine or Mobile) could connect to 5G network through some Access network for availing various
services from various IoT servers.
• An attacker may use the extracted data from impersonation and DoS attacks. Hence, there is a crucial requirement of
security protocol to preserve privacy along with confidentiality and integrity of the data exchanged.
• Access and Mobility Management (AMF) /
Functionality as in LTE MME-HSS : It is responsible for
maintaining mobility, registration and reachability management. It
provides access authentication, access authorization, Security
Anchor Function (SEAF) support and Security Context Management
Function (SCMF) support.
• Session Management Function (SMF): It is responsible for
managing sessions, allocating IP address for user equipment, user
plane selection and controlling policy enforcement and QOS.
• Unified Data Management (UDM): It is responsible for
Authentication Credential Repository and Processing Function (ARPF)
support and subscription of data storage.
• Policy Control Function (PCF): It is responsible for making policies
for Control plane.
• Authentication Server Function (AUSF): It provides authentication
for various services and user equipment(UE).
• Network Slice Selection Function (NSSF): It chooses the group of
network slice instances serving the UE, determining allowed
Network Slice Selection Association Information (NSSAI) and
determining the AMF Set to be used to serve the UE.

2- Secure Authentication Protocol for 5G Enabled IoT Network
11
Security Assumptions
Assumption 1: The encrypted service-request/user-credential can only be decrypted by a shared symmetric-key, which was
used for encryption.
Assumption 2: AMF is the full trusted party and physically secured.
Assumption 3: User equipment is also trusted party of the system; it is free from malware and not physically tampered.
Threat Model
• Threat on authentication: There is a possibility of unauthenticated attacker Trudy, who has the
capability of monitoring, intercepting, and impersonate as an authenticated user equipment to send
data through the 5G network. The possible attacks by the attacker are: Sybil, impersonation, identity-
based attacks, etc.
• Threat to confidentiality: An adversary is an unauthorized person who could access and understand the
unauthorized service-query or service-allocation in the path to 5G network. Various possible passive
attacks include packet sniffing, phishing, etc.
• Threat to integrity: An attacker may have an attack on integrity; he could monitor the service-
request/user-credentials in 5G and user equipment. The attacker may attempt to access and alter the
service before it reaches AMF of 5G network. Numerous possible attacks include man-in-the-middle
attack, session hijacking attack, etc.

Step 1: Initially, a User Equipment UEi sends its identification number
UEid and a random number rn obtained by it. It sends (UEid; rn) to
the Core Access and Mobility Management Function (AMF) through
the Access Network.
Step 2: AMF receives the pair (UEid; rn) from the User Equipment
UEid, it retrieves its shared symmetric key, Ki , after that, AMF
generates a random number for communicating with the
corresponding User Equipment UEid. AMF also calculates the key
Skey by bit-wise X-ORing the temporary key rn2 and secret key Ki.
The AMF encrypts the generated key Skey with the UEid’s random
number rn. Then, AMF calculates a message digest for integrity using
one way hash function H() and generates the end message h1. AMF
sends the secret message e1 with message digest h1.
Step 3: The User Equipment UEid gets {h1; e1} from the AMF and
decrypts the encrypted message e1 with D(). The User Equipment
then finds rn2 by X-ORing Skey and ki. It then generates its own
version of secret message and its corresponding hash values as e2
and h2, respectively. The User Equipment, UEid then compares its
created versions e2 with e1 and h2 0 with h1. If it finds that both e2 =
e1 and h2' = h1 true, then it authenticates the AMF, otherwise it
terminates the protocol.

Step 4: AMF receives the h2' from User Equipment UEid, then
checks equality of it with
H (h1 ǁ Skey ǁ e1 ǁ rn). If it is true, then User Equipment UEid
is authenticated by AMF and it sends the h3; Otherwise, then
exits.
Step 5: The authenticated User Equipment Ueid ciphers the
ServiceRequest with secret key Ki and evaluates the message
integrity h4 by H(e3). After that, it creates a variable A and
assigns the result obtained by bitwise X-ORing h4 and h2' and
transmits it along with e3.
Step 6: AMF obtains {e3;A}. Then it retrieves h4 from A by
bit-wise X-ORing. Next, it evaluates its message digest for
integrity check from e3. After that, it checks the equality
between h4 and h4'. If equal, then the encrypted
ServiceRequest e3 is decrypted to obtain the Service
Request. It then processes the ServiceRequest and sends
back the results and acknowledgment to User Equipment
UEid.

Theme
• Need of secure, reliable and efficient handover authentication with low
computation overheads.
• Each vehicle can temporarily acquire Network Function Virtualization (NFV)-
manager in its home and PLMN (Public Land mobile network).
• The above encrypted ID will ensure authentication when handover occurs.
Proposal
• Introduced lightweight handover authentication scheme, that can be used in 5G
V2X applications.
• Initial Mutual Authentication Scheme: Both ‘Vehicle’ and ‘NFV manager’
authenticates each other unlike the previous authentication scheme. In this
scheme the authenticated vehicle acquires temporary identity encrypted using
NFV manager and SDN controllers private keys.
• Lightweight authentication scheme: This is based on the shared key and the
encrypted identity created in initial authentication, the roaming vehicle
authenticates to the visited PLMN with lightweight symmetric encryption.
Additionally two types of authentications are discussed, when the home and
PLMNs share the same and different SDN Controllers .
3 - Lightweight Handover Authentication Scheme for 5G-based V2X
Communications

Initial Mutual Authentication
As initial step, when connected to the network, the vehicle sends a list of network slices IDs it wishes support for, a random number, rn1, vehicle
capabilities, and subscription information, including the vehicle certificate and public key, to the NFV-manager. Note that the network slices IDs are
put in the device at the time of configuration.
• After checking the certificate, the NFV-manager performs the following:
1) Selects the best one of the network slices to support the vehicle, NSid.
2) Creates a shared key, to be used in subsequent messages with the vehicle, KMng−V .
3) Creates a unique identity for the vehicle, as MngID||V ID, and encrypts it using the NFVmanager’s private key, EPRMng {MngID||V ID}.
4) Sends the encrypted identity to the connected SDN-controller after encrypting it using the shared key with the controller, KSDN. The SDN
controller encrypts the received encrypted identity using its private key, PRSDN, and then sends it back to the NFV-manager, EPRSDN {EPRMng
(MngID||V ID)}.
5) Computes the hash of the encrypted unique Id of the vehicle , H(EPRMng {MngID||V ID}) then encrypts the hash value again using the shared
key with the SDN controllerKSDN. Therefore the final value will be EKSDN {H(EPRMng {MngID||V ID})}. Note that the vehicle can not decrypt the
hash value because the vehicle does not have the SDN controller’s shared key with the NFV-manager.
6) Encrypts the above information, after adding its certificate along with the received random number, rn1, and another random number, rn2, by
the vehicle’s public key, as follows:
EPUvi {NSid,KMng−v,EPRSDN (EPRMng {MngID||V ID}),EKSDN {H(EPRMng {MngID||V ID})}, rn1, rn2, Signature, CERT}
7) Transmits the encrypted message to the vehicle.
The vehicle decrypts the message and checks the NFVmanager’s certificate, then replies with the received random number, rn2, after encrypting it
using the shared key, KMng−V . The NFV-manager also creates a CCNF that is responsible of subsequent communications with the authenticated
vehicle.
3 - Lightweight Handover Authentication Scheme for 5G-based V2X Communications

Handover under Same SDN controller
When the vehicle roams to a different PLMN, the vehicle performs the following steps to mutually authenticate
itself with the new NFV-manager in the visited network:
The vehicle sends a handover request to the new NFV-manager to join its network. The request message contains
the encrypted hash of their identity,
EKSDN {H(EPRMng {MngID||V ID})}, that is transmitted from the home NFV-manager in the initial authentication
scheme, illustrated in Section III-B. The vehicle also adds its identity, which is encrypted using its home NFV-
manager’s private key, EPRMng {MngID||V ID}, along with a random value, nonce1.
• Upon receiving the request message, the visited NFVmanager first decrypts the encrypted hash, then compares
the decrypted value with the hashed value of the vehicle’s identity,
H(EPRMng {MngID||V ID}).
• The visited NFV-manager authenticates the vehicle if the compared values are equal, and the NFV-manager then
replies with nonce1, that is transmitted before by the vehicle, along with another random number, nonce2
• The visited NFV-manager also creates a new secret key, K Mng−v , to be used as a shared secrete between the
new NFV-manager and the roaming vehicle and encrypts it using the vehicle identity, V ID before transmitting it to
the vehicle.

Handover Under Different SDN-controllers
• When the vehicle roams to a PLMN that is under different SDN-controller, the previous handover
authentication cannot be used because the new NFV-manager does not know the shared key with
the previous SDN-controller, KSDN. Therefore, the vehicle performers the following steps instead:
• Since the visited PLMN is under different SDNcontroller, the vehicle sends a handover request to the
new NFV-manager as before, but after updating the request. Therefore, the request message
contains the vehicle identity encrypted using it home NFV-manger and SDN-controller’s private keys,
EPRSDN {EPRMng {MngID||V ID}}. Note that this encrypted identity is transmitted from the home
NFVmanager in the initial authentication scheme, illustrated in Section III-B.
• The vehicle also sends its identity and encrypts the whole request message using the visited NFV-
manager’s public key, PUMng−new, as follows:
EPUMng−new {MngID||V ID,EPRSDN {EPRMng−home {MngID||V ID}}}.

References
• Arkko, Jari, Karl Norrman, Mats Näslund, and Bengt Sahlin. "A USIM compatible 5G AKA protocol
with perfect forward secrecy." In 2015 IEEE Trustcom/BigDataSE/ISPA, vol. 1, pp. 1205-1209. IEEE,
2015.
• Sharma, Suraj, Shaswat Satapathy, Shivani Singh, Amiya Kumar Sahu, Mohammad S. Obaidat,
Sanjay Saxena, and Deepak Puthal. "Secure Authentication Protocol for 5G Enabled IoT Network."
In 2018 Fifth International Conference on Parallel, Distributed and Grid Computing (PDGC), pp.
621-626. IEEE, 2018.
• Taha, Sanaa, and Xuemin Shen. "Lightweight Group Authentication with Dynamic Vehicle-
Clustering for 5G-Based V2X Communications." In 2018 IEEE Global Communications Conference
(GLOBECOM), pp. 1-6. IEEE, 2018.
20

3- A Secure Efficient and Lightweight authentication protocol for 5G
cellular networks: SEL-AKA
The SEL-AKA assumes the existence of the following
assumptions:
• Each device has a permanent identity Subscription
Permanent Identifier (SUPI), which identifies the device and
should be installed by the supplier in order to allow it to
register in a 3GPP network.
The SUPI consists of routing information parameters such as MCC
(Mobile Country Code), MNC (Mobile Network Code) and MSIN
(Mobile Subscription Identification Number). The MSIN parameter
should be encrypted using the long-term secret key K.
• Each device has a pre-shared secret key (K) with the
UDM/ARPF.
• Each device has a parameter called Ref pre-shared with the
UDM/ARPF.
• Secure communication channel between the UDM/ARPF
and the SEAF has already been established and can offer
security services to the transmitted data.
• Access and Mobility Management (AMF) : It is responsible for
maintaining mobility, registration and reachability management. It
provides access authentication, access authorization, Security
Anchor Function support (SEAF) support and Security Context
Management Function (SCMF) support.
• Unified Data Management (UDM): It is responsible for
Authentication Credential Repository and Processing Function (ARPF)
support and subscription of data storage.
• Authentication Server Function (AUSF): It provides authentication
for various services and user equipment (UE).
The authors propose a Secure Efficient and Lightweight authentication and Key Agreement protocol SEL-AKA of 5G
cellular network taken into account the different limitations relieved in the 3GPP standardized 5G-AKA and without
relying on a Global Public Key Infrastructure.

3- A Secure Efficient and Lightweight authentication protocol for 5G cellular networks: SEL-AKA

Step 1:
UE→SEAF: Attach Request (MACUE, MUE)
The UE calculates its authentication message MUE= (SUCI //ref // rUE),
and generates its own MACUE=f1K (SUCI//Ref //rUE). Then, it sends its
MACUE and MUE to the SEAF.
Where SUCI is the concealed SUPI computed by the UE. Subsequently,
the Home network ARPF decrypts the encrypted part of SUCI by the
same pre-shared key K to obtain the SUPI.
Step 2:
SEAF→AUSF: Attach Request (MUE, MACUE, SN-name)
The SEAF shall include the Serving Network name (SN-name) in the
Authentication Data Request together with the MACUE and MUE.
Then, sends it to the AUSF for further verification.
Step 3:
AUSF→ UDM/ARPF: Authentication Data Request (MUE, MACUE, SN-
name)
Upon receiving “Authentication Data Request” message, the AUSF
compares the SN-name received with the expected network name in
order to check whether the requesting SEAF in the serving network is
authorized to use the SN-name in the Authentication Data Request. If
so, it stores the received SN-name temporarily.

Step 4:
UDM/ARPF→AUSF: Authentication Data Response (5G HE AV, [SUPI])
ARPF from the Ref parameter determine the correspondent shared
key and verifies MACUE.
MACARPF= f1K (IDARPF, rUE, RAND); AUTN= (RAND, MACARPF);
XRES*= f4 (IDSEAF, RAND, SUCI, K); Derives KAUSF; Sends 5G HE AV
(Home Environment Authentication Vector) = (RAND, AUTN, XRES*,
KAUSF) together with the SUPI to the AUSF in an Authentication Data
Response.
Step 5:
AUSF→SEAF: Authentication Request /Data Response (5G AV, [SUPI])
The AUSF stores XRES* temporarily until it expires and stores the
KAUSF. Generates 5G AV from 5G HE AV= (RAND, AUTN, HXRES*,
KSEAF); HXRES*= SHA256 (RAND, XRES*); KSEAF= KeySeed (K, RAND,
rUE, SN-name).
Step 6:
SEAF→UE: Authentication Request (RAND, AUTN, AUTHSEAF)
Upon receiving the message from the AUSF, SEAF computes MACSEAF
as follows MACSEAF= f2KSEAF (rSEAF, IDSEAF, RAND, MACARPF),
AUTHSEAF= (MACSEAF, rSEAF, IDSEAF) and transmits it together with
RAND, AUTN parameters to the UE.

Step 7:
UE→ SEAF: Authentication Data Response (RES*)
At receipt of the RAND, AUTN and AUTHSEAF, the UE will perform the following:
1) Verifies the freshness of 5G AV by checking AUTN and MACARPF. In case of
MACARPF and MACARPF matches, the UE authenticates the ARPF. Otherwise, the
UE sends a synchronisation failure or a MAC failure message.
2) The UE computes MAC’SEAF and compares it with MAC’SEAF. If equality holds,
the SEAF is validated by the UE. Otherwise, it rejects the authentication process.
3) Next, the USIM calculates a response value RES and returns RES, CK and IK to
the UE. This later compute RES* from RES and sends it to the SEAF for mutual
authentication of UE with SEAF in the Authentication Data Response.
Step 8:
SEAF→ AUSF: Authentication Data Request (RES*, [SUPI])
The SEAF must calculate HRES* from RES* as: HRES*= SHA256 (RAND, XES*) and
compares it with HXRES* received in the 5G AV. In case the values are equals,
the authentication has considered as successful. Thus, the SEAF authenticates
the UE, and sends the RES* in a message containing the SUPI and the SN name.
Step 9:
AUSF→ SEAF: Confirmation message (Result, [SUPI])
For mutual authentication with the UE, the SEAF receives RES* and verifies if
RES* matches with XRES*. If equality holds and AV does not expire. SEAF
transmits a successful authentication message to the SEAF in a confirmation
message contained the result and the SUPI. Thus, it considers the authentication
and key agreement to be successfully completed.
After successful authentication, the UE and the SEAF shares a KSEAF key as
essential material and an anchor key.

References
• Gharsallah, Ikram, Salima Smaoui, and Faouzi Zarai. "A Secure Efficient and Lightweight
authentication protocol for 5G cellular networks: SEL-AKA." In 2019 15th International Wireless
Communications & Mobile Computing Conference (IWCMC), pp. 1311-1316. IEEE, 2019.
26

Security Consideration in 5G

Recommended

Recommended

More Related Content

What's hot

What's hot (10)

Similar to Security Consideration in 5G

Similar to Security Consideration in 5G (20)

Recently uploaded

Recently uploaded (20)

Security Consideration in 5G