SNOW3G is the algorithm used for UIA2 in UMTS and EIA1 in LTE. In this page, I will describe on this algorithm at a very high level. For the details (or sample source code), refer to ETSI/SAGE specification (3GPP document on NAS Integrity does not have any details on the algorithm itself). If you want to look into some implementation example in source code, refer to ref [1].

In this page, just try to understand what kind of input you need for the algorithm and how to figure out those input values.

I'll start with the inputs and the output, then look at the one input that confuses most people, FRESH. At the end we'll see where LTE uses the same algorithm, because EIA1 protects both NAS and RRC messages.

• What are the Input and Output of SNOW3G ?
• How to derive FRESH value ?
• Where is SNOW3G used in LTE ?
• Reference

What are the Input and Output of SNOW3G ?

Every integrity algorithm needs the same things: a key, a counter that never repeats, some context bits and the message itself. The table below lists these inputs as UIA2 defines them. EIA1 reuses the list, with one change that the next section explains.

The table has five inputs of fixed size and one of variable size. COUNT-I and DIRECTION make each MAC-I unique in time and direction, so a replayed message fails the check. IK is the 128 bit key. LENGTH gives the number of bits in MESSAGE, so the message does not have to end on a byte boundary. The output MAC-I is always 32 bits, whatever the message length.

In LTE the same inputs get LTE names. 33.401 v19.2.0 Annex B.2.1 calls them KEY, COUNT, BEARER, DIRECTION and MESSAGE, and the 32 bit output is MAC-I for RRC or NAS-MAC for NAS. KEY is K_NASint for NAS and K_RRCint for RRC. DIRECTION is 0 for uplink and 1 for downlink. FRESH has no LTE name of its own, and that is the topic of the next section.

Following is the illustration of overall procedure for SNOW3G. It is drawn based on ref [2] and modified a little bit based on ETSI/SAGE specification.

In the diagram below, the inputs enter at the top and the MAC leaves at the bottom. COUNT, FRESH and DIRECTION build a 128 bit IV, and IK and IV drive the key stream calculation. Five 32 bit key stream words come out. The message is evaluated with the first two words, multiplied by the next two, truncated, and combined with the last one.

UIA2 and EIA1 use the SNOW 3G key stream only to produce five words. The MAC itself comes from a polynomial evaluation of the message, masked with the last key stream word.

• IV₃ is COUNT and IV₂ is FRESH. IV₁ is DIRECTION in the top bit XOR COUNT, and IV₀ is DIRECTION in a middle bit XOR FRESH.
• IK of 128 bits and IV of 128 bits go into the Key Stream Calculation block.
• z₁ and z₂ form the 64 bit value P, z₃ and z₄ form the 64 bit value Q, and z₅ is the 32 bit OTP.
• MESSAGE goes through Length Padding and then into Eval f_M(P), which evaluates the padded message at the point P.
• The result is multiplied by Q, truncated, and combined with OTP to give the MAC.

OTP stands for one-time pad. It is the last key stream word, and it masks the truncated result, so the same message with a different COUNT gives an unrelated MAC. The detailed field arithmetic is in the ETSI SAGE UEA2 and UIA2 specification. 35.215 v19.0.0 itself only points to that document, so I did not check the operations in the diagram line by line against it.

• Six inputs, one 32 bit output : COUNT-I, FRESH, DIRECTION, IK, LENGTH and MESSAGE go in, and MAC-I comes out.
• FRESH and COUNT both enter the IV : so changing either one changes the whole key stream.
• LTE renames the inputs : IK becomes K_NASint or K_RRCint, and FRESH is built from BEARER.

How to derive FRESH value ?

Just in terms of Algorithm implementation, FRESH is specified as a 32 bit random number. But when SNOW3G is used in EIA1, it is not completely random. It is more like a predefined constant as stated below.

33.401 - B.2.2 128-EIA1 states as follows :

128-EIA1 is based on SNOW 3G and is implemented in the same way as UIA2 as specified in TS 35.215. The used IV is constructed the same way as in subclause 4.4 of that TS, with the only difference being that FRESH [0], … FRESH [31] shall be replaced by BEARER[0] … BEARER[4] ¦ 0..0  (i.e. 27 zero bits)

It means each of the FRESH bit is configured as follows (NOTE : FRESH is 32 bit, but BEARER is 5 bit). NOTE : FRESH[0] is MSB and FRESH[31] is LSB.

FRESH[0] = BEARER[0]

FRESH[1] = BEARER[1]

FRESH[2] = BEARER[2]

FRESH[3] = BEARER[3]

FRESH[4] = BEARER[4]

FRESH[5] = 0

FRESH[6] = 0

FRESH[7] = 0

...

FRESH[30] = 0

FRESH[31] = 0

Then you may ask how to derive BEARER value. 33.401 - 8.1.1 NAS input parameters and mechanism states as follows.

The BEARER identity is not necessary since there is only one NAS signalling connection per pair of MME and UE, but is included as a constant value so that the input parameters for AS and NAS will be the same, which simplifies specification and implementation work.

Also  33.401 - 7.4.3 KeNB* and Token Preparation for the RRCConnectionReestablishment Procedure has following statement  

all BEARER bits shall be set to 1

Putting all the above statement together, we can define FRESH value to be 0xF8000000 for the RRCConnectionReestablishment token as follows :

FRESH[0] = 1

FRESH[1] = 1

FRESH[2] = 1

FRESH[3] = 1

FRESH[4] = 1

FRESH[5] = 0

FRESH[6] = 0

FRESH[7] = 0

...

FRESH[30] = 0

FRESH[31] = 0

Be careful with that value, because it holds only for the token. The NAS case and the RRC case use other BEARER values. 33.401 v19.2.0 clause 8.1.1 says that the NAS BEARER shall equal the constant value 0x00. So FRESH is 0x00000000 for every NAS message.

For RRC messages, the integrity function runs in PDCP. 36.323 v19.0.0 sets BEARER to the radio bearer identity minus 1, as 36.331 numbers the radio bearers. So SRB1 uses BEARER = 0 and SRB2 uses BEARER = 1. The short tokens use all ones. 33.401 clause 7.2.11.3 gives the same rule for the ShortResumeMAC-I of the RRC Connection Resume procedure.

You can check the bit order with the 128-EIA1 test data in 33.401 Annex C.4. Test Set 1 uses Count-I = 38a6f056, Bearer = 1f, Direction = 0 and a message of 88 bits. Bearer 1f is 11111 in binary, so FRESH is 0xF8000000 in that test, the same value as the token case. The expected MACT is 731f1165. An implementation that puts BEARER in the low bits of FRESH instead gets a different MAC for this test set.

• FRESH is not random in EIA1 : it is BEARER in the 5 most significant bits, followed by 27 zero bits.
• The value depends on the use : 0x00000000 for NAS and SRB1, 0x08000000 for SRB2, and 0xF8000000 for the short tokens.
• Test Set 1 checks the bit order : Bearer 1f gives FRESH 0xF8000000 and MACT 731f1165.

Where is SNOW3G used in LTE ?

The same SNOW 3G core appears in LTE twice, once for integrity and once for ciphering. So it helps to know which identifier points to it, and which nodes must support it.

33.401 v19.2.0 clause 5.1.4.2 gives 128-EIA1 the 4 bit identifier 0001, and clause 5.1.3.2 gives 128-EEA1 the same identifier. The network selects the algorithm in the NAS Security Mode Command for NAS and in the AS Security Mode Command for RRC and user plane. UEs, eNBs and MMEs shall implement 128-EIA1 and 128-EIA2 for signalling integrity, while 128-EIA3 is optional. Also 128-EEA1 is identical to UEA2, in the same way that 128-EIA1 follows UIA2.

A later case uses the same algorithm again. When an eNB activates user plane integrity protection with NR PDCP, 33.401 clause 7.3.5 maps 128-EIA1 to the NR algorithm 128-NIA1, with the same identifier 0001. In all of these cases the algorithm is the one in the diagram above. Only KEY, COUNT, BEARER and DIRECTION change from one use to the next.

The COUNT input is built differently for NAS and for RRC. For NAS, 33.401 clause 8.1.1 builds COUNT as 0x00 || NAS OVERFLOW || NAS SQN. The leftmost 8 bits are zero padding, NAS OVERFLOW is a 16 bit counter, and NAS SQN is the 8 bit sequence number carried in each NAS message. For RRC, 36.323 v19.0.0 clause 6.3.5 builds the 32 bit COUNT from a HFN and the PDCP SN. On an SRB the PDCP SN has 5 bits, so the HFN takes the remaining 27 bits.

You can see two of these inputs directly in a decoded security protected NAS message. The Sequence number field is NAS SQN, and the Message authentication code field is the 32 bit NAS-MAC. The UE and the MME never send the rest of COUNT. Each side keeps NAS OVERFLOW locally and increments it when NAS SQN wraps around, so a lost counter state shows up as a failed integrity check.

• 128-EIA1 and 128-EEA1 are SNOW 3G : both carry the identifier 0001.
• Support is mandatory : UEs, eNBs and MMEs shall implement 128-EIA1 for NAS and RRC integrity.
• Only the inputs change : NAS, RRC and user plane use the same algorithm with different KEY, COUNT and BEARER.

Reference

[1] CryptoMobile (GitHub)

[2] Lightweight Security Solutions for LTE/LTE-A Networks

[3] 3GPP TS 33.401 v19.2.0 - clause 5.1.3.2, 5.1.4.2, 7.2.11.3, 7.3.5, 7.4.3, 8.1.1, Annex B.2 and Annex C.4

[4] 3GPP TS 36.323 v19.0.0 - clause 5.7 Integrity protection and verification

[5] 3GPP TS 35.215 v19.0.0 - Specification of the 3GPP confidentiality and integrity algorithms UEA2 and UIA2, Document 1