4G/LTE - NAS

 

 

 

EEA(EPS Encryption Algorithms)

 

Simply put, this is a Ciphering Algorithm. and Ciphering can be aplied to both U-Plane Data and C-Plane Data (RRC/NAS Message). The type of EEA being used is determined by Network and informed to UE via Security Mode Command. NAS EEA is carried by NAS:Security Mode Command and RRC EEA is carried by RRC:Security Mode Command.

Three questions sit underneath that paragraph. Where does the network announce its choice, which algorithms can it choose from, and what does the chosen one actually do to the bits ? This page takes them in that order, because the two decodes below are the evidence for everything after them.

Where does the network announce its choice ?

The network activates ciphering twice, not once. The MME configures NAS ciphering and the eNB configures AS ciphering, and each one uses its own Security Mode Command. The two decodes below are one of each.

33.401 clause 7.2.4.1 keeps the two apart deliberately. It requires separate AS and NAS level security mode command procedures, and it allows the selected AS and NAS algorithms to differ at any moment. A log can therefore show 128-EEA2 on NAS and 128-EEA1 on RRC without contradicting itself. Each node ran its own selection.

The selection rule is the same on both sides. An operator configures each MME and each eNB with a priority-ordered list of ciphering algorithms. The node then picks the highest entry on its own list that also appears in the UE EPS security capabilities it received. The UE never negotiates, which is what the opening paragraph means when it says the network determines the type.

The first decode is the NAS half. The MME sends it, and the tree below is the message as a decoder unpacked it.

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, and it is the answer this page is about. The whole information element is one octet.
  • Type of ciphering algorithm ::= CHOICE [EPS encryption algorithm EEA0(ciphering not used)] is the red line inside it. This capture selected EEA0, so NAS ciphering was off for the exchange it records.
  • The two spare ::= FIX [0] lines are real bits. 24.301 clause 9.9.3.23 puts the ciphering algorithm in bits 5 to 7 of octet 2 and the integrity algorithm in bits 1 to 3. The clause then states that bit 4 and bit 8 are spare and shall be coded as zero.
  • Message type ::= MSG [5D] is the message identity. 0x5D is the SECURITY MODE COMMAND.
  • Replayed UE security capabilities near the bottom is not padding. 33.401 requires the MME to send the UE's own capabilities back inside an integrity protected message, so that the UE can detect a bidding down attack.

The reason for replaying those capabilities is worth spelling out. Suppose an attacker stripped 128-EEA2 out of the Attach Request on its way to the MME. The MME would then select a weaker algorithm from a shortened list. The UE compares the replayed capabilities against what it actually sent, sees the difference, and rejects the command.

One line needs reading carefully. The security header type at the top reads Plain NAS message, not security protected, while 33.401 clause 7.2.4.4 requires this message to be integrity protected, though never ciphered. The value belongs to the message body the decoder has already unwrapped, rather than to the protected message that carried it over the air.

The RRC half of the same decision looks different. 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 it was 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.
  • cipheringAlgorithm ::= ENUMERATED [eea0] is the red line, and it is the AS selection. It agrees with the NAS selection in the capture above, which is common in practice but never required.
  • rrc-TransactionIdentifier ::= INTEGER (0..3) [0] at the top is the transaction number that the matching SecurityModeComplete will echo back.
  • nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit at the end marks an absent field. Omit means the field was not encoded at all, rather than encoded and empty.

The enumeration behind cipheringAlgorithm is worth reading, because the release history shows in the names. 36.331 defines it as a type of its own.

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, ...}
}

CipheringAlgorithm-r12 ::=				ENUMERATED {
											eea0, eea1, eea2, eea3-v1130, spare4, spare3,
											spare2, spare1, ...}
  • eea3-v1130 carries its version in its name. The value sits fourth in the list, where the countdown of spares would otherwise reach spare5, so ZUC was given a code point that had been reserved since Release 8.
  • The root list holds eight values, which is three bits. That is the same width the NAS information element gives the field, so RRC cannot express a selection that NAS cannot.
  • The type is called CipheringAlgorithm-r12 while its values date from Release 11. Release 12 moved the enumeration into a named type so that MobilityControlInfoSCG-r12 could reuse it for the secondary cell group.
  • integrityProtAlgorithm sits beside it and is a separate choice. 33.401 lets the ciphering and integrity algorithms differ, and the EIA page covers that half.
  • Ciphering is configured twice : the MME sets the NAS algorithm and the eNB sets the AS algorithm, through two separate Security Mode Command procedures.
  • The network decides and the UE only supplies a list : each node picks the highest entry on its own operator-ordered priority list that the UE also supports.
  • The replayed capabilities are the tamper check : 33.401 requires the UE's own security capabilities to come back inside an integrity protected message, so a shortened list is detectable.
  • AS and NAS may differ at the same moment : 33.401 clause 7.2.4.1 allows it, so two different algorithm names in one log are not a decoding error.

Which algorithms are defined ?

The choice is smaller than the field width suggests. 33.401 clause 5.1.3.2 reserves a 4-bit space for EPS Encryption Algorithms and has assigned four of the sixteen values. One of those four does no encryption at all.

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

    Identifier

    Type

    Description

    0000

    EEA0

    Null ciphering algorithm

    0001

    128-EEA1

    SNOW 3G

    0010

    128-EEA2

    AES

    0011

    128-EEA3

    ZUC
  • The table lists four rows, and only three of them encrypt anything. EEA0 is the null algorithm, so the three the sentence above counts are 128-EEA1, 128-EEA2 and 128-EEA3.
  • The 128- prefix states a key length, and EEA0 does not carry it. 33.401 clause 5.1.3.2 opens by saying that every algorithm in the clause takes a 128-bit input key except the null ciphering algorithm.
  • The twelve identifier values above 0011 are reserved for future use in 33.401.
  • The identifier is four bits here and three bits in the NAS message. 33.401 assigns a 4-bit identifier, while 24.301 clause 9.9.3.23 carries bits 5 to 7 of one octet and leaves bit 8 spare.

The three working algorithms come from three unrelated cryptographic families, and that is the point of having three. A break in one is unlikely to carry across to the others, so an operator keeps a fallback that does not share the broken construction.

128-EEA1 is SNOW 3G. 33.401 Annex B.1.2 says it is identical to UEA2, the UMTS algorithm, with the initialisation vector built the same way. An operator moving to LTE therefore kept the stream cipher it already had.

128-EEA2 is AES in counter mode. Annex B.1.3 defines the counter blocks. The top 64 bits of the first block hold COUNT, then BEARER, then DIRECTION, then 26 zero bits, and the bottom 64 bits are zero. Each later block increments the bottom half. That construction is what turns a block cipher into a keystream generator.

128-EEA3 is ZUC, and it arrived later in a separate specification. It is also the only one of the three that is optional. 33.401 clause 5.1.3.2 says UEs and eNBs shall implement EEA0, 128-EEA1 and 128-EEA2, and may implement 128-EEA3. The clause then repeats the same split for UEs and MMEs on the NAS side.

  • Four values, three ciphers : EEA0 is the null algorithm, so only 128-EEA1, 128-EEA2 and 128-EEA3 generate a keystream.
  • Two ciphers are mandatory and one is not : 33.401 requires EEA0, 128-EEA1 and 128-EEA2 in every UE, eNB and MME, and leaves 128-EEA3 optional on both the AS and the NAS side.
  • The families are unrelated on purpose : SNOW 3G, AES and ZUC share no common construction, so a break in one does not reach the other two.
  • EEA0 is not an absence of processing : 33.401 Annex B.0 requires it to behave as a keystream of zeroes, so every other step of the ciphering path still runs.

How does an EEA turn the key into ciphertext ?

None of the three algorithms encrypts the message directly. Each one generates a keystream from five inputs, and the message is then added to that keystream one bit at a time. 33.401 Annex B.1.1 defines the inputs and the addition.

The five inputs are a 128-bit KEY, a 32-bit COUNT, a 5-bit BEARER identity, a 1-bit DIRECTION and a LENGTH. Figure 1 puts the sender on the left and the receiver on the right, because both ends run the identical algorithm over the identical inputs. Only the block arriving at the addition differs.

At the sender COUNT 32 bit BEARER 5 bit DIRECTION 1 bit LENGTH KEY 128 bit EEA 128-EEA1 / 2 / 3 KEYSTREAM BLOCK At the receiver COUNT 32 bit BEARER 5 bit DIRECTION 1 bit LENGTH KEY 128 bit EEA 128-EEA1 / 2 / 3 KEYSTREAM BLOCK PLAINTEXT BLOCK PLAINTEXT BLOCK CIPHERTEXT BLOCK

Figure 1. Ciphering with an EEA, redrawn from 33.401 Figure B.1-1. Both ends build the same keystream from the same five inputs, so the receiver recovers the plaintext by repeating the sender's addition rather than by inverting it.

  • KEY is KNASenc, KRRCenc or KUPenc, depending on what is being ciphered. It never travels in the Security Mode Command. Only the algorithm identifier is sent, and both ends derive the key themselves.
  • COUNT is 32 bits and advances with every PDCP PDU or NAS message. It is the input that stops two messages sharing a keystream.
  • BEARER is 5 bits of radio bearer identity. Two bearers still get different keystreams when they share a key and a COUNT.
  • DIRECTION is one bit, 0 for uplink and 1 for downlink. Without it, an uplink message and a downlink message would share a keystream whenever the COUNT and the bearer matched.
  • LENGTH says how much keystream to generate. 33.401 adds that it affects only the length of the keystream block and not the bits in it.

That last sentence has a practical consequence. If LENGTH changed the bits, two messages of different lengths would produce unrelated keystreams, even on the same key, COUNT, bearer and direction. A receiver would then have to know the length before it could start. Because LENGTH only truncates, the receiver can generate exactly as much keystream as the message needs.

The addition is exclusive-or, and exclusive-or is its own inverse. Figure 1 therefore shows the same block on both sides instead of an encryption box and a decryption box. Deciphering is enciphering, run a second time against the same keystream.

This also explains why COUNT, BEARER and DIRECTION matter as much as the key. Imagine one keystream used on two different messages. Adding the two ciphertexts together would cancel the keystream and leave the two plaintexts added to each other, which is a real attack rather than a theoretical one. The three varying inputs exist to prevent that collision for the lifetime of one key.

EEA0 fits the same frame without any special case. 33.401 Annex B.0 requires it to behave as though it produced a keystream of zeroes, of whatever length LENGTH asked for. Adding zero changes nothing, so the ciphertext equals the plaintext. Every other part of the ciphering path still runs, which is why the specification describes EEA0 as an algorithm rather than as a switch.

  • The algorithm never touches the message : it produces a keystream, and the message is exclusive-ored with it, so enciphering and deciphering are one operation.
  • Five inputs, and only one of them is secret : KEY is derived at both ends and never sent, while COUNT, BEARER, DIRECTION and LENGTH are all knowable.
  • The three varying inputs prevent keystream reuse : two messages sharing a keystream would leak the exclusive-or of their plaintexts.
  • LENGTH truncates and does not alter : 33.401 states it affects only the length of the keystream block, which is what lets a receiver generate keystream as the message arrives.

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.3.2 assigns the identifier values, clause 7.2.4 covers algorithm selection and the security mode command, and Annex B defines EEA0 and the ciphering inputs.

[3] 36.331 : 3GPP - E-UTRA; Radio Resource Control; Protocol specification, v19.3.0. SecurityAlgorithmConfig and CipheringAlgorithm-r12 carry the AS selection.

[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.