LTE Security Architecture

Key-Parameters-distribution-at-different-nodes-of-LTE

LTE security architecture defines the security mechanism for both NAS layer and AS layer. No HO related security is covered in this document.

LTE Security Distribution

Security distribution LTE Security Architecture

NAS security

  • Carried out for NAS messages and belongs to the scope of UE and MME.
  • In this case NAS message communication between UE and MME are Integrity protected and Ciphered with extra NAS security header.

AS security

  • Carried out for RRC and user plane data and belongs to the scope of UE and eNB.
  • PDCP layer in UE and eNB side is responsible for the ciphering and integrity protection.
  • RRC messages are integrity protected and ciphered but U-Plane data is only ciphered.

Different Security algorithms (integrity/ciphering)

Integrity

  • “0000″ EIA0 Null Integrity Protection algorithm
  • “0001″ 128-EIA1 SNOW 3G
  • “0010″ 128-EIA2 AES

Ciphering

  • “0000″ EEA0 Null ciphering algorithm
  • “0001″ 128-EEA1 SNOW 3G based algorithm
  • “0010″ 128-EEA2 AES based algorithm
Key Parameters distribution at different nodes of LTE LTE Security Architecture

 

Pre Shared Keys

  • UE Security Key – Configured in operator’s DB in Authentication center and USIM.
  • AMF - Configured in operator’s DB in Authentication center and USIM.
  • OP – This is optional and configured in operator’s DB in Authentication center and USIM.

Generated Keys

  • SQN – It is the 4 Octet sequence no which should be refreshed each time NW tries to re authenticate the UE. It is generated as below.
  • SQN1-n = SEQ1-n || IND1-n
    SEQ is the Prefix with value in the range of 27 bits (0-2^27) and IND is the index of 5 bits (0-31).
    If 0 If IND=0, generate SEQ using random rules (ex – modular addition)

    Ex- SQN is generated using modular addition

    SQN 1 =SEQ || IND
    SQN 2 =SEQ+ 1 || IND
    SQN 3 =SEQ+ 2 || IND
    SQN 4 =SEQ+ 3 || IND
    SQN 5 =SEQ+ 4 || IND

  • RAND – It is the random no generated through some random no generation algorithm.

Derived Authentication vectors

  • IK – Is the integrity key generated with input (K, RAND)->f4->IK. It is generated at authentication center and USIM.
  • CK – It is the ciphering key generated with input (K, RAND)->f3->CK. It is generated at authentication center and USIM.
  • AK – It is the anonymity key generated with input (K, RAND)->f5->AK. It is generated only at authentication center.
  • XRES – Expected response generated with input (K, RAND)->f2->XRES. It is generated only at authentication center. Corresponding parameter RES is generated at USIM.
  • MAC - Message authentication code generated with input (K, SQN, RAND, AMF)->f1->MAC. It is generated only at authentication center. Corresponding parameter XMAC is generated at USIM.
  • AUTN - authentication token generated with AUTN = SQN * AK || AMF || MAC. It is generated only at authentication center.

When MME receives Attach Request from an UE to get the initial access to the network, MME send the authentication data request to AuC/HSS. After derivation of RAND, XRES, CK, IK, AUTN Authentication center combines them in to authentication vector (AV = RAND || XRES || CK || IK || AUTN) and sends it to MME with authentication data response.

Vector Derivation at Network side LTE Security Architecture Vector Derivation at USIM side LTE Security Architecture

Derived Keys

These keys are derived using the key derivation function (KDF) = HMAC-SHA-256 (Key, S) where

Key = Input key
Input string S = FC || P0 || L0 || P1 || L1 || P2 || L2 || P3 || L3 ||… || Pn || Ln
FC= function code
P0 = parameter 0
L0 = length of parameter 0

  • KASME – To calculate KASME following steps are required.
  • Key = CK||IK
    S = FC(0×10) || SN Id || Length of SN id || SQN  AK || length of SQN  AK
    KASME = HMAC-SHA-256 (Key, S)

  • KeNB - To calculate KeNB following steps are required.
  • Key = KASME
    S = FC(0×11) || UL NAS Count || Length of UL NAS Count
    KeNB = HMAC-SHA-256 (Key, S)

  • Algorithm Key generation function – It covers the derivation of Knas-int, Knas-enc, Krrc-int, Krrc-enc, Kup-enc.
  • Key = KASME/Kenb (KASME is for Knas-int, Knas-enc and KeNB is for Krrc-int, Krrc-enc, Kup-enc)
    S = FC(0×15) || algorithm type distinguisher || length of algorithm type distinguisher || algorithm identity || length of algorithm identity
    Knas-int/Knas-enc/Krrc-int/Krrc-enc/Kup-enc = HMAC-SHA-256 (Key, S)

    Lte security table LTE Security Architecture

State diagram for Authentication and key generation

Security state diagram LTE Security Architecture

Note: The above diagram shows only the messages related to the security.

Step-1

  • Attach request from UE.
  • MME requests for the authentication vectors related to that particular IMSI by sending Authentication Data Request.
  • AuC/HSS fetches the Pre shred keys (PSK) against IMSI and calculates the authentication vectors from PSK.
  • AuC/HSS sends back the AV with Authentication Data Response.

Step-2

  • MME retrieves IK, CK, XRES, RAND and AUTN from AV
  • MME sends AUTN and RAND with Authentication Request to UE.

Step-3

  • UE authenticates the NW by checking AUTN received
  • Then calculates IK, CK, RES, XMAC from UE Security key, AMF, (OP), AUTN and RAND as described above.
  • It sends the RES along with Authentication response.

Step-4

  • After receiving RES MME compares it with XRES if it matches then authentication is successful else MME Sends the Authentication failure to UE.
  • MME will reset the DL NAS count
  • Calculate KASME, KeNB, Knas-int, Knas-enc as described above.
  • Sends NAS Security mode command (integrity algo, ciphering algo, NAS key set ID, UE Security capability) with integrity protected but not ciphered, using Knas-inc.

Step-5

  • After receiving NAS Security Mode Command UE will calculate KASME, KeNB, Knas-int, Knas-enc as described above.
  • UE will send the NAS Security mode complete with integrity protected and ciphered.

Step-6

  • After receiving NAS security mode command from UE, MME Sends the KeNB to eNB with S1AP Initial Context Setup Request (Security key)

Step-7

  • After getting keNB eNB will calculate Krrc-int, Krrc-enc, Kup-enc from that as described above.
  • Then it will send RRC Security mode Command with AS integrity algo and AS ciphering algo.

Step-8

  • After receiving RRC security mode command UE will calculate Krrc-int, Krrc-enc, Kup-enc as described above.
  • UE will send RRC security mode complete to eNB

After all the above steps All the NAS and AS messages will be integrity protected and ciphered except user data which will be only ciphered.

Further Studies

LTE Security is very well described in LTE Security book by Günther Horn, Dan Forsberg, Wolf-Dietrich Moeller and Valtteri Niemi. This is a handy book with all the details related to security aspects of LTE.

Post your questions and suggestions in the comments section below for a healthy discussion on LTE Security.

email

  • S.Kar

    I did not see any major changes in comparison to UTran security. It would be good to have a side by side comparison. Very nice article and helpful though. It refreshed my knowledge.

  • dhayanithi

    I think this Key Generation is based on UMTS but in LTE as part of authentication request some parameter is passed to HE which is in addition to IMSI. so the algorithm possibly will be different. for example the Ck and Ik are not supposed to be send in E-UTRAN type back as response.

    Please refer spec 33.401

    If the Network Type equals E-UTRAN then the “separation bit” in the AMF field of AUTN shall be set to 1 to indicate to the UE that the authentication vector is only usable for AKA in an EPS context, if the “separation bit” is set to 0, the vector is usable in a non-EPS context only (e.g. GSM, UMTS). For authentication vectors with the “separation bit” set to 1, the secret keys CK and IK generated during AKA shall never leave the HSS

    the AVP also specifies the same in diameter protocol

    Please clarify but still the way of organization of data is good

  • http://in.linkedin.com/pub/prasanna-sahu/29/257/91a Prasanna Sahu

    Hi Dhayanithi,
    This key generation is based on LTE only if you will see the flow. May be it is bit similar to UMTS. Let me clarify your points.
    LTE uses spec 3gpp 29.272 in S6a interface between MME and HSS, where as traditional Diameter follows the RFC 3588.
    1. when MME gets any attach request from UE it finds out the UE capability and based on that it makes sure that this UE supports E-UTRAN or UTRAN/GERAN and then MME generates Authentication Data/Information request (Diameter spec 3gpp 29272.940) from MME to HSS(HE) carries following parameters
    a. IMSI (as per rfc 3588 : User-name)
    b. Supported features (as per rfc 3588 : Supported-features)
    c. Requested E-UTRAN Authentication Info (included if UE Supports E-UTRAN)
    d. Requested UTRAN/GERAN Authentication Info(Included if UE Supports UTRAN/GERAN)
    e. Visited PLMN ID

    If parameter (c) is included then HSS will set the “seperation bit” to 1 and if (d) is included then HSS will set the “separation bit” to 0. now i think it is clear that how HE is distinguish between E-UTRAN or UTRAN based UEs.

    2. As per your CK, IK will never leave HSS during AKA. it is not correct, as described in the blog HSS will combine AUTN, IK, CK, RAND and will form AV and it will send this AV to MME with “Authentication Information answer.
    Structure of Authentication Information answer is as below
    a. Result (error code)
    b. Supported Features (o)
    c. Authentication Info(This IE shall contain the Authentication Vectors.)
    This means HSS will revert back to Auth information request with the generated AV.

    If you have any question or concerns please let me know so that we can discuss it here and clarify it :)

    Thanks for this valuable comment, It clarified one of my doubts regarding “separation bit”

  • raju

    OP seems mandatory [Section 8, 35205-a00.doc]

    #excerpt
    8.3 Analysis of the role of OP and OPc
    The 128-bit value OP is the Operator Variant Algorithm Configuration Field, which the Task Force was asked to include to provide separation between the functionality of the algorithms when used by different operators.

    It is left to each operator to select a value for OP.
    The algorithm set is designed to be secure whether or not OP is publicly known; however, operators may see some advantage in keeping their value of OP secret as a secret OP is one more hurdle in the attacker’s path.

    It should be difficult for someone who has discovered even a large number of (OPc, K) pairs to deduce OP. That means that the OPc associated with any other value of K will be unknown, which may make it (slightly) harder to mount some kinds of cryptanalytic and forgery attacks.
    It is more likely that OP can be kept secret if OP is not stored on the USIM, as it then only takes one USIM to be reverse engineered for OP to be discovered and published. Hence the task force recommends that OPc is calculated off USIM.

  • http://in.linkedin.com/pub/prasanna-sahu/29/257/91a Prasanna Sahu

    Hi Raju, Thanks for your comment. 35.205(For UMTS network but still used by LTE) is specifically for Milenage algorithm for authentication and key generation.
    LTE uses two types of algorithm for authentication and key generation
    1. Test :-For Test algorithm the OP is not required, so if current LTE operator is supporting Test algorithm for authentication and key generation then OP is not required and in this case USIM doesn’t contain OP.
    2. Milenage :-For milenage OP is mandatory. So if operator is using Milenage algorithm for authentication and key generation then OP need to be fabricated in USIM.

    That’s the reason May be I have written it optional, But I should have written it conditional instead of optional. If you have any concerns please let me know.

    Thanks and Regards
    Prasanna

  • dhayanithi

    Thanks for the clarification

    few more doubts:

    1) The error code is failure only in case if HSS is not able to retrieve the requested IMSI right. Is there any other failure sequence?

    2) In case MME and SGSN is combined then the AIR will contain both request for E-UTRAN and UTRAN/GERAN. so what is AMF in this case?

    3) what exactly these Supported Features IE contains?

    4) In the Key Generation Algo there is a parameter OP. Can you brief on it ? (no of bits, where exactly it is feed as input? )

    5) What is the signifiance of More AV’s Request from MME to HSS and HSS sending More AV’s?

    6) How the SQN is managed as there are three ways to handle it?

  • dhayanithi

    The SQN is actually 48 bit value (6 octet)

  • http://in.linkedin.com/pub/prasanna-sahu/29/257/91a Prasanna Sahu

    Hi Dayanithi,
    Please go through my comments below.
    1) The error code is failure only in case if HSS is not able to retrieve the requested IMSI right. Is there any other failure sequence?

    Ans>>If HSS will not get the information about IMSI it will generate Auth failure for sure, about further failure sequences I am also not clear. I have very less knowledge on S6a interface. If you want I can get help from my colleagues those who are working on that and let you know.

    2) In case MME and SGSN is combined then the AIR will contain both request for E-UTRAN and UTRAN/GERAN. so what is AMF in this case?
    ANS:-Simultaneously UE can’t Access UTRAN and E-Utran, It will depend on the UE capability, If the UE is only 3G based UE then it will communicate with NodeB–>RNC–>SGSN–for security–>HSS. and if the UE is dual mode(LTE/UTRAN) then it will depend on UE to select network based open the NW availability(if LTE NW is available then it will communicate with eNB–>MME–for security–>HSS). But simultaneously it is not possible for UE to register with MME and SGSN.

    3) what exactly these Supported Features IE contains?
    Ans: this is optional parameter in Diameter and I have limited knowledge on this as it is related to s6a interface.
    4) In the Key Generation Algo there is a parameter OP. Can you brief on it ? (no of bits, where exactly it is feed as input? )
    Ans:- I have given some idea on OP in one of my response below.
    5) What is the signifiance of More AV’s Request from MME to HSS and HSS sending More AV’s?
    Ans:-Again limited idea on this as it is related to S6a interface.
    6) How the SQN is managed as there are three ways to handle it?
    Ans:-I will get back to you on this.

  • Jitendra Sahu

    Step- 6 There seems to be a typo
    the sentence “After receiving NAS security mode command from UE” should read “After receiving NAS security mode command complete from UE”

  • http://www.youtube.com/user/FreeiPhoneSpot free ipad app of the day

    Howdy! Someone in my Myspace group shared this site with us so I came to look it over. I’m definitely loving the information. I’m bookmarking and will be tweeting this to my followers! Great blog and excellent style and design.

  • wpoon

    Hi anyone knows if there’s an free implementation of the SNOW 3G ciphering option (eea1)?

  • st0cktrader

    Hi, what would happen if UE does not include security mode complete in the NAS? It looks like the attach still completes.

  • sibananda

    its nice one

  • m

    Hi, you say the AMF is configured in the USIM but I can’t find that anywhere in the 3GPP specs on USIMs. Can you explain where the AMF is configured in the USIM?
    Thanks!

  • Pingback: My Homepage

  • Chandra Prakash

    Hi Prasanna,
    I am working in dvelopment of HSS in which we are using HMAC-RSA-256 algo as a part of the procedure to generate KASME key. Now my doubt is once generated this key, do we have any test set to verify whether the generated key is correct or not. Please help.

    Regards,
    Chandra Prakash

  • Pingback: туроператор по израилю

  • Pingback: туроператор по израилю

  • Pingback: http://www.youtube.com/watch?v=5mQA0A1PNaY

  • Pingback: Responsive Magento themes 2013

  • Pingback: fatcow reseller review

  • Pingback: http://answers.yahoo.com/question/index?qid=20130114023359AAgmE8v

  • Pingback: Top 2013 Jigoshop WordPress Themes

  • Pingback: Lawerence Winzer

  • Pingback: Shad Snellbaker

  • Pingback: Jordon Agudelo

  • Pingback: Marjory Staib

  • rajeev

    Dear ones,
    i am implimenting the integrity algorithm (128-eea2 aes) for PDCP protocol At UE side ,Do you know any links that provides good info about this ,any implimentation available…

  • prasanna

    Yes, You are right. AMF is not configured in USIM. It is configured in HSS and transfered to UE with AUTN.

  • Janardhan

    Hi,
    Does MME send Authentication Request (for re-authentication) with integrity protected only ?

    Thanks
    Janardhan.