4G/LTE - NAS

 

 

 

EIA(EPS Integrity Algorithms)

 

As the term implies, this is "Integrity Algorithm" being used in LTE. This algorithm applies only to C-Plane data (NAS mesage). You can take this as a kind of special encryption algorithm which is used only for NAS message. Like EEA, this is also determined by the Network and informed to UE by EMM:Security Mode Command and RRC : Security Mode Command message.

Two points in that paragraph are narrower than 33.401 is, and both matter for the rest of the page. C-Plane covers RRC as well as NAS, and 33.401 clause 5.1.4.1 requires integrity protection on both, so the RRC decode below is not an exception. An EIA is also not an encryption algorithm. It hides nothing, and computes a 32-bit check value that travels beside the message.

Four questions follow from that. Where the network announces its choice, which algorithms are defined, how the null algorithm reached the specification, and what an EIA actually computes. The order below takes the messages first and the arithmetic last.

Where is the integrity algorithm selected ?

The network configures integrity in the same two places it configures ciphering. The MME selects the NAS algorithm and the eNB selects the AS algorithm, and each announces its choice in its own Security Mode Command. The two decodes below are one of each.

33.401 clause 7.2.4.1 requires the two procedures to stay separate, and it adds a rule that has no equivalent on the ciphering side. The same integrity algorithm shall be used for RRC integrity protection and for user plane integrity protection. One AS selection therefore covers both, while NAS is chosen on its own.

The selection itself works the way it does for ciphering. An operator configures each MME and each eNB with a priority-ordered list. Each node then picks the highest entry on its own list that also appears in the UE EPS security capabilities it received.

The first decode is the NAS half. It is the same message the EEA page shows, and here the red line is the integrity field rather than the ciphering one.

Capture : NAS Security mode command, shown as a decoder tree. The field values come from one live exchange and not from the specification.

NAS_LTE:EMM,Security mode command
Security mode command ::= DIVISION
  +-Security header type ::= V
  | +-Security header type ::= CHOICE [Plain NAS message, not security protected]
  +-EPS mobility management protocol discriminator ::= V
  | +-Protocol discriminator ::= PD [7]
  +-Security mode command message identity ::= V
  | +-Message type ::= MSG [5D]
  +-Selected NAS security algorithms ::= V
  | +-Octet1 ::= DIVISION
  |   +-spare ::= FIX [0]
  |   +-Type of ciphering algorithm ::= CHOICE [EPS encryption algorithm EEA0(ciphering not used)]
  |   +-spare ::= FIX [0]
  |   +-Type of integrity protection algorithm ::= CHOICE [Reserved 0]
  +-Spare half octet ::= V
  | +-Spare half octet ::= FIX [0]
  +-NAS key set identifier ::= V
  | +-TSC ::= CHOICE [native security context (for KSI ASME)]
  | +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 0]
  +-Replayed UE security capabilities ::= LV
  | +-Octet1 ::= DIVISION
  | | +-Length of UE security capability contents ::= LEN (0..255) [5]
  • Selected NAS security algorithms is the blue block. One octet carries both choices, so a single NAS Security Mode Command settles ciphering and integrity together.
  • Type of integrity protection algorithm ::= CHOICE [Reserved 0] is the red line, and the value it carries is 000.
  • The name Reserved 0 points straight at the release history below. 24.301 clause 9.9.3.23 now calls value 000 the EPS integrity algorithm EIA0. This decoder still calls it reserved, which is the Release 8 naming that the release history further down the page explains.
  • The two spare ::= FIX [0] lines are bit 4 and bit 8 of octet 2. 24.301 requires both to be coded as zero.
  • Replayed UE security capabilities lets the UE check that nobody shortened the list it originally sent.

One property of this message matters more for integrity than it does for ciphering. 33.401 clause 7.2.4.4 requires the NAS Security Mode Command to be integrity protected and never ciphered. The UE therefore verifies a MAC on the very message that tells it which integrity algorithm to use, which is why the algorithm and the replayed capabilities have to travel together.

The RRC half sits in a different message. The block below is the tail of an RRC SecurityModeCommand, and the capture begins partway down the tree, so the outer DL-DCCH-Message levels are missing. It is left exactly as captured.

Capture : RRC SecurityModeCommand, shown as a decoder tree. The capture is truncated at the top and is left that way, because it records one exchange rather than a specification.

   +-c1 ::= CHOICE [securityModeCommand]
      +-securityModeCommand ::= SEQUENCE
        +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
        +-criticalExtensions ::= CHOICE [c1]
          +-c1 ::= CHOICE [securityModeCommand-r8]
            +-securityModeCommand-r8 ::= SEQUENCE [0]
              +-securityConfigSMC ::= SEQUENCE
              | +-securityAlgorithmConfig ::= SEQUENCE
              |   +-cipheringAlgorithm ::= ENUMERATED [eea0]
              |   +-integrityProtAlgorithm ::= ENUMERATED [spare1]
              +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
  • securityAlgorithmConfig is the blue block, and it carries exactly two fields.
  • integrityProtAlgorithm ::= ENUMERATED [spare1] is the red line. spare1 names no algorithm in any release of the enumeration quoted below. The line above it carries eea0, so this capture reads as a test configuration rather than a live one. It is left exactly as recorded.
  • 36.331 clause 5.3.4.3 says what the UE does with the field. It derives the KRRCint key for the algorithm named here, then asks lower layers to verify the integrity of this same SecurityModeCommand using that algorithm and that key.
  • rrc-TransactionIdentifier ::= INTEGER (0..3) [0] is the transaction number the matching SecurityModeComplete will echo back.
  • Integrity is selected twice : the MME chooses the NAS algorithm and the eNB chooses the AS algorithm, in two separate Security Mode Command procedures.
  • One AS choice covers RRC and the user plane : 33.401 clause 7.2.4.1 requires the same integrity algorithm for both, so the eNB makes a single selection.
  • The security mode command protects itself : it is integrity protected and never ciphered, so the UE verifies a MAC using the algorithm the message itself is announcing.
  • A decoder label is not a specification : this capture prints Reserved 0 where the current 24.301 prints EIA0, because the decoder was built against the older naming.

Which algorithms are defined ?

The identifier space has the same shape as the ciphering one, and the four assignments line up with it one for one. 33.401 clause 5.1.4.2 gives each EPS Integrity Algorithm a 4-bit identifier and has defined four of the sixteen values.

Currently there are two different types of EIA we can use as shown in the following table.

    Identifier

    Type

    Description

    0000

    EIA0

    Null Integrity algorithm

    0001

    128-EIA1

    SNOW 3G

    0010

    128-EIA2

    AES

    0011

    128-EIA3

    ZUC
  • The table lists four rows and the sentence above counts two. EIA0 checks nothing and 128-EIA3 arrived later, so the two being counted are 128-EIA1 and 128-EIA2, which are also the two that every implementation must carry.
  • EIA0 carries no 128- prefix where the other three do. The prefix marks a 128-bit input key, and the null algorithm takes none.
  • The twelve identifier values above 0011 are reserved for future use in 33.401.
  • The identifier is four bits in 33.401 and three bits in the NAS message. 24.301 clause 9.9.3.23 puts the integrity algorithm in bits 1 to 3 of octet 2 and leaves bit 4 spare.

The three working algorithms reuse the same three families as the ciphering side. 128-EIA1 is SNOW 3G, 128-EIA2 is AES and 128-EIA3 is ZUC, matching 128-EEA1, 128-EEA2 and 128-EEA3. An implementation therefore carries three primitives rather than six.

The mode differs even where the family does not. 33.401 Annex B.1.3 builds 128-EEA2 from AES in counter mode, which produces a keystream as long as the message. Annex B.2.3 builds 128-EIA2 from AES in CMAC mode, which produces a fixed 32-bit tag. The same block cipher does two different jobs.

128-EIA1 is also not quite its UMTS ancestor. Annex B.2.2 says it is implemented the same way as UIA2, with one substitution. 128-EIA1 replaces the 32-bit FRESH input with the 5-bit BEARER followed by 27 zero bits.

The obligations are not symmetric, and EIA0 is the exception. 33.401 clause 5.1.4.2 requires UEs and eNBs to implement 128-EIA1 and 128-EIA2 for RRC signalling and leaves 128-EIA3 optional, then repeats that split for UEs and MMEs on NAS. The rule for EIA0 is reversed. Every UE shall implement it, while an MME, an RN or an eNB need not.

  • Four values, three algorithms that check anything : EIA0 returns a fixed answer, so only 128-EIA1, 128-EIA2 and 128-EIA3 compute a real MAC.
  • The families match the ciphering side and the modes do not : AES appears as counter mode for 128-EEA2 and as CMAC for 128-EIA2, which is the difference between a keystream and a tag.
  • 128-EIA1 and 128-EIA2 are the mandatory pair : 33.401 requires both in UEs, eNBs and MMEs, and leaves 128-EIA3 optional everywhere.
  • EIA0 is mandatory in the UE and optional in the network : 33.401 clause 5.1.4.2 states that split, which is the reverse of how the other three are treated.

How did EIA0 get into the specification ?

The null integrity algorithm arrived two releases after the null ciphering algorithm, and the reason is visible in the ASN.1. Three versions of one information element, quoted below in order, record the change from a reserved code point to a named one.

In Rel 8, EIA0 is not officially defined because integrity protection is mandatory for RRC (AS) and NAS signalling messages, but in some special condition (e.g, in UE testing environment),  Null Integrity is used. Even in this case, NAS message carries Integrity Header, but the MAC (Message Authentication Code) part of the header is all set to be 0.

Following is based on 36.331 v8.10.0 (Release 8), dated 2010-07

SecurityAlgorithmConfig ::=			SEQUENCE {
	cipheringAlgorithm					ENUMERATED {
											eea0, eea1, eea2, spare5, spare4, spare3,
											spare2, spare1, ...},
	integrityProtAlgorithm				ENUMERATED {
											reserved, eia1, eia2, spare5, spare4, spare3,
											spare2, spare1, ...}
}
  • reserved sits exactly where eia0 would later go. The field description in that version adds that the value reserved is handled as a spare value in Rel-8, so a Release 8 network had no way to name null integrity.
  • cipheringAlgorithm on the line above already carried eea0 in the same version. Ciphering could be switched off from the first release, and integrity could not, which is the asymmetry the paragraph above describes.
  • Both enumerations run to eight values and end with an extension marker, so the shape was fixed early and only the names changed afterwards.

 

In Rel 9, 3GPP started to define EIA0 as shown below. I am not sure if there is any live network using EIA0.. probably 3GPP started supporting this for test purpose.

Following is based on 36.331 v10.4.0 (Release 10), dated 2012-01

SecurityAlgorithmConfig ::=			SEQUENCE {
	cipheringAlgorithm					ENUMERATED {
											eea0, eea1, eea2, spare5, spare4, spare3,
											spare2, spare1, ...},
	integrityProtAlgorithm				ENUMERATED {
											eia0-v920, eia1, eia2, spare5, spare4, spare3,
											spare2, spare1, ...}
}
  • eia0-v920 has replaced reserved, and the suffix dates the change. The value was added in v9.2.0, which is where a network first gained a way to signal null integrity.
  • Nothing else in the element moved. cipheringAlgorithm is unchanged, and the spare countdown still runs from spare5.

33.401 answers the question the paragraph above leaves open. Clause 5.1.4.1 allows EIA0 only for unauthenticated emergency calls, and clause 5.1.4.2 adds that implementing it in an MME, an RN or an eNB is optional. The same clause requires it to be disabled wherever unauthenticated emergency calling is not a regulatory requirement. It is a regulatory feature rather than a test feature, and a network that does not need it turns it off.

EIA0 switches off a second protection as well. 33.401 Annex B.0 states that replay protection shall not be activated when EIA0 is activated, and that the receiver does not check the received MAC at all.

The same information element in the current release shows the enumeration in its present form.

Following is based on 36.331 v19.3.0 (Release 19)

SecurityAlgorithmConfig ::=			SEQUENCE {
	cipheringAlgorithm					CipheringAlgorithm-r12,
	integrityProtAlgorithm				ENUMERATED {
											eia0-v920, eia1, eia2, eia3-v1130, spare4, spare3,
											spare2, spare1, ...}
}
  • eia3-v1130 now occupies the slot that held spare5 in both versions above, so ZUC entered the enumeration in Release 11.
  • cipheringAlgorithm is no longer an inline enumeration. Release 12 moved it into a named type, CipheringAlgorithm-r12, so that MobilityControlInfoSCG-r12 could reuse it for the secondary cell group. The integrity field was never factored out the same way.
  • Read the integrity line down the three tiles and the history is complete. It runs reserved, then eia0-v920, then eia0-v920 with eia3-v1130 beside it.
  • The ASN.1 records the release history directly : one field name changes across three versions, and each change is dated by its own suffix.
  • Null integrity was a late addition and null ciphering was not : eea0 existed in Release 8 while the matching integrity value was still marked reserved.
  • EIA0 exists for unauthenticated emergency calls : 33.401 restricts it to that case and requires it to be disabled where no regulation demands it.
  • Choosing EIA0 also switches replay protection off : 33.401 Annex B.0 says so explicitly, and adds that the receiver stops checking the MAC.

What does an EIA actually compute ?

An EIA returns a number rather than a message. 33.401 Annex B.2.1 defines five inputs and one 32-bit output, and the receiver's task is to compute the same number and compare. That comparison is what the word integrity means here.

The five inputs are a 128-bit KEY, a 32-bit COUNT, a 5-bit BEARER, a 1-bit DIRECTION and the MESSAGE itself. Figure 1 puts the sender on the left and the receiver on the right. Both ends run the same algorithm over the same inputs, and the only question at the end is whether the two results agree.

At the sender COUNT 32 bit BEARER 5 bit DIRECTION 1 bit MESSAGE KEY 128 bit EIA 128-EIA1 / 2 / 3 MAC-I / NAS-MAC 32 bit At the receiver COUNT 32 bit BEARER 5 bit DIRECTION 1 bit MESSAGE KEY 128 bit EIA 128-EIA1 / 2 / 3 XMAC-I / XNAS-MAC 32 bit compare equal : the message is accepted. different : it is discarded.

Figure 1. Deriving the MAC, redrawn from 33.401 Figure B.2-1. The sender appends MAC-I to the message, and the receiver computes XMAC-I over what actually arrived. A difference between the two means the message was altered, or that the two security contexts do not match.

  • KEY is KNASint or KRRCint, 128 bits. Both ends derive it, and it never travels in the Security Mode Command.
  • MESSAGE is an input and not an output. The algorithm reads the whole message and returns 32 bits, so nothing in the message is hidden or changed.
  • COUNT, BEARER and DIRECTION appear for the reason they appear in ciphering. They stop a MAC computed for one message being accepted on another.
  • The output is 32 bits whatever the message length. 33.401 calls it MAC-I on the RRC side and NAS-MAC on the NAS side, with XMAC-I and XNAS-MAC for the copy the receiver computes.
  • The receiver works on the message it received rather than on the message that was sent. Those two differ exactly when something has gone wrong, which is what makes the comparison worth doing.

The mode is where 128-EIA2 differs from 128-EEA2. Annex B.2.3 builds the CMAC input as COUNT, then BEARER, then DIRECTION, then 26 zero bits, then the message, and uses a 32-bit CMAC output directly as the result. Ciphering fed the same three fields into a counter block instead.

EIA0 is the degenerate case of the same picture. 33.401 Annex B.0 requires it to generate a MAC of all zeroes at both ends, so the comparison always succeeds. The specification switches replay protection off alongside it and states that the receiver does not check the received MAC.

This is the case the page describes higher up, where an Integrity Header carries a MAC of all zeroes. The header stays, its length stays, and only the value is fixed. Every other part of the path behaves as though a real algorithm were running, which is what makes EIA0 an algorithm rather than a switch.

  • The algorithm reads the message and writes 32 bits : it never modifies or conceals anything, which is what separates integrity from ciphering.
  • Both ends compute, and only the comparison decides : the receiver derives its own XMAC-I over what arrived and checks it against the MAC-I that came with it.
  • The output length does not follow the message length : a one byte message and a full RRC reconfiguration both produce 32 bits.
  • EIA0 makes the comparison meaningless by design : a MAC of zeroes always matches, and 33.401 disables replay protection at the same time.

Reference :

[1] The New LTE Cryptographic Algorithms EEA3 and EIA3

[2] 33.401 : 3GPP - 3GPP System Architecture Evolution; Security architecture, v19.2.0. Clause 5.1.4 defines the scope and the identifier values, clause 7.2.4 covers algorithm selection, and Annex B.0 and B.2 define EIA0 and the MAC derivation.

[3] 36.331 : 3GPP - E-UTRA; Radio Resource Control; Protocol specification. Three versions were read for the SecurityAlgorithmConfig tiles above, v8.10.0, v10.4.0 and v19.3.0, and clause 5.3.4.3 of the current version gives what the UE does with the field.

[4] 24.301 : 3GPP - Non-Access-Stratum protocol for Evolved Packet System; Stage 3, v20.0.0. Clause 9.9.3.23 gives the bit layout of the NAS security algorithms information element.