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.
- RAND – It is the random no generated through some random no generation algorithm.
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
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.
- KeNB – To calculate KeNB following steps are required.
- Algorithm Key generation function – It covers the derivation of Knas-int, Knas-enc, Krrc-int, Krrc-enc, Kup-enc.
Key = CK||IK
S = FC(0x10) || SN Id || Length of SN id || SQN AK || length of SQN AK
KASME = HMAC-SHA-256 (Key, S)
Key = KASME
S = FC(0x11) || UL NAS Count || Length of UL NAS Count
KeNB = HMAC-SHA-256 (Key, S)
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.
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.
Permalink
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
Permalink
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”
Permalink
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.
Permalink
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
Permalink
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?
Permalink
The SQN is actually 48 bit value (6 octet)
Permalink
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.
Permalink
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”
Permalink
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.
Permalink
Hi anyone knows if there’s an free implementation of the SNOW 3G ciphering option (eea1)?
Permalink
Hi, what would happen if UE does not include security mode complete in the NAS? It looks like the attach still completes.
Permalink
its nice one
Permalink
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!
Permalink
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
Permalink
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…
Permalink
Yes, You are right. AMF is not configured in USIM. It is configured in HSS and transfered to UE with AUTN.
Permalink
Hi,
Does MME send Authentication Request (for re-authentication) with integrity protected only ?
Thanks
Janardhan.
Permalink
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?
Permalink
Hi Can you please give a call flow for security when UE moves from 3G to 4G
Permalink
I will try to add some security call flow procedures for handover scenarios
Permalink
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.
Permalink
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
Permalink
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.
Permalink
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! 🙂
Permalink
Ik and Ck are used to generate Kasme only?
or they have other roles ?
Permalink
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,0x9C,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,0x27,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,0x4A,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,0x4B,0xBD,0x8B,0x8A,
0x70,0x3E,0xB5,0x66,0x48,0x03,0xF6,0x0E,0x61,0x35,0x57,0xB9,0x86,0xC1,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,0x84,0x65,0xE2,
0xD8,0xE9,0xCC,0xED,0x40,0x2F,0x11,0x28,0x57,0xD2,0xAC,0xE3,0x4A,0x15,0x1B,0xB9,
0xB2,0x80,0x85,0xA6,0x2E,0x02,0x47,0x29,0x07,0x4B,0x0E,0xC1,0x51,0xAA,0x89,0xD4,
0xCA,0x01,0x46,0xB3,0xEF,0xDD,0x44,0x7B,0xC2,0x7F,0xBE,0xC3,0x9F,0x20,0x4C,0x64,
0x83,0xA2,0x68,0x42,0x13,0xB4,0x41,0xCD,0xBA,0xC6,0xBB,0x6D,0x4D,0x71,0x21,0xF4,
0x8D,0xB0,0xE5,0x93,0xFE,0x8F,0xE6,0xCF,0x43,0x45,0x31,0x22,0x37,0x36,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,0xF5,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,0x8B,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,0x3E,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_S11 = LFSR_S12;
LFSR_S12 = LFSR_S13;
LFSR_S13 = LFSR_S14;
LFSR_S14 = LFSR_S15;
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_S10 = LFSR_S11;
LFSR_S11 = LFSR_S12;
LFSR_S12 = LFSR_S13;
LFSR_S13 = LFSR_S14;
LFSR_S14 = LFSR_S15;
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_S8 = k[0] ^ 0xffffffff;
LFSR_S7 = k[3];
LFSR_S6 = k[2];
LFSR_S5 = k[1];
LFSR_S4 = k[0];
LFSR_S3 = k[3] ^ 0xffffffff;
LFSR_S2 = k[2] ^ 0xffffffff;
LFSR_S1 = k[1] ^ 0xffffffff;
LFSR_S0 = k[0] ^ 0xffffffff;
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);
Permalink
PLEASE IF ANYONE HAVING THE IMPLEMENTATION CODE, PLEASE DO MAIL ME…
Permalink
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,
Permalink
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.
Permalink
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
Permalink
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.
Permalink
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
Permalink
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
Permalink
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
Permalink
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.
Permalink
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
Permalink
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.
Permalink
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
Permalink
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?
Permalink
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
Permalink
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.
Permalink
HI Prasanna
Why we are using two security mode commands in LTE and only one security command in UMTS
Thanks
Rakesh
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.
Permalink
Thanks for the info. nicely organised. very useful.
Permalink
Hi,
How RRC will set the content of Security mode complete message and security mode failure message?