LTE SecurityPAPER

 Home
 3GPP
 LTE Security Architecture
LTE Security Architecture

Prasanna Sahu March 25, 2011 45
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
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
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
 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.
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(0x10) || 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(0x11) || 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(0x15) || 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)
State diagram for Authentication and key

generation
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.
Posted in 3GPP
45 COMMENTS
1. S.Kar
8 years ago Permalink
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.
2. 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
3. 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”
4. 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.
5. 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
6. 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?
7. dhayanithi
The SQN is actually 48 bit value (6 octet)
8. 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.
9. 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”
10. 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.
11. wpoon
Hi anyone knows if there’s an free implementation of the SNOW 3G

ciphering option (eea1)?
12. st0cktrader
Hi, what would happen if UE does not include security mode complete in
the NAS? It looks like the attach still completes.
13. sibananda
its nice one
14. 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!
15. 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
16. 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…
17. prasanna
Yes, You are right. AMF is not configured in USIM. It is configured in HSS
and transfered to UE with AUTN.
18. Janardhan
Hi,
Does MME send Authentication Request (for re-authentication) with
integrity protected only ?
Thanks
Janardhan.
19. jyothis chalissery

Kasme derivation:
as in 33.220, P0 is a static ASCII-encoded string.” For example if
P0=SNID=0x32F121. Would the P0 hex representation part of S look like
0x333246313231?
20. bhavana
Hi Can you please give a call flow for security when UE moves from 3G to
4G
21. Prashant Panigrahi

I will try to add some security call flow procedures for handover scenarios
22. Prathvi
Hi, I am getting Security Mode Reject Message with cause “UnSpecified”.

Can you please give me some idea on why it so?
Thank you for the blog, it was a big help to understand the LTE network.
23. Amit Sheps

Hi, when the MME will send an AIR to the HSS with UTRAN/GERAN will
be present, is there a way to enforce the HSS to send triplets for EAP-SIM
authentication?
Thanks
24. Elizabeth
Hi,I’m working on device to device communication of LTE. Please help me

to get the MATLAB code for the AKA procedure in LTE.
25. Margery
Absolute beauty. I spotted red/white specimen of similar wheels while back.

Back &qou;tthen&qout; they made thinks to last. And designs were more
beautifull than these days. Or maybe it's just me..? Getting old and
nostalgic.You have a great week!
26. ilham
Ik and Ck are used to generate Kasme only?

or they have other roles ?
27. dhayanithi
SNOW3G Source Code

/*————————————————————————
* SNOW_3G.c
*————————————————————————*/
#include “SNOW_3G.h”
/* LFSR */
u32 LFSR_S0 = 0x00;

u32 LFSR_S1 = 0x00;
u32 LFSR_S2 = 0x00;
u32 LFSR_S3 = 0x00;
u32 LFSR_S4 = 0x00;
u32 LFSR_S5 = 0x00;
u32 LFSR_S6 = 0x00;
u32 LFSR_S7 = 0x00;
u32 LFSR_S8 = 0x00;
u32 LFSR_S9 = 0x00;
u32 LFSR_S10 = 0x00;
u32 LFSR_S11 = 0x00;
u32 LFSR_S12 = 0x00;
u32 LFSR_S13 = 0x00;
u32 LFSR_S14 = 0x00;
u32 LFSR_S15 = 0x00;
/* FSM */
u32 FSM_R1 = 0x00;
u32 FSM_R2 = 0x00;
u32 FSM_R3 = 0x00;
/* Rijndael S-box SR */
u8 SR[256] = {
0x63,0x7C,0x77,0x7B,0xF2,0x6B,0x6F,0xC5,0x30,0x01,0x67,0x2B,0xFE,
0xD7,0xAB,0x76,
0xCA,0x82,0xC9,0x7D,0xFA,0x59,0x47,0xF0,0xAD,0xD4,0xA2,0xAF,0x9
C,0xA4,0x72,0xC0,
0xB7,0xFD,0x93,0x26,0x36,0x3F,0xF7,0xCC,0x34,0xA5,0xE5,0xF1,0x71,
0xD8,0x31,0x15,
0x04,0xC7,0x23,0xC3,0x18,0x96,0x05,0x9A,0x07,0x12,0x80,0xE2,0xEB,0
x27,0xB2,0x75,
0x09,0x83,0x2C,0x1A,0x1B,0x6E,0x5A,0xA0,0x52,0x3B,0xD6,0xB3,0x29
,0xE3,0x2F,0x84,
0x53,0xD1,0x00,0xED,0x20,0xFC,0xB1,0x5B,0x6A,0xCB,0xBE,0x39,0x4
A,0x4C,0x58,0xCF,
0xD0,0xEF,0xAA,0xFB,0x43,0x4D,0x33,0x85,0x45,0xF9,0x02,0x7F,0x50,
0x3C,0x9F,0xA8,
0x51,0xA3,0x40,0x8F,0x92,0x9D,0x38,0xF5,0xBC,0xB6,0xDA,0x21,0x10,
0xFF,0xF3,0xD2,
0xCD,0x0C,0x13,0xEC,0x5F,0x97,0x44,0x17,0xC4,0xA7,0x7E,0x3D,0x64
,0x5D,0x19,0x73,
0x60,0x81,0x4F,0xDC,0x22,0x2A,0x90,0x88,0x46,0xEE,0xB8,0x14,0xDE,
0x5E,0x0B,0xDB,
0xE0,0x32,0x3A,0x0A,0x49,0x06,0x24,0x5C,0xC2,0xD3,0xAC,0x62,0x91,
0x95,0xE4,0x79,
0xE7,0xC8,0x37,0x6D,0x8D,0xD5,0x4E,0xA9,0x6C,0x56,0xF4,0xEA,0x65
,0x7A,0xAE,0x08,
0xBA,0x78,0x25,0x2E,0x1C,0xA6,0xB4,0xC6,0xE8,0xDD,0x74,0x1F,0x4
B,0xBD,0x8B,0x8A,
0x70,0x3E,0xB5,0x66,0x48,0x03,0xF6,0x0E,0x61,0x35,0x57,0xB9,0x86,0
xC1,0x1D,0x9E,
0xE1,0xF8,0x98,0x11,0x69,0xD9,0x8E,0x94,0x9B,0x1E,0x87,0xE9,0xCE,
0x55,0x28,0xDF,
0x8C,0xA1,0x89,0x0D,0xBF,0xE6,0x42,0x68,0x41,0x99,0x2D,0x0F,0xB0,
0x54,0xBB,0x16
};
/* S-box SQ */
u8 SQ[256] = {
0x25,0x24,0x73,0x67,0xD7,0xAE,0x5C,0x30,0xA4,0xEE,0x6E,0xCB,0x7D
,0xB5,0x82,0xDB,
0xE4,0x8E,0x48,0x49,0x4F,0x5D,0x6A,0x78,0x70,0x88,0xE8,0x5F,0x5E,0
x84,0x65,0xE2,
0xD8,0xE9,0xCC,0xED,0x40,0x2F,0x11,0x28,0x57,0xD2,0xAC,0xE3,0x4
A,0x15,0x1B,0xB9,
0xB2,0x80,0x85,0xA6,0x2E,0x02,0x47,0x29,0x07,0x4B,0x0E,0xC1,0x51,0
xAA,0x89,0xD4,
0xCA,0x01,0x46,0xB3,0xEF,0xDD,0x44,0x7B,0xC2,0x7F,0xBE,0xC3,0x9
F,0x20,0x4C,0x64,
0x83,0xA2,0x68,0x42,0x13,0xB4,0x41,0xCD,0xBA,0xC6,0xBB,0x6D,0x4
D,0x71,0x21,0xF4,
0x8D,0xB0,0xE5,0x93,0xFE,0x8F,0xE6,0xCF,0x43,0x45,0x31,0x22,0x37,0
x36,0x96,0xFA,
0xBC,0x0F,0x08,0x52,0x1D,0x55,0x1A,0xC5,0x4E,0x23,0x69,0x7A,0x92,
0xFF,0x5B,0x5A,
0xEB,0x9A,0x1C,0xA9,0xD1,0x7E,0x0D,0xFC,0x50,0x8A,0xB6,0x62,0xF
5,0x0A,0xF8,0xDC,
0x03,0x3C,0x0C,0x39,0xF1,0xB8,0xF3,0x3D,0xF2,0xD5,0x97,0x66,0x81,
0x32,0xA0,0x00,
0x06,0xCE,0xF6,0xEA,0xB7,0x17,0xF7,0x8C,0x79,0xD6,0xA7,0xBF,0x8
B,0x3F,0x1F,0x53,
0x63,0x75,0x35,0x2C,0x60,0xFD,0x27,0xD3,0x94,0xA5,0x7C,0xA1,0x05,
0x58,0x2D,0xBD,
0xD9,0xC7,0xAF,0x6B,0x54,0x0B,0xE0,0x38,0x04,0xC8,0x9D,0xE7,0x14
,0xB1,0x87,0x9C,
0xDF,0x6F,0xF9,0xDA,0x2A,0xC4,0x59,0x16,0x74,0x91,0xAB,0x26,0x61
,0x76,0x34,0x2B,
0xAD,0x99,0xFB,0x72,0xEC,0x33,0x12,0xDE,0x98,0x3B,0xC0,0x9B,0x3
E,0x18,0x10,0x3A,
0x56,0xE1,0x77,0xC9,0x1E,0x9E,0x95,0xA3,0x90,0x19,0xA8,0x6C,0x09,
0xD0,0xF0,0x86
};
/* MULx.*/
u8 MULx(u8 V, u8 c)
{
if ( V & 0x80 )
return ( (V << 1) ^ c);
else
return ( V << 1);
}
/* MULxPOW*/
u8 MULxPOW(u8 V, u8 i, u8 c)
{
if ( i == 0)
return V;
else
return MULx( MULxPOW( V, i-1, c ), c);
}
/* The function MUL alpha*/
u32 MULalpha(u8 c)
{
return ( ( ((u32)MULxPOW(c, 23, 0xa9)) << 24 ) |
( ((u32)MULxPOW(c, 245, 0xa9)) << 16 ) |
( ((u32)MULxPOW(c, 48, 0xa9)) << 8 ) |
( ((u32)MULxPOW(c, 239, 0xa9)) ) ) ;
}
/* The function DIV alpha*/
u32 DIValpha(u8 c)
{
return ( ( ((u32)MULxPOW(c, 16, 0xa9)) << 24 ) |
( ((u32)MULxPOW(c, 39, 0xa9)) << 16 ) |
( ((u32)MULxPOW(c, 6, 0xa9)) <> 24) & 0xff) ];
u8 srw1 = SR[ (u8)((w >> 16) & 0xff) ];
u8 srw2 = SR[ (u8)((w >> 8) & 0xff) ];
u8 srw3 = SR[ (u8)((w) & 0xff) ];
r0 = ( ( MULx( srw0 , 0x1b) ) ^
( srw1 ) ^
( srw2 ) ^
( (MULx( srw3, 0x1b)) ^ srw3 )
);
r1 = ( ( ( MULx( srw0 , 0x1b) ) ^ srw0 ) ^
( MULx(srw1, 0x1b) ) ^
( srw2 ) ^
( srw3 )
);
r2 = ( ( srw0 ) ^
( ( MULx( srw1 , 0x1b) ) ^ srw1 ) ^
( MULx(srw2, 0x1b) ) ^
( srw3 )
);
r3 = ( ( srw0 ) ^
( srw1 ) ^
( ( MULx( srw2 , 0x1b) ) ^ srw2 ) ^
( MULx( srw3, 0x1b) )
);
return ( ( ((u32)r0) << 24 ) | ( ((u32)r1) << 16 ) | ( ((u32)r2) <> 24) & 0xff)
];
u8 sqw1 = SQ[ (u8)((w >> 16) & 0xff) ];
u8 sqw2 = SQ[ (u8)((w >> 8) & 0xff) ];
u8 sqw3 = SQ[ (u8)((w) & 0xff) ];
r0 = ( ( MULx( sqw0 , 0x69) ) ^
( sqw1 ) ^
( sqw2 ) ^
( (MULx( sqw3, 0x69)) ^ sqw3 )
);
r1 = ( ( ( MULx( sqw0 , 0x69) ) ^ sqw0 ) ^
( MULx(sqw1, 0x69) ) ^
( sqw2 ) ^
( sqw3 )
);
r2 = ( ( sqw0 ) ^
( ( MULx( sqw1 , 0x69) ) ^ sqw1 ) ^
( MULx(sqw2, 0x69) ) ^
( sqw3 )
);
r3 = ( ( sqw0 ) ^
( sqw1 ) ^
( ( MULx( sqw2 , 0x69) ) ^ sqw2 ) ^
( MULx( sqw3, 0x69) )
);
return ( ( ((u32)r0) << 24 ) | ( ((u32)r1) << 16 ) | ( ((u32)r2) << 8 ) |
( ((u32)r3) ) );
}
/* Clocking LFSR in initialization mode*/
void ClockLFSRInitializationMode(u32 F)
{
u32 v = ( ( (LFSR_S0 <>24) & 0xff) ) ) ^
( LFSR_S2 ) ^
( (LFSR_S11 >> 8) & 0x00ffffff ) ^
( DIValpha( (u8)( ( LFSR_S11) & 0xff ) ) ) ^
(F)
);
LFSR_S0 = LFSR_S1;
LFSR_S1 = LFSR_S2;
LFSR_S2 = LFSR_S3;
LFSR_S3 = LFSR_S4;
LFSR_S4 = LFSR_S5;
LFSR_S5 = LFSR_S6;
LFSR_S6 = LFSR_S7;
LFSR_S7 = LFSR_S8;
LFSR_S8 = LFSR_S9;
LFSR_S9 = LFSR_S10;
LFSR_S10 = LFSR_S11;
LFSR_S15 = v;
}
/* Clocking LFSR in keystream mode*/
void ClockLFSRKeyStreamMode()
{
u32 v = ( ( (LFSR_S0 <>24) & 0xff) ) ) ^
( LFSR_S2 ) ^
( (LFSR_S11 >> 8) & 0x00ffffff ) ^
( DIValpha( (u8)( ( LFSR_S11) & 0xff ) ) )
);
LFSR_S0 = LFSR_S1;
LFSR_S1 = LFSR_S2;
LFSR_S2 = LFSR_S3;
LFSR_S3 = LFSR_S4;
LFSR_S4 = LFSR_S5;
LFSR_S5 = LFSR_S6;
LFSR_S6 = LFSR_S7;
LFSR_S7 = LFSR_S8;
LFSR_S8 = LFSR_S9;
LFSR_S9 = LFSR_S10;
LFSR_S15 = v;
}
/* Clocking FSM*/
u32 ClockFSM()
{
u32 F = ( ( LFSR_S15 + FSM_R1 ) & 0xffffffff ) ^ FSM_R2 ;
u32 r = ( FSM_R2 + ( FSM_R3 ^ LFSR_S5 ) ) & 0xffffffff ;
FSM_R3 = S2(FSM_R2);
FSM_R2 = S1(FSM_R1);
FSM_R1 = r;
return F;
}
/* Initialization*/
void Initialize(u32 k[4], u32 IV[4])
{
u8 i=0;
u32 F = 0x0;
LFSR_S15 = k[3] ^ IV[0];
LFSR_S14 = k[2];
LFSR_S13 = k[1];
LFSR_S12 = k[0] ^ IV[1];
LFSR_S11 = k[3] ^ 0xffffffff;
LFSR_S10 = k[2] ^ 0xffffffff ^ IV[2];
LFSR_S9 = k[1] ^ 0xffffffff ^ IV[3];
LFSR_S7 = k[3];
LFSR_S6 = k[2];
LFSR_S5 = k[1];
LFSR_S4 = k[0];
FSM_R1 = 0x0;
FSM_R2 = 0x0;
FSM_R3 = 0x0;
for(i=0;i<32;i++)
{
F = ClockFSM();
ClockLFSRInitializationMode(F);
}
}
/* Generation of Keystream*/
void GenerateKeystream(u32 n, u32 *ks)

{
u32 t = 0;
u32 F = 0x0;
ClockFSM(); /* Clock FSM once. Discard the output. */
ClockLFSRKeyStreamMode(); /* Clock LFSR in keystream mode once. */
for ( t=0; t<n; t++)
{
F = ClockFSM(); /* STEP 1 */
ks[t] = F ^ LFSR_S0; /* STEP 2 */
/* Note that ks[t] corresponds to z_{t+1} in section 4.2
*/
ClockLFSRKeyStreamMode(); /* STEP 3 */
}
}
/*———————————————————————–
* end of SNOW_3G.c
*———————————————————————–*/
/*———————————————————
* f8.c
*———————————————————*/
/*
#include "f8.h"
#include
#include
#include
*/
/* f8*/
void f8(u8 *key, u32 count, u32 bearer, u32 dir, u8 *data, u32 length)
{
u32 K[4],IV[4];
int n = ( length + 31 ) / 32;
int i=0;
int lastbits = (8-(length%8)) % 8;
u32 *KS;
/*Initialisation*/
/* Load the confidentiality key for SNOW 3G initialization as in section
3.4. */
for (i=0; i<4; i++)
K[3-i] = (key[4*i] << 24) ^ (key[4*i+1] << 16)
^ (key[4*i+2] << 8) ^ (key[4*i+3]);
/* Prepare the initialization vector (IV) for SNOW 3G initialization as in

section 3.4. */
IV[3] = count;
IV[2] = (bearer << 27) | ((dir & 0x1) << 26);
IV[1] = IV[3];
IV[0] = IV[2];
/* Run SNOW 3G algorithm to generate sequence of key stream bits KS*/

Initialize(K,IV);
KS = (u32 *)malloc(4*n);
GenerateKeystream(n,(u32*)KS);
/* Exclusive-OR the input data with keystream to generate the output bit
stream */
for (i=0; i> 24) & 0xff;
data[4*i+1] ^= (u8) (KS[i] >> 16) & 0xff;
data[4*i+2] ^= (u8) (KS[i] >> 8) & 0xff;
data[4*i+3] ^= (u8) (KS[i] ) & 0xff;
}
free(KS);
/* zero last bits of data in case its length is not byte-aligned

this is an addition to the C reference code, which did not handle it */
if (lastbits)
data[length/8] &= 256 – (1<<lastbits);
}
/* End of f8.c */
/*———————————————————
* f9.c
*———————————————————*/
/* MUL64x */
u64 MUL64x(u64 V, u64 c)
{
if ( V & 0x8000000000000000 )
return (V << 1) ^ c;
else
return V << 1;
}
/* MUL64xPOW */
u64 MUL64xPOW(u64 V, u8 i, u64 c)
{
if ( i == 0)
return V;
else
return MUL64x( MUL64xPOW(V,i-1,c) , c);
}
/* MUL64 */
u64 MUL64(u64 V, u64 P, u64 c)
{
u64 result = 0;
int i = 0;
for ( i=0; i>i ) & 0x1 )

result ^= MUL64xPOW(V,i,c);
}
return result;
}
/* mask8bit */
u8 mask8bit(int n)
{
return 0xFF ^ ((1<<(8-n)) – 1);
}
/* f9 */
u8* f9( u8* key, u32 count, u32 fresh, u32 dir, u8 *data, u64 length)
{
u32 K[4],IV[4], z[5];
u32 i=0, D;
static u8 MAC_I[4] = {0,0,0,0}; /* static memory for the result */
u64 EVAL;
u64 V;
u64 P;
u64 Q;
u64 c;
u64 M_D_2;
int rem_bits = 0;
/* Load the Integrity Key for SNOW3G initialization as in section 4.4. */

for (i=0; i<4; i++)
K[3-i] = (key[4*i] << 24) ^ (key[4*i+1] << 16) ^
(key[4*i+2] << 8) ^ (key[4*i+3]);
/* Prepare the Initialization Vector (IV) for SNOW3G initialization as

in section 4.4. */
IV[3] = count;
IV[2] = fresh;
IV[1] = count ^ ( dir << 31 ) ;
IV[0] = fresh ^ (dir << 15);
z[0] = z[1] = z[2] = z[3] = z[4] = 0;
/* Run SNOW 3G to produce 5 keystream words z_1, z_2, z_3, z_4 and z_5.
*/
Initialize(K, IV);
GenerateKeystream(5, z);
P = (u64)z[0] << 32 | (u64)z[1];

Q = (u64)z[2] <>6) + 1;
else
D = (length>>6) + 2;
EVAL = 0;
c = 0x1b;
/* for 0 <= i <= D-3 */

for (i=0; i<D-2; i++)
{
V = EVAL ^ ( (u64)data[8*i ]<<56 | (u64)data[8*i+1]<<48 |
(u64)data[8*i+2]<<40 | (u64)data[8*i+3]<<32 |
(u64)data[8*i+4]<<24 | (u64)data[8*i+5]<<16 |
(u64)data[8*i+6]< 7)
{
M_D_2 |= (u64)data[8*(D-2)+i] < 0)
M_D_2 |= (u64)(data[8*(D-2)+i] & mask8bit(rem_bits)) << (8*(7-i));
V = EVAL ^ M_D_2;
EVAL = MUL64(V,P,c);
/* for D-1 */
EVAL ^= length;
/* Multiply by Q */
EVAL = MUL64(EVAL,Q,c);
/* XOR with z_5: this is a modification to the reference C code,

which forgot to XOR z[5] */
for (i=0; i> (8*(3-i))) & 0xff;
*/
MAC_I[i] = ((EVAL >> (56-(i*8))) ^ (z[4] >> (24-(i*8)))) & 0xff;
return MAC_I;
}
/*———————————————————
* SNOW_3G.h
*———————————————————*/
#include
#include
#include
typedef unsigned char u8;
typedef unsigned int u32;
typedef unsigned long long u64;
/* Initialization*/
void Initialize(u32 k[4], u32 IV[4]);
/* Generation of Keystream*/
void GenerateKeystream(u32 n, u32 *z);
/* f8*/
void f8( u8 *key, u32 count, u32 bearer, u32 dir, \
u8 *data, u32 length );
/* f9*/
u8* f9( u8* key, u32 count, u32 fresh, u32 dir, \
u8 *data, u64 length);
28. santosh
PLEASE IF ANYONE HAVING THE IMPLEMENTATION CODE,

PLEASE DO MAIL ME…
29. dom
Hi everyone,
I am doing a project and would like to find out the following.
Is it possible to write my own protocol on a USIM card and authenticate

with OpenBTS-UMTS for example?
Is it possible to add my own modification to the Milenage algorithm for 3G
and authenticate with OpenBTS_UMTS?
If yes, any advice on how to them will be much appreciated.
cheers,
30. free anonymous proxies

Hi,I check your new stuff named “LTE Security Architecture | 3GLTEInfo”
like every week.Your writing style is awesome, keep up the good work! And
you can look our website about free anonymous proxies.
31. prasanna sahu

Hi Dom,
Yes, you can use your proprietary algorithm instead of Milanage. but in this
case you have to make sure both USIM and HSS are running your
authentication algorithm. As authentication is happening between USIM and
HSS, OpenBTS_UMTS framework will affect the process. you proprietary
algorithm should work.
if you are modifying Millanage for your use then you have to do it in USIM
and HSS both. then only it will work.
Thanks
Prasanna Sahu
32. dom
Thanks Prasanna for your feedback.

Any advice or book that can show me how to load this program on the
USIM.
Do I have to erase the authentication protocol on the card before loading

mine?
Is it possible to modify milenage program on the USIM and add my
modification and save directly?
how do I tell the phone for example to use my protocol?
Any site that can make all this clear would be helpful.
33. Veerendra
Hi, I am getting Security Mode Reject message with cause “UnSpecified”.

Can any one please give me some idea on why it so?
Thanks,
veerendra
34. prasanna sahu

Hi Veerendra,
In Your case you haven’t specified NAS or RRC security Mode Reject. I
guess it might be NAS Security mode reject from UE to eNB!!!
I presume, Authentication procedure before security procedure is successful.
In this case there might be 2 causes for Reject.
1. selected Encryption and Integrity algorithm is not matching with UE
supported capability.
2. KSI in auth request is not matching with Security Mode Command.
Thanks
Prasanna
35. prasanna sahu

Hi Dom,
Sorry I missed your last comment, so late in responding to your question.
Yes you can write your algorithm to the USIM card. but most of the SIM
cards available in market from Operators is locked and write protected. You
can buy a new blank SIM card from http://www.gemalto.com/. and use their
SW to write your algorithm, UE Key, OP, AMF… Etc.
Thanks
Prasanna
36. Veerendra
Hi Prasanna,
Thanks for reply.The two cases you mentioned:

1. If UE security capabilties are not matched, there is a reject with UE
security capabilities mismatch.
2. KSI in both auth request and security mode command are same.
I have one doubt if KNAS-integrity key generated by MME is not matching
with UE KNAS-integrity, this may be the issue.
Thanks,
Veerendra.
37. prasanna sahu

Hi Veerendra,
Again the things comes down to root cause mentioned in point no-1, if both
UE and MME are using same integrity algorithm, and MME intimates UE,
which algorithm to use (In Security mode command) then there is no way
KNAS-Int with mismatch between MME and UE, conditions is
Authentication procedure happened between MME and UE successfully(is
Authentication procedure successful for you?).
Thanks
Prasanna
38. Veerendra
Hi Prasanna,
Authentication procedure is successful. What i think is KNAS-int generated

by MME is not matching with the KNAS-int of UE, at that time also the
Security Mode Reject cause sent to MME. Can i have algorithm details for
generating kNAS-int.
Thanks,
Veerendra.
39. prasanna sahu
Hi Veerendra,
After Auth is successful, What is the Integrity Algo you are receiving from
NW in Security mode command ?
selectedNasSecurityAlgorithm {
integrityAlgorithm epsIntegrityAlgorithm-EIA0,
cipheringAlgorithm epsCipheringAlgorithm-EEA0
If you are receiving EIA1 for integrity algo then it is Snow3G algorithm
reference is as below.
This algorithm is used to generate all keys(KASME, KNAS-Int, KNAS-enc,

KeNB, KeNB-UP etc), only difference will be input parameters used for this
algorithm. You can find all the input parameters above in the blog for each
key calculation.
one more thing MME never sends KNAS-int to UE or UE never compares.
Only thing is compared during Security mode procedure is, MAC generated
using KNAS-int at MME side, sent over to UE in security mode command.
if both the side will be using different algorithms, then this MAC will not
match, and this could lead to your problem.
Below Snow3G algo–>EIA1 algorithm

http://www.3glteinfo.com/lte-security-architecture/#comment-20814
Thanks
40. vamse
Hi, I am getting in NAS Security Mode Reject message with cause
“UnSpecified”. Can any one please give me some idea on why it so?
41. vamse
Hi Prasanna,
I am getting in NAS Security Mode Reject message with cause

“UnSpecified”.
Here i am using EIA2 for integrity algorithm. Can any one please give me
some idea on why it so?
Thanks
Vamse
42. Satish Sharma

Is there any tool by which SQN UE can be calculated using the AUTS value
received in the Resync Info in AIR request from MME ? This is regarding
the Re synchronisation Process between UE and HSS.
43. Rakesh
11 months ago Permalink
HI Prasanna
Why we are using two security mode commands in LTE and only one
security command in UMTS
Thanks
Rakesh
44. MD TAUFEEQ AHMED

9 months ago Permalink
This is in LTE case.
Can anyone tell me how the UE security key or long term key or permanent
secret key “K” generated ?
based on K, other keys are generated but where is this K generated?
what I know about this is , it is denoted by 128 bits, and stored in USIM and
AuC. but how it is generated and where it is generated is not known to me.
Kindly let me know if you have any answer for this.
45. Ranjith Kumar

4 days ago Permalink
Thanks for the info. nicely organised. very useful.
LEAVE A REPLY
Your email address will not be published. Required fields are marked *
Comment
Name *
Email *
Website
Save my name, email, and website in this browser for the next time I comment.
Post Comment
Previous Post: Global System for Mobile Communication (GSM)

Next Post: Tricks to Read and Understand 3GPP Specifications

LTE SecurityPAPER

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LTE SecurityPAPER

Uploaded by

Copyright:

Available Formats

 Home

LTE Security Architecture

LTE Security Distribution

 “0000” EIA0 Null Integrity Protection algorithm

 “0000” EEA0 Null ciphering algorithm

Pre Shared Keys

 SQN – It is the 4 Octet sequence no which should be refreshed each time

SQN1-n = SEQ1-n || IND1-n

Ex- SQN is generated using modular addition

SQN 1 =SEQ || IND

 RAND – It is the random no generated through some random no generation

Derived Authentication vectors

 IK – Is the integrity key generated with input (K, RAND)->f4->IK. It is

Key = Input key

 KASME – To calculate KASME following steps are required.

 KeNB – To calculate KeNB following steps are required.

 Algorithm Key generation function – It covers the derivation of Knas-int,

Key = KASME/Kenb (KASME is for Knas-int, Knas-enc and KeNB

State diagram for Authentication and key

 Attach request from UE.

 MME retrieves IK, CK, XRES, RAND and AUTN from AV

 UE authenticates the NW by checking AUTN received

 After receiving RES MME compares it with XRES if it matches then

 After receiving NAS Security Mode Command UE will calculate KASME,

I think this Key Generation is based on UMTS but in LTE as part of

Please refer spec 33.401

the AVP also specifies the same in diameter protocol

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

Thanks for this valuable comment, It clarified one of my doubts regarding

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

It is left to each operator to select a value for OP.

Thanks and Regards

Thanks for the clarification

few more doubts:

3) what exactly these Supported Features IE contains?

The SQN is actually 48 bit value (6 octet)

3) what exactly these Supported Features IE contains?

Step- 6 There seems to be a typo

10. free ipad app of the day

Howdy! Someone in my Myspace group shared this site with us so I came to

Hi anyone knows if there’s an free implementation of the SNOW 3G

15. Chandra Prakash

19. jyothis chalissery

21. Prashant Panigrahi

Hi, I am getting Security Mode Reject Message with cause “UnSpecified”.

23. Amit Sheps

Hi,I’m working on device to device communication of LTE. Please help me

Absolute beauty. I spotted red/white specimen of similar wheels while back.

Ik and Ck are used to generate Kasme only?

SNOW3G Source Code

u32 LFSR_S0 = 0x00;

/* The function DIV alpha*/

/* Clocking LFSR in initialization mode*/

/* Clocking LFSR in keystream mode*/

void GenerateKeystream(u32 n, u32 *ks)

/* Prepare the initialization vector (IV) for SNOW 3G initialization as in

/* Run SNOW 3G algorithm to generate sequence of key stream bits KS*/

/* zero last bits of data in case its length is not byte-aligned

for ( i=0; i>i ) & 0x1 )

/* Load the Integrity Key for SNOW3G initialization as in section 4.4. */

/* Prepare the Initialization Vector (IV) for SNOW3G initialization as

z[0] = z[1] = z[2] = z[3] = z[4] = 0;

P = (u64)z[0] << 32 | (u64)z[1];