SJL AppNote 009 - Ciphering and Secure RRC Decoding

SJL AppNote 009 - Ciphering and Secure RRC Decoding
June 16, 2011

SJL AppNote 009 - Ciphering and Secure RRC Decoding www.sanjole.com 1

Ciphering and Secure RRC Decoding
Revision 2.0
Introduction
This document, and its examples provide a preliminary introduction to the topic of ciphering in
WaveJudge, focusing on Secure RRC Decoding.

The examples are based on the following files: IJ Example.RTPHYSAP, IJ Example.FXL, and IJ Example K-
asme.TXT. The files are available at http://support.sanjole.com/WaveJudge Captures Trial/.

This application note and the associated application are not in their final form and will continue to
evolve. They are currently based on version 4.2.14 of the WaveJudge software.

June 16, 2011
Table of Contents
Revision 1.0 ............................................................................................................................................... 1
Introduction .................................................................................................................................................. 1
Table of Contents .......................................................................................................................................... 2
Introduction to Keys and Entities used in Ciphering ..................................................................................... 3
Configuring Ciphering Support within WaveJudge ....................................................................................... 6
LTE UE Manager ........................................................................................................................................ 7
LTE MAC Settings Tree (Settings hierarchy display) ................................................................................. 7
Ciphering process and logic ........................................................................................................................ 13
Programming the UE Encryption Keys .................................................................................................... 16

June 16, 2011

Introduction to Keys and Entities used in Ciphering
IMSI International Mobil Subscriber Identity
GUTI Globally Unique Temporary Identifier
GUMMEI Globally Unique MME Identifier
MMEI MME Identifier
MCC Mobile Country Code
MNC Mobile Network Code
MMEG(I)-MME Group Identifier
MMEC MME Code
M-TMSI MME Assigned Temporary Unique Mobile Subscriber Id
KASME-Key Access Security Management Entity

ASME is defined in TS 33.401[1] as the entity in an access network that receives the top level
keys from the Home Subscriber Server (HSS). For E-UTRAN access, the MME assumes the role of the
Access Security Management Entity (ASME).

SRB Signaling Radio Bearer
DRB Data Radio Bearer

June 16, 2011
Below are the definitions of the different Keys

June 16, 2011
The following is the key hierarchy in which they are derived:

June 16, 2011
Configuring Ciphering Support within WaveJudge
To support Ciphering well review two tools in addition to the message list. The LTE UE Manager, and
the LTE MAC Settings.

Both of the tools are automatically populated, however once they are initally populated a cipher key
must be manually provided by the user. Once done the decoder can be rerun and secure messages may
be decoded.

Both tools are located on the tools drop down menu pictured below

June 16, 2011
Based on the test configuration users of the WaveJudge 4900 will use LTE MAC Settings for Cell 0 or 1
and LTE UE Manager Cell 0 or 1. IntelliJudge users will use the INtelliJudge LTE MAC Settings and LTE UE
Manager IntelliJudge.
LTE UE Manager
The following is the LTE UE Manager Screen. Other than colors its not user configurable.

The fields are as follows

1. Index index of the entry
2. Type Classifies the mobile element for a particular index entry, Broadcast, Unknown, Merged
and UE
3. IMSI International Mobil Subscriber Identity which the unique and permanent identity of a UE
4. GUTI Globally Unique Temporary ID which identifies the UE and the MME involved in the
connection
5. Color The color applied to the RNTI value that corresponds to the associated index entry

LTE MAC Settings Tree (Settings hierarchy display)
Below is the LTE MAC Settings Tree. Most of its fields are also preconfigured for convenience.
The user only needs to populate the proper KeySet with a K_ASME encryption key. However the user
may also add any or all entries to the tree if desired. Therefore the information on the controls and

June 16, 2011
fields are presented below. This information will then be followed by a section covering UE discovery
and K_ASME configuration.
The LTE MAC Settings Tree appears as follows:

The following are controls available to the LTE MAC Settings configuration window.

The LTE Settings window consists of the LTE Settings Tree. The Tree consists of one leaf or attribute
off of the trunk RA-RNTIs and three branches or nodes identified as Decoders, UEs and MAC-Layers.
Under each branch there are other branches and leafs. Each branch may have one or all of the
following functions

1. Append Child which represents a brand
2. Attributes leafs on the branch

June 16, 2011
3. Delete
4. Validate
5. Export
6. Import

The menu is accessed with a right button click while the mouse is hovering over the item to update

The Append Child function will identify all branches which have additional branches or attributes
associated with it. Attributes or branches of that child which are mandatory will automatically be
created. Optional as well as mandatory attributes may be added by the user.

June 16, 2011

Adding Attributes:

Once attributes have been added the optional entries may be deleted, or their contents may be
cleared, or set from either the parents menu or the attributes menu as displayed below

Parent clearing an Attribute content:

Parent deleting and Attribute:

June 16, 2011
Parent setting an Attribute content:

Export/Import Option

The Export/Import Option is available to every node in the LTE Mac Settings Tree.

Export/Import appends an .sxl extension to the file names.

Export will export everything under a node. For example if Export is performed at the Keysets Level
then the attributes CurrentKSI and NextKSI of KeySets and each KeySet child and their attributes will
be exported.

Exported files must be imported from the level at which they were exported. The following will be
displayed

June 16, 2011

The LTE Settings tree may be updated with child branches containing UE data based on decoded from
the LTE Attach process.

The UE data is a super set of the information contained in the UE Manager. UEs are contained in the
UEs object. Each UE identified by a User Equipment object. The objects included are the IMSI, the GUTI
subdivided into its components parts and the Key Set information that are discovered based on
messages sent in the clear.

These are User Equipment Attributes

1. IMSI
2. K_UE Encryption Key for UE Data

The following are the GUTI Component Parts:

1. MCC Mobile Country Code
2. MNC Mobile Network Code
3. GUMMEI Globally Unique MME Identifier Component
a. MMEG - MME Group Identifier
b. MMEC MME Code
4. M-TMSI MME Assigned Temporary Mobil Subscriber Identifier

The following are the attributes of the Key Sets Child

1. CurrentKSI - Current Key Set Identifier
2. NextKSI - Next Key Set Identifier
3. Key Set Child
a. KSI = Key Set Identifier
b. K_ASME Base Encryption Key
c. NASContext Security setting for NAS traffic
d. eNBContext Security settings for eNobeB traffic
e. SRBContext Security settings for signal channel traffic
f. DRBContext Security settings for data channel traffic

Each of the different security contexts contain the following attributes
1. Cipher Algorithm
2. Integrity Algorithm
3. Cipher Key Override Cypher Key to use when communicating in this context
4. Integrity Key Override Integrity Key to use when communicating in this context

The selectable Cipher Algorithms are:
1. EEA0
2. EEA1
3. EEA2

June 16, 2011
4. EEA3
5. EEA4
6. EEA5
7. EEA6
8. EEA7

The selectable Integrity Algorithms are:
1. EIA0
2. EIA1
3. EIA2
4. EIA3
5. EIA4
6. EIA5
7. EIA6
8. EIA7

Ciphering process and logic
The following is the process of discovering the UEs, and configuration of their K_ASME field.

During the first pass of the captured data through the decoder the RRCConnection Request and
RRCConnection Reestablishment Request messages on different RNTI are monitored. Their receipt
creates UE entries in the UE manager with an associated color and key code.

Next the RRConnection Request is checked for the ue-Identity field which is one of the following
1. 40 bit Random Value
2. S-TMSI

If the message includes an S-TMSI field its utilized to fill in the MMEC and the M-TMSI fields of the
GUTI. Otherwise a blank entry is created. From this point on all messages received on the
associated RNTI will display the RNTI using the color configured. Upon receipt of the next
RRCConnection request the color associated with the RNTI may change.

3. Attach Request.

Following the RRCConnection request an Attach Request may be received. If a UE doesnt exist for
the Attach Request messages RNTI a UE entry is created. Next the messages Old GUTI/ IMSI field is
checked. If an IMSI value is present its used to populate the IMSI field, otherwise the GUTI field is
populated if it doesnt already exist.

Below is a decoded Attach Request. Contained within it is an expansion of the Old GUTI/IMSI field.
In it is the IMSI identity field.

June 16, 2011

Once this information is obtained the decoder populates the LTE Mac Configuration tree with UEs
and the attributes available

This may include

IMSI
GUTI
Key Sets

June 16, 2011

The Keys Sets created are empty containers with place holders for the attributes required. The Key
Set is identified in the NAS Security Mode Command pictured below. Different Security Mode
Commands may identify Key Sets, Security Algorithms, and UE security capabilities. The user must
provide the Authentication key for the key set used. Typically the Key would be the K_asme since all
other keys would be derived from the K_asme. If there are problems using the Kasme, the user has
the option to configure the Cipher Key Override, and or Integrity Key Override for each of the
following: NASContext , ENBContext, SRBContext, or DRBContext.

Below the Security Mode Command decode identifies Ciphering Algorithm EEA1, Integrity Algorithm
EIA1 and NAS Key Set 5 to be used

June 16, 2011
Programming the UE Encryption Keys
Once the UE Managers UE table and the LTE MAC settings tree has been populated the encryption
key identified by the user may be programmed into the K_ASME field for the associated UE and its
key set.

To identify the UE to configure look through the UE manager list for an entry with a valid ISMI or
valid GUTI.

Item 1 on index 4 represents a valid IMSI. Item 2 represents a valid GUTI. Both were received
through the Attach Requests. The first case represents a UE that has no knowledge of a GUTI, the
second case represents a UE re-entering a network or roaming to another network therefore it has a
previously received GUTI which may be replaced by the MME.

Heres an entry in the LTE Settings tree identifying a UE and the fields that should be matched when
programming the K_ASME of a UE

1. The IMSI code corresponding to item 1 above
2. The id of the next Key Set of 5
3. Key Set 5

June 16, 2011

Once found Clear and Set the K_ASME attribute.

June 16, 2011

June 16, 2011

After configuring the K_ASME field and clicking the OK button the decoder will run again, and
decode the encrypted data.

Below, are the before and after results of configuring the Cipher Key.

June 16, 2011
The following is a message decode prior to adding the key; in the validated field the message No Key is
displayed:

June 16, 2011
After adding the key, the UE manager is updated with the GUTI associated with the UE we configured.
The GUTI was obtained from the Attach Accept Message.

In addition the UE in the LTE MAC Settings has been updated with a GUTI and various context
entries have been created, although empty.

Now theres an updated message list. Among messages included, are the various encrypted Security
Protected NAS Messages which includes the Attach Accept message which became visible and
allows the decoder to extract the GUTI. Also visible is the Attach Complete and EMM Information
message. Additionally, the Validated field indicates a key is associated with the Service Request
message.

June 16, 2011
The updated message list:

SJL AppNote 009 - Ciphering and Secure RRC Decoding

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SJL AppNote 009 - Ciphering and Secure RRC Decoding

Caricato da

Copyright:

Formati disponibili

SJL AppNote 009 - Ciphering and Secure RRC Decoding

June 16, 2011

Potrebbero piacerti anche