Security In LTE Access Network

30,129 views
29,483 views

Published on

The Long Term Evolution (LTE) is the latest step in an advancing series of mobile telecommunications systems. In this paper, authors show interest on the security features and the cryptographic algorithms used to ensure confidentiality and integrity of the transmitted data. A closer look is taken upon EPS confidentiality and integrity algorithms. The authors also defined AKA, AS and NAS security and key derivations during normal Attach process and Handover also.

Published in: Technology, News & Politics
0 Comments
21 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
30,129
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
0
Comments
0
Likes
21
Embeds 0
No embeds

No notes for slide

Security In LTE Access Network

  1. 1. January 2014 Nisha Malik, Sukhvinder Malik, Preet Rekhi, Rahul Atri, Mandeep Arora Security in LTE Access Network 1. Introduction The Long Term Evolution (LTE) is the latest step in an advancing series of mobile telecommunications systems. In this paper, authors show interest on the security features and the cryptographic algorithms used to ensure confidentiality and integrity of the transmitted data. A closer look is taken upon EPS confidentiality and integrity algorithms. The authors also defined AKA, AS and NAS security and key derivations during normal Attach process and Handover also. Contents      MSIN and IMEI should be confidentially protected, IMEI should be send only after NAS security is activated. The UE shall provide its equipment identifier IMEI or IMEISV to the network, if the network asks for it in an integrity-protected request USIM is used instead of Normal GSM SIM When the UE has no IMSI, no valid GUTI, or no valid P-TMSI during emergency attach, the IMEI is included before the NAS security has been activated Introduction  Security Requirements of LTE system  3GPP Security Architecture  Confidentiality and Integrity mechanisms in LTE  2. Security Requirements of LTE System  EPS Algorithms  Security Procedures in LTESAE Network  Key Hierarchy in 4 G and Key Derivation  Key Derivation in During Handover  Conclusion  References .
  2. 2. Security requirements on eNodeB:  Security requirements on eNB are listed below and supported by the figure:  eNodeB setup and configuration related Communication between the remote/local O&M systems and the eNB shall be mutually authenticated. The eNB shall be able to ensure that software/data change attempts are authorized. Sensitive parts of the boot-up process shall be executed with the help of the secure environment. Confidentiality and Integrity protection of software transfer towards the eNB shall be ensured.  Requirements for key management inside eNB The EPS core network provides subscriber specific session keying material for the eNBs, which also hold long term keys, used for authentication and security association setup purposes. Protecting all these keys is important. Keys stored inside eNBs shall never leave a secure environment.  Requirements for handling User plane/Control plane data for the eNB It is eNB's task to cipher and decipher user/control plane packets between the Uu reference point and the S1/X2 reference points. User/control plane data ciphering/deciphering shall take place inside the secure environment where the related keys are stored. The transport of user data over S1-U/C and X2-U/C shall be integrity, confidentially and replay-protected from unauthorized parties.
  3. 3. 3. 3GPP Security Architecture As per 3GPP, five security feature groups are defined. Each of these feature groups meets certain threats and accomplishes certain security objectives: Network access security: The set of security features that provide users with secure access to services, and which in particular protect against attacks on the radio link. Primary radio link security features are like:  Encryption and Integrity Protection of RRC Signalling  Encryption and Integrity Protection of NAS Signalling  Encryption of Data Radio Bearer  Mutual Authentication between UE and Access Network User domain security: The set of security features that secure access to mobile Device and SIM. This security domain considers following security set:    User domain security requires IMSI and IEMI should be confidentially protected. User - USIM authentication: Access to the USIM is restricted until the USIM has authenticated the user with use of PIN. If user does not know PIN, user is not allowed to use SIM. USIM – Terminal authentication: Used only for SIM-Locked Mobiles. When a mobile device is SIM-locked, the device stores the IMSI of the USIM. If the inserted USIM has a different IMSI, the ME goes into a Emergency call only mode. .
  4. 4. - Application domain security: The set of security features that enable secure messaging between USIM and the Network. This USIM application toolkit provides capability for Operator to create applications which are resident on UE SIM - Visibility and configurability of security: The set of features that enables the user to inform himself whether a security feature is in operation or not and whether the use and provision of services should depend on the security feature.       - Indication of access network encryption Indication of the level of security Enabling/disabling user-USIM authentication Accepting/rejecting incoming non-ciphered calls Accepting/rejecting the use of certain ciphering algorithms Accepting/rejecting incoming non-ciphered calls Network domain security: The set of security features that enable nodes to securely exchange signaling data, user data (between Access Node and Signaling nodes and within Access Node), and protect against attacks on the wire line network. Network domain security mainly performs following:    Key negotiation using Internet Key Exchange (IKE) Use of Internet Security Association and Key Management Protocol (ISAKMP) for setting up the security association between the Security Gateways (SEG) Tunnel-mode Encapsulation Security Protocol (ESP) to be used for Encryption, data Integrity and Authentication.
  5. 5. 4. Confidentiality and Integrity mechanisms in LTE eNodeB layer and security Function: In eNB Physical, MAC and RLC Layers do not perform any security related operation. Only PDCP, RRC and NAS layer are involved: 3  PDCP layer is responsible for integrity protection of RRC and Confidentiality of RRC and User Plane (UP).  RRC has the role of AS (RRC and UP) key handling and security activation in PDCP  NAS performs key handling and integrity and confidentiality of NAS. Confidentiality and Integrity mechanisms in LTE  To ensure data security during its transmission over the air interface and through the LTE-SAE system: ciphering of both user plane data and control plane data in the RRC layer, and integrity protection which is used for control plane data only. For the NAS network, both ciphering and integrity are provided.  Ciphering is used in order to protect the data streams from being received by a third party, Ciphering may be provided to RRC-signaling to prevent UE tracking based on cell level measurement reports, handover message mapping, or cell level identity chaining. User and signaling data Confidentiality  To ensure the data confidentiality Cipher algorithm EEA (EPS Encryption Algorithm) agreement: To ensure the confidentiality of user and signaling data in LTE-SAE (Long Term Evolution - Service Architecture Evolution), 3GPP has maintained the use of the UMTS algorithm UEA2 based on SNOW 3G algorithm and has named it EEA1.  In addition, a new algorithm EEA2, based on AES algorithm used in the CTR mode (Counter Mode), has been adopted. Besides, the UE and the EPS can securely negotiate the algorithm to use in their mutual communication.  Cipher key agreement: the agreement is done between the UE and the network during the Authentication and Key Agreement procedure;  Encryption/Decryption of user and signaling data;
  6. 6. Signaling data Integrity Data integrity in the EPS network ensures the protection of the signaling data integrity and allows the authentication of the signaling messages transmitted between the user and the serving network. User data is not integrity protected. Integrity protection, and replay protection, shall be provided to all NAS and RRC-signaling messages. The following security features are provided to ensure the signaling data integrity on the LTE and SAE:  Integrity algorithm (EIA) agreement: as for the data confidentiality, there are actually two variants of the integrity algorithm for LTE: EIA1 based on SNOW 3G algorithms (named UIA2 in UMTS network). It was used since 2006 in the UMTS network and was maintained in the LTE-SAE network and the second algorithm EIA2, based on AES algorithm.  Integrity key (IK) agreement;  Data integrity feature: the receiving entity (ME or SN) must be able to check that the signaling data wasn't modified during its transition over the network access link and to check the expected origin of the message (SN (Serving Network) or UE). 5. EPS Algorithms There are nowadays two sets of security algorithms used in the Long Term Evolution network. The first set is based on the stream cipher algorithm SNOW 3G, which is inherited for UMTS, the 3rd generation of mobile telecommunication. The second set is based on the well-known block cipher algorithm AES. Each algorithm is identified by an identifier. EEA Algorithm Identification The EPS Encryption Algorithms (EEA) is algorithms work with internal 128-bit blocks under the control of a 128-bit input key except Null ciphering algorithm. To each EEA algorithm is assigned a 4-bit identifier. Currently, the following values have been defined for NAS, RRC and UP ciphering:  “00002”: EEA0 Null ciphering algorithm. The EEA0 algorithm is implemented in the way that it has the same effect as if it generates a key stream of all zeroes.  “00012”: 128-EEA1. The EEA1 is a stream cipher based on another stream cipher named SNOW 3G  “00102”: 128-EEA2. The EEA2 is a stream cipher based on the block cipher A.
  7. 7. 6. Security Procedures in LTE-SAE Network User Identity Confidentiality During network access, the serving Mobility Management Entity (MME) is required to allocate a Globally Unique Temporary Identity (GUTI) to the UE, which is used in the EPS to avoid frequent exchange of the UE's permanent identity (IMSI) over the radio access link. The GUTI consists of two components: a Globally Unique MME Identity (GUMMEI), which is the identity of the MME that has allocated the GUTI, and the M-TMSI, which is the identity of the UE within that MME. The GUMMEI in turn consists of PLMN ID (MCC, MNC) and MME Identifier (MME Group Id and MME Code).The MMEC provides a unique identity to an MME within the MME pool, while the MMEGI is used to distinguish between different MME pools. The SAE TMSI (S-TMSI) is a shortened form of the GUTI that is used to identify the UE over the radio path and is included in the RRC connection request and paging messages. The S-TMSI contains the MMEC and MTMSI components of the MMEI. However the S-TMSI does not include the MMEGI—that is, the MME pool component. Thus, because MME pool areas can overlap, care must be taken to ensure that MMEs serving the overlapping areas are not allocated the same MMECs. The International Mobile Equipment Identity (IMEI) is sent upon request from the network using NAS procedures. Authentication and Key Agreement EPS AKA is the authentication and key agreement procedure that is used between UE and EPC Core Network. EPS AKA produces keying material forming a basis for user plane (UP), RRC, and NAS ciphering keys as well as RRC and NAS integrity protection keys. Authentication Data Retrieval Authentication information is retrieved from the HSS over the S6a interface upon request by the MME. An authentication data request includes the IMSI, the serving network identity (MNC and MCC), the network type (EUTRAN), and the number of requested Authentication Vectors (AV) that the MME is prepared to receive.
  8. 8. UE Authentication Authentication of the UE is initiated by the serving MME through EPS NAS procedures. An EMM authentication request is sent to the UE with authentication parameters (RAND, AUTN) and the NAS Key Set Identifier (eKSI) or KSIASME. The KSIASME is allocated by the MME and uniquely identifies the KASME. It is stored in the UE and serving MME together with the GUTI, if one is available, allowing the KASME to be cached and re-used during subsequent connections without re-authentication. A new authentication procedure must include a different KSIASME. The UE responds to the MME with an authentication response, including the user response (RES) upon successful processing of the authentication challenge data. The MME then must validate the correctness of RES, and the intermediate KASME is determined after successful completion of the current EPS AKA, as agreed upon by the UE and MME. UE Identification The UE identification request is initiated by the serving MME using EPS NAS procedures. An EPS Mobility Management (EMM) identity request is sent to the UE requesting that the permanent identity—that is, the IMSI—be sent to the MME. This request is normally made when a GUTI is not available to provide a unique UE identification. The EMM identity request can also be used to retrieve the International Mobile Equipment (IMEI) as part of the Mobile Equipment (ME) identity check procedure, wherein the returned IMEI is passed on to the Equipment Identity Register (EIR) via the S13 interface for validation. .
  9. 9. EPS Security Context An EPS security context is created as the result of the EPS AKA and is uniquely identified by the evolved Key Set Identifier (eKSI) of Type KSIASME, allocated by the MME as part of the EPS AKA procedure. An EPS security context consists of AS and NAS components. The UE and MME each maintain up to two EPS security contexts simultaneously. For example, during a re-authentication procedure, both the current and new EPS security context exist during the period of transition. An EPS security context can be stored for future system accesses, termed a "cached security context." A UE transitioning from the EMMDEREGISTERED to EMM-REGISTERED state without an EPS security context typically requires the Extended Pedestrian A (EPA) AKA procedure to be run; however, the process is optional if cached security context is used. An EPS security context can be stored for future system accesses, termed a "cached security context." NAS Security The NAS security context in the EPS can be either set or re-established. The NAS security context is set using the NAS security mode control procedure, which is initiated by the MME towards the UE. This procedure can be used during the initial establishment of security context, subsequent re-authentications, or context modification. To initiate the procedure, an integrity-protected NAS security mode command message is sent with the EIA and key belonging to the security context to be activated while non-ciphered. The EEA, EIA and eKSI selected for the new security context are sent in the same message. The EEA and EIA selections are based on the UE’s security capabilities sent in initial UE context message. The system chooses the highest priority EEA and EIA supported by both The MME and the UE. During MME relocation, the NAS EEA and EIA may be updated, as source and target MMEs can have varying levels of support for security algorithms. The NAS security mode complete message is sent using ciphering and integrity protection with that of the security context to be activated. After the security procedures are exchanged, ciphering is applied on all NAS messages except the EMM attach request, tracking area update request, and security mode command until the NAS signaling connection is released and the MME is in the ECM-IDLE state. In transiting from the ECM-IDLE state to the ECM-CONNECTED state, the system always sends the NAS initial messages without ciphering but with integrity protection with the EPS cached security context, if one exists. If not, then the system sends the EPS AKA, NAS and AS Security Mode Control procedures to set the new EPS security context for the NAS and AS.
  10. 10. When an EPS cached security context is available, the UE sends the eKSI corresponding to the cached context, and the EPS AKA is optional. If the cached security context is to be activated, a new KeNB (eNB Key) is derived for this NAS Signalling connection at the MME and forwarded to the eNB over the S1-AP interface. AS security mode control procedures are used to inform the UE of the eKSI, indicating the current KASME in use. Security keys for the AS are derived accordingly at both the eNB and the UE. NAS security mode control procedures are not required in this case. The NAS security context loop is closed when the MME responds to the UE initiating message by sending the corresponding NAS procedure. This response is ciphered and integrity protected with that of the cached security context to be activated. An exception applies in the case of a TAU procedure in which the active flag is not set; that is, a signaling-only NAS connection is made that does not require establishment of DRBs and that releases resources as soon as the TAU procedure is completed. A NAS message is ciphered and transferred in the NAS message portion of a security protected NAS message. After ciphering, integrity protection is performed on the NAS message and sequence number, after which the Message Authentication Code (MAC) is computed and filled in. Integrity validation is performed prior to deciphering of the embedded NAS message. AS Security An EPS AS security context is initialized in the eNB by the MME when the UE enters the ECM- CONNECTED state and during the preparation for an intra-LTE handover. At this time the UE’s security capabilities and context, including the transitional security key material, is transferred from the source to the target eNB.
  11. 11. An RRC security command procedure is used during initial establishment of the AS security context and is initiated by the eNB towards the UE. The SRB1 is established at this time; that is, prior to the establishment of the Signalling Radio Bearer 2 (SRB2) and Data Radio Bearers (DRBs) for user plane transfer. An integrity-protected AS security mode command message is sent with the EIA and key belonging to the security context to be activated while nonciphered. The EEA, EIA and eKSI selected for the new security context are sent in the same message. The EEA and EIA selections are based on the security capabilities of the UE. They indicate the supported EEA and EIA and the locally configured, prioritized support lists in the eNB. The system chooses the highest priority EEA and EIA supported by both the eNB and the UE. The UE security capabilities list is provided by the MME in the S1-AP procedures during the initial UE context setup request or during the handover resource preparation phase for the S1- initiated intra-LTE handover. Such a list is also made available from the source eNB during preparation for an X2-initiated handover. Depending on the system, the EEA and EIA for the AS may be updated as part of the intra-LTE handover, as eNBs can have varying levels of support for security algorithms. Ciphering and deciphering at the AS in the downlink is started after the security mode command has been sent by the eNB and received at the UE; it is not necessary to wait for the security mode complete message. In the uplink, however, the security mode complete message must be sent by the UE and received at the eNB before ciphering and deciphering at the AS can start. The AS security mode complete message is sent ciphered and integrity- protected with that of the security context to be activated. An explicit start time for user plane ciphering is not required, since DRBs are always established after security mode procedures, and these DRBs share a common EEA with the SRBs. Keys may be updated through handovers and RRC connection re-establishments.
  12. 12. For DRB Packet Data Units (PDUs), ciphering at the Packet Data Control Plane (PDCP) is performed using post header compression, and deciphering is performed using pre header decompression. Ciphering and deciphering is performed on the data part of the SRB or DRB, and Message Authentication Code (MAC-I) for the SRB. PDCP control PDUs are not ciphered. Integrity protection and validation for the SRB is performed on the PDCP PDU header before ciphering on the data parts. 7. Key Hierarchy in 4G and Key Derivations The keys derived in the 4G AKA procedures are the following: K-NASenc (encryption key for NAS traffic), KNASint (integrity key for NAS traffic), KeNB (derived by MME and eNB), KUPenc (encryption key for the userplane data, derived by MME and eNB from KeNB), KRRCint and KRRCenc (integrity check, respectively encryption key derived by MME and eNB from KeNB, used for securing the Radio Resource Control traffic).
  13. 13. The sections in this figure describe which entities are involved in a particular key generation process; there are 6 keys derived from the EPS authentication mechanism. This key generation feature introduced in 4G improves the speed of the re-authentication procedures and also the refreshing process of the keys. As the K-ASME may be used a master key in further service requests authentication, the MME no longer has to download the authentication data from the HSS and it can also avoid re-synchronization issues. . The entire authentication information that is stored in the UICC and its corresponding associates from the network side is called “security context”; a security context consists of the NAS and AS security contexts. The AS security context has the cryptographic keys and chaining information for the next hop access key derivation, but the entire AS context exist only when the radio bearers established are cryptographically protected. The NAS context consists of the K-ASME with the associated key set identifier, the UE security capabilities and the uplink and downlink NAS count values, used for each EPS security context. For a security context to be considered full, the MME should have the K-NASenc and KNASint keys are derived as, K------>CK, IK----> KASME------>KNASint K------>CK, IK----> KASME------>KNASenc LTE RRC Key Derivation at the eNodeB and UE K------>CK, IK----> KASME------>KeNB----->KRRCint K------>CK, IK----> KASME-----> KeNB------>KRRCenc . LTE User Plane Key Derivation at the eNodeB and UE K------>CK, IK----> KASME-----> KeNB------> KUPenc
  14. 14. 8. Key Derivation During Handover In Handover to achieve the adequate security forward security mechanism is used. It means that, without knowledge of KASME, even with the knowledge of KeNB that is shared by the UE and the current eNB, computational complexity prevents guessing the future KeNBs which will be used between the UE and eNBs to which the UE will connect in the future. Thus, the encryption stays intact. The Model for Key transmission is shown in below figure during handover. When the initial AS security context is shared by UE and eNB, MME and UE must generate the KeNB and Next-Hop (NH) parameter. KeNB and NH are generated from KASME and there is a KeNB and NH for each NH chaining counters (NCC). Those respective KeNB are generated from the NH values for each NCC. In the Initial KeNB is generated by from KASME and NAS uplink Count, resulting NCC=0 key Chaining, with the initial values the derived NH values is for a key chain of NCC=1 or less. KeNB is used as base key for the secure communication between UE and eNB .For Handover directly between eNBs, KeNB*, the new key is generated from the active KeNB* or from the NH value. There are two methods for key derivation Horizontal key derivation And Vertical key derivation. The horizontal key derivation method generated KeNB* from the existing KeNB while the vertical key derivation method generate the KeNB* from NH. In Handovers, using vertical key derivation KeNB* is generated from NH with addition input like DL- EARFCN, and target eNB cell Physical cell Identity while in horizontal key derivation the KeNB* is generated from the current KeNB using the target PCI and its DL-EARFCN as additional parameters.
  15. 15. As NH can be calculated only by the UE and MME this use of the NH provides a method that achieves forward security in handover across the multiple eNBs. In that case the n-hop (where N can be 1 or 2) forward security at the time of vertical key derivation delivery means that the future KeNB to be used when UE connects to another eNB after n or more handovers cannot be guessed because of the computational complexity. This function can limit the scope of harm even if a Key is leaked, because feature Key will be generated without current KeNB in case of vertical key delivery 9. Conclusion This paper presented the basic 4G security architecture and requirements. The paper focused on the access-level security issues that may arise at the eNodeB, UE and MME level. As the connection to the network poses the most serious issues when talking about User Domain security, this paper analyzed the authentication process of the UE connecting to 4G networks. Authors explained about what all EPS algorithms are supported and how they can be identified. They also explained the NAS security, AS security and derivation of security key during normal attaché procedure and during the handovers.
  16. 16. Authors 10. References    Nisha Malik Student M.Tech      3 GPP 33.401 “3 GPP System Architecture Evolution, Security Architecture” 3GPP standard 36.300 , “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestriall” 3GPP 33.310, “Network Domain Security; Authentication Framework” 3GPP 33.220 ” Generic Authentication Architecture; Generic Bootstrapping, Authentication” 3GPP 33.102, “3G Security Architecture” LTE, The UMTS long Terms Evolution: From Theory to Practice Security Analysis of LTE Access Network Cristina-Elena Vintilă, Victor-Valeriu Patriciu, Ion Bica Computer Science Department LTE Security Encryption and Integrity Protection in LTE from Event Helix Sukhvinder Malik LTE Test Engineer Rahul Atri LTE Test Engineer Preet Rekhi LTE Test Engineer . Disclaimer: Authors state that this whitepaper has been compiled meticulously and to the best of their knowledge as of the date of publication. The information contained herein the white paper is for information purposes only and is intended only to transfer knowledge about the respective topic and not to earn any kind of profit. Mandeep Arora LTE Test Engineer Every effort has been made to ensure the information in this paper is accurate. Authors does not accept any responsibility or liability whatsoever for any error of fact, omission, interpretation or opinion that may be present, however it may have occurred

×