助理教授：吳俊興 助教：楊文健 國立高雄大學 資訊工程學系 教育部行動寬頻尖端技術人才培育計畫-小細胞基站聯盟中心 示範課程:行動與無線區網整合 Week #02 LTE AAA暨認證機制 助理教授：吳俊興 助教：楊文健 國立高雄大學 資訊工程學系

Outline introduction to AAA Intial Attach System Acquisition & RRC Connection Establishment Authentication The EPS AKA procedure NAS Security AS Security PDN Connectivity and IP Address Allocation

Introduction AAA stands for Authentication, Authorization and Accounting

AAA… for Authentication Authentication refers to the process of determining whether a user is an authorized subscriber to the network that he/she is trying to access Among various authentication procedures available in such networks, EPS AKA (Authentication and Key Agreement) procedure is used in LTE networks for mutual authentication between users and networks http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AAA… for Authorization Authorization refers to the process of adding or denying individual user access to a computer network and its resources Users may be given different authorization levels that limit their access to the network and associated resources Authorization determination may be based on geographical location restrictions, date or time-of-day restrictions, frequency of logins or multiple logins by single individuals or entities Other associated types of authorization service include route assignments, IP address filtering, bandwidth traffic management and encryption. https://www.techopedia.com/definition/24130/authentication-authorization-and-accounting-aaa

AAA… for Account Accounting refers to the record-keeping and tracking of user activities on a computer network For a given time period this may include, but is not limited to, real-time accounting of time spent accessing the network, the network services employed or accessed, capacity and trend analysis, network cost allocations, billing data, login data for user authentication and authorization, and the data or data amount accessed or transferred https://www.techopedia.com/definition/24130/authentication-authorization-and-accounting-aaa

LTE Security LTE network consists of various system elements connected using various interfaces The network elements are UE, eNB, MME, HSS and AuC. Following to be considered in order to provide LTE security Nodes should be able to exchange signalling data and user data securely In LTE networks is used EPS AKA (Authentication and Key Agreement) procedure for mutual authentication between users and networks http://www.rfwireless-world.com/Tutorials/LTE-security.html

User Connection UE connectivity is established in following steps: System acquisition & RRC connection establishment Intial Attach Authentication NAS security establishment AS security establishment PDN connectivity and IP address allocation Authentication, NAS/RRC security establishment creates security context for User's connection. We will discuss authentication in detail as it is main focus of this chapter https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

Intial Attach https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

System Acquisition & RRC Connection Establishment When a UE is powered on, it will scan its pre-programmed frequency list to find the strongest frequency Then it will go through the system acquisition procedure steps Which includes Downlink transmission synchronizing, once downlink synchronization is complete, the UE will be able to read downlink data from the cell Cell Selection, for cell selection the UE requires the PLMN ID of the network, cell barring status and minimum signal strength threshold from SIB type 1 Once cell selection is successful, the UE will read the information in SIB Type 2 to get the parameters it requires for beginning uplink synchronization After completing uplink synchronization will the UE be allowed to send anything else in the uplink, including the signaling required to create an RRC connection The first message from the UE is the RRC Connection Request. The UE will include in this message its UE identity (GUTI or IMSI) https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

RRC Connection The UE initiates the attach procedure with the completion of setting up the RRC connection The NAS Attach Request is piggybacked to the RRC message Also piggybacked on the RRC message is the NAS PDN Connectivity request which will also be passed to the MME for processing after the Attach The eNB, upon receiving the Attach Request will have to select an MME MME selection can be based upon several network operator definable criteria including: MME loading, LTE network topology, and which MME last served the UE In the Attach Request, the UE will identify itself by sending its IMSI or old GUTI https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

Overview of LTE Security Procedure http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

Authentication http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

Authentication As part of processing the initial Attach, the MME will have to perform authentication of the subscriber To initiate authentication, the MME will request authentication information from the HSS The HSS will send an authentication token (AUTN), an expected response (XRES) and the RAND it used to generate the XRES to the MME Then the MME has the necessary information for completing authentication with the SIM card in the UE https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

Authentication(Cont.) The MME sends an Authentication Request to the UE, including the RAND and the AUTN which it received from the HSS The SIM card in the UE will process the request, using the RAND it received and its pre-shared secret key to generate authentication parameters The SIM can use this to authenticate the requesting network prior to sending any response If the network is authenticated, the UE will send an Authentication Response back to the MME, including the Response (RES) If the RES the UE sends matches the XRES the MME got from the HSS, then the subscriber is authenticated and we can proceed to the next step which is establishing security https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

EPS Key Hierarchy 33.401 Figure 6.2-1: Key hierarchy in E-UTRAN The EPC and E-UTRAN shall allow for use of encryption and integrity protection algorithms for AS and NAS protection having keys of length 128 bits and for future use the network interfaces shall be prepared to support 256 bit keys

EPS Keys https://read01.com/zh-tw/Oy3LK4.html#.WaT7mD4jHIW

EPS Keys for NAS traffic KNASint : is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm This key is derived by ME and MME from KASME, as well as an identifier for the integrity algorithm using the KDF KNASenc : is a key, which shall only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by ME and MME from KASME, as well as an identifier for the encryption algorithm using the KDF 33.401 這一章的安全流程可以用於 UE 和 RNs 之間的溝通 也可以用於 UE 和 RNs 之間的溝通

EPS Keys for UP traffic KUPenc : is a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by ME and eNB from KeNB, as well as an identifier for the encryption algorithm using the KDF KUPint : is a key, which shall only be used for the protection of UP traffic between RN and DeNB with a particular integrity algorithm. This key is derived by RN and DeNB from KeNB, as well as an identifier for the integrity algorithm using the KDF 33.401 這一章的安全流程可以用於 UE 和 RNs 之間的溝通 也可以用於 UE 和 RNs 之間的溝通

EPS Keys for RRC traffic KRRCint : is a key, which shall only be used for the protection of RRC traffic with a particular integrity algorithm. KRRCint is derived by ME and eNB from KeNB, as well as an identifier for the integrity algorithm using the KDF KRRCenc : is a key, which shall only be used for the protection of RRC traffic with a particular encryption algorithm. KRRCenc is derived by ME and eNB from KeNB as well as an identifier for the encryption algorithm using the KDF 33.401 這一章的安全流程可以用於 UE 和 RNs 之間的溝通 也可以用於 UE 和 RNs 之間的溝通

Intermediate keys NH is a key derived by ME and MME to provide forward security KeNB* is a key derived by ME and eNB when performing an horizontal or vertical key derivation 33.401 這一章的安全流程可以用於 UE 和 RNs 之間的溝通 也可以用於 UE 和 RNs 之間的溝通

The EPS AKA procedure The EPS AKA procedure consists of two steps First, an HSS (Home Subscriber Server) generates EPS authentication vector(s) (RAND, AUTN, XRES, KASME) and delivers them to an MME Then in the second step, the MME selects one of the authentication vectors and uses it for mutual authentication with a UE and shares the same authentication key (KASME) each other Mutual authentication is the process in which a network and a user authenticate each other In LTE networks, since the ID of the user's serving network is required when generating authentication vectors, authentication of the network by the user is performed in addition to authentication of the user by the network http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AKA (UE → MME) Request by UE for Network Registration When a UE attempts to access the network for initial attach, it delivers Attach Request (IMSI, UE Network Capability, KSIASME=7) message to an MME. And this triggers EPS AKA procedure. The following information elements are included in the Attach Request message: IMSI: International Mobile Subscriber Identity, a unique identifier associated with the user UE Network Capability: security algorithms available to UE KSIASME=7: indicates UE has no authentication key http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AKA (UE → MME) (Cont.) UE network capability informs the MME of what kinds of capability the UE has related to EPS, and indicates which NAS and AS security algorithms, i.e., EPS Encryption Algorithms (EEA) and EPS Integrity Algorithms (EIA) are supported by the UE. Each of them has a value of 1 bit that is presented as on (supported) or off (not supported) (e.g. EEA0=on, EEA1=on, EEA2=off, …, EIA1=on, EIA2=on, …). Table 1 lists some of UE network capability information, specifically ciphering and integrity protection algorithms defined in [3] http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AKA (MME → HSS) Request by MME for Authentication Data The MME recognizing the UE has no KASME available initiates LTE authentication procedure to get new authentication data by sending an Authentication Information Request (IMSI, SN ID, n, Network Type) message to the HSS Message parameters used for this purpose are as follows: IMSI: a unique identifier associated with the user SN ID (Serving Network ID): refers to the network accessed by the user. Consists of PLMN ID (MCC+MNC). n (number of Authentication Vectors): No. of authentication vectors that MME requests Network Type: type of the network accessed by UE (E-UTRAN herein) http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AKA (MME → HSS) (Cont.) Upon receipt of the Authentication Information Request message from the MME, the HSS generates RAND and SQN, and creates XRES, AUTN, CK and IK using EPS AKA algorithm with LTE key (K), SQN and RAND Thereafter, using CK, IK, SQN and SN ID, it derives a top- level key (KASME) of the access network, from Key Derivation Function (KDF), to be delivered to the MME KDF is a one-way has function. Since SN ID is required when deriving KASME, KASME is derived again if the serving network is changed. After KASME is derived, the HSS forms authentication vectors AVi=(RANDi, AUTNi, XRESi, KASMEi), i=0..n. http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AKA (MME ← HSS) Response by HSS to the Authentication Data Request THe HSS forms as many AVs as requested by the MME and then delivers an Authentication Information Answer (AVs) message to the MME http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AKA (MME ← HSS) (Cont.) The MME stores the AVs received from the HSS, and selects one of them to use in LTE authentication of the UE In this example, the MME selected ith AV (AVi). KASME is a base key of MME and serves as a top-level key in the access network. It stays within EPC only and is not delivered to the UE through E-UTRAN, which is not secure The MME allocates KSIASME, an index for KASME, and delivers it instead of KASME to the UE so that the UE and the MME can use it as a substitute for KASME (In this example, KSIASME=1) http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AKA (UE ← MME) Request by MME for User Authentication The MME keeps KASMEi and XRESi in AVi but delivers KSIASMEi, in substitution for KASMEi, RANDi and AUTNi as included in the Authentication Request (KSIASMEi, RANDi, AUTNi) message to the UE. XRESi is used later in when authenticating the user http://www.netmanias.com/en/?m=view&id=techdocs&no=10621

AKA (UE ← MME) (Cont.) The UE, upon receiving the Authentication Request message from the MME, delivers RANDi and AUTNi to USIM USIM, using the same EPS AKA algorithm that the HSS used, derives RES, AUTNUE, CK and IK with the stored LTE key (K) and RANDi and SQN generated from the HSS5 The UE then compares AUTNUE generated using EPS AKA algorithm and AUTN received from MME (AUTNi) to authenticate the LTE network (the serving network) http://www.netmanias.com/en/?m=view&id=techdocs&no=10621

AKA (UE → MME) Response by UE to User Authentication Once the UE completes the network authentication, it delivers an Authentication Response (RES) including RES generated using EPS AKA algorithm to MME. If the network authentication using AUTN fails in , UE sends an Authentication Failure (CAUSE) message that contains a CAUSE field stating reasons for such failure http://www.netmanias.com/en/?m=view&id=techdocs&no=10621

AKA (UE → MME) (Cont.) When the MME receives the Authentication Response message from the UE, it compares RES generated by the UE and XRESi of the AV received from the HSS to authenticate the user USIM delivers CK and IK to the UE after its network authentication is completed The UE derives KASME using Key Derivation Function (KDF) with CK, IK, SQN and SN ID and stores it using KSIASME received from the MME as its index Thereafter, KSIASME is used instead of KASME during the NAS security setup between the UE and the MME http://www.netmanias.com/en/?m=view&id=techdocs&no=10621

Authentication and key agreement (AKA) LTE authentication is mutual authentication performed by and between a user and a network based on EPS AKA procedure An MME in the serving network performs mutual authentication with a UE on behalf of an HSS, and as a result, KASME is shared by the UE and the MME http://www.netmanias.com/en/?m=view&id=techdocs&no=10621

NAS Security NAS security, designed to securely deliver signaling messages between UEs and MMEs over radio links, performs integrity check (i.e., integrity protection/verification) and ciphering of NAS signaling messages Different keys are used for integrity check and for ciphering. While integrity check is a mandatory function, ciphering is an optional function NAS security keys, such as integrity key (KNASint) and ciphering key (KNASenc), are derived by UEs and MMEs from KASME http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

NAS security establishment

NAS security establishment Now that the subscriber has been authenticated and is allowed to use the LTE network, the MME will initiate establishment of security between the UE and the MME, and between the UE and the eNB The first step is to establish security for NAS signaling The MME will first select the NAS integrity and encryption algorithm to be used It will then convey this information to the UE in a NAS Security Mode Command message This message is integrity protected The selection of integrity and encryption algorithms is based on a prioritized list configured at the MME and the security capabilities of the UE http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

NAS security establishment(Cont.) The UE makes a note of the selected encryption and integrity algorithms and validates the integrity of the received message It then acknowledges the successful acceptance of the message by sending a Security Mode Complete message This message is both integrity protected and encrypted, and all future NAS signaling will be both integrity protected and encrypted. http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

NAS security establishment(Cont.) The integrity procedure starts at the MME with the transmission of the NAS Security Mode Command and encryption at the MME starts after receiving the Security Mode Complete message Integrity and encryption procedures start at the UE with the transmission of the NAS Security Mode Complete message http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AS Security AS security is purposed to ensure secure delivery of data between a UE and an eNB over radio links It conducts both integrity check and ciphering of RRC signaling messages in control plane, and only ciphering of IP packets in user plane Integrity check is mandatory, but ciphering is optional Different keys are used for integrity check/ciphering of RRC signaling messages and ciphering of IP packets http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AS security establishment http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AS security establishment Once NAS security is established, the MME will let the eNB know to establish a context for the UE This will cause the eNB to initiate establishment of Access Stratum (AS) security with the UE In this case, it is the eNB selecting the RRC integrity and encryption algorithm to be used in addition to the user plane (UP) encryption algorithms for user traffic The eNB will then convey this information to the UE in an RRC Security Mode Command This message is integrity protected http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AS security establishment(Cont.) The UE makes a note of the selected encryption and integrity algorithms and validates the integrity of the received message It then generates the keys required for these algorithms It acknowledges the successful acceptance of the message by sending an RRC Security Mode Complete message This message is integrity protected All subsequent RRC signaling will be integrity protected and both signaling and user traffic will be encrypted http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

AS Security Key AS security keys, such as KRRCint, KRRCenc and KUPenc, are derived from KeNB by a UE and an eNB KRRCint and KRRCenc are used for integrity check and ciphering of control plane data (i.e., RRC signaling messages) KUPenc is used for ciphering of user plane data (i.e., IP packets) Integrity check and ciphering are performed at the PDCP (Packet Data Convergence Protocol) layer A UE can derive KeNB from KASME. However, since KASME is not transferred to an eNB, an MME instead generates KeNB from KASME and forwards it to the eNB http://www.netmanias.com/en/?m=view&id=techdocs&no=10425

PDN Connectivity and IP Address Allocation https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

PDN Connectivity Request In addition to the Attach Request, the UE also requested access to data services Every UE in an LTE network will have at least one default connection established to a PDN When the RRC connection was setup, the UE had piggybacked two NAS messages The second of those messages, the PDN Connectivity Request, caused the MME to establish a default bearer for user traffic between the UE and a P-GW after authentication was completed https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

The IP address is delivered to the UE The MME used a default APN, specific to that UE, which it received from the HSS subscriber database to determine to which PDN we are connecting and selected the appropriate P-GW for that PDN Then the MME selected an S-GW and established the user traffic bearer in the EPC for the UE The complete bearer path was not completed until security was established on the Access Stratum As part of the bearer establishment in the EPC, the P-GW allocated an IP address for the UE The IP address is delivered to the UE in the NAS Activate Default EPS Bearer Context Request message https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

UE "always-on" connectivity to the PDN To acknowledge the completion of the Attach procedure and the establishment of the default EPS bearer, the UE sends 2 NAS messages to the MME: Attach Complete and Activate Default EPS Bearer Context Accept The default bearer connects from the UE to the P-GW and gives the UE "always-on" connectivity to the PDN https://github.com/sgurjar/lte-security-presentation/blob/master/lte-security.md

References