Content for TS 33.105 Word version: 17.0.0

5.2 Data confidentiality 5.2.1 Overview 5.2.2 Use 5.2.3 Allocation 5.2.4 Extent of standardisation 5.2.5 Implementation and operational considerations 5.2.6 Type of algorithm 5.2.7 Interfaces to the algorithm
...

5.2 Data confidentiality p. 14

5.2.1 Overview p. 14

The mechanism for data confidentiality of user data and signalling data that is described in clause 6.6 of TS 33.102 requires the following cryptographic function:

f8 UMTS encryption algorithm.

Figure 5 illustrates the use of f8 to encrypt plaintext by applying a keystream using a bitwise XOR operation. The plaintext may be recovered by generating the same keystream using the same input parameters and applying it to the ciphertext using a bitwise XOR operation.

Copy of original 3GPP image for 3GPP TS 33.105, Fig. 5: Ciphering user and signalling data transmitted over the radio access link

Figure 5: Ciphering user and signalling data transmitted over the radio access link
(⇒ copy of original 3GPP image)

The input parameters to the algorithm are the Cipher Key (CK), a time dependent input (COUNT-C), the bearer identity (BEARER), the direction of transmission (DIRECTION) and the length of the keystream required (LENGTH). Based on these input parameters the algorithm generates the output keystream block (KEYSTREAM) which is used to encrypt the input plaintext block (PLAINTEXT) to produce the output ciphertext block (CIPHERTEXT).

The input parameter LENGTH shall affect only the length of the KEYSTREAM BLOCK, not the actual bits in it.

5.2.2 Use p. 14

The function f8 shall only be used to protect the confidentiality of user data and signalling data sent over the radio access link between UE and RNC.

5.2.3 Allocation p. 15

The function f8 is allocated to the UE and the RNC.

Encryption will be applied in the Medium Access Control (MAC) sublayer and in the Radio Link Control (RLC) sublayer of the data link layer (Layer 2).

5.2.4 Extent of standardisation p. 15

The function f8 shall be fully standardized.

5.2.5 Implementation and operational considerations p. 15

The algorithm should be designed to accommodate a range of implementation options including hardware and software implementations. For hardware implementations, it should be possible to implement one instance of the algorithm using less than 10,000 gates (working assumption).

A wide range of UE with different bearer capabilities is expected, so the encryption throughput requirements on the algorithm will vary depending on the implementation. However, based on the likely maximum user traffic data rates, it must be possible to implement the algorithm to achieve an encryption speed in the order of 2Mbit/s on the downlink and on the uplink.

RLC-transparent mode:
- New keystream block required every physical layer frame (10ms)
- Maximum number of bits per physical layer frame of 20000 bits
- Minimum number of bits per physical layer frame of 1 bit
- Granularity of 1 bit on all possible intermediate values.
For UM RLC mode:
- New keystream block required per UMD PDU
- Maximum number of bits in UMD PDU is 5000 bits
- Minimum number of bits in UMD PDU is 16 bits
- Granularity of 8 bit on all possible intermediate values.
For AM RLC mode:
- New keystream block required per AMD PDU
- Maximum number of bits in AMD PDU is 5000 bits
- Minimum number of bits in AMD PDU is 24 bits
- Granularity of 8 bit on all possible intermediate values.

The encryption throughput requirements should be met based on clock speeds upwards of 20MHz (typical clock speeds are expected to be much greater than this).

5.2.6 Type of algorithm p. 15

The function f8 should be a symmetric synchronous stream cipher.

5.2.7 Interfaces to the algorithm p. 16

5.2.7.1 CK p. 16

CK: the cipher key

CK[0], CK[1], …, CK[127]

The length of CK is 128 bits. In case the effective key length k is smaller than 128 bits, the most significant bits of CK shall carry the effective key information, whereas the remaining, least significant bits shall repeat the effective key information:

CK[n] = CK[n mod k], for all n, such that k ≤ n < 128.

5.2.7.2 COUNT-C p. 16

COUNT-C: the cipher sequence number.

COUNT-C[0], COUNT-C[1], …, COUNT-C[31]

The length of the COUNT-C parameter is 32 bits.

Sychronisation of the keystream is based on the use of a physical layer (Layer 1) frame counter combined with a hyperframe counter introduced to avoid re-use of the keystream. This allows the keystream to be synchronised every 10ms physical layer frame. The exact structure of the COUNT-C is specified in TS 33.102.

5.2.7.3 BEARER p. 16

BEARER: the radio bearer identifier.

BEARER[0], BEARER[1], …, BEARER[4]

The length of BEARER is 5 bits.

The same cipher key may be used for different radio bearers simultaneously associated with a single user which are multiplexed onto a single 10ms physical layer frame. To avoid using the same keystream to encrypt more than one bearer, the algorithm shall generate the keystream based on the identity of the radio bearer.

5.2.7.4 DIRECTION p. 16

DIRECTION: the direction of transmission of the bearer to be encrypted.

DIRECTION[0]

The length of DIRECTION is 1 bit.

The same cipher key may be used for uplink and downlink channels simultaneously associated with a UE, which are multiplexed onto a single 10ms physical layer frame. To avoid using the same keystream to encrypt both uplink and downlink transmissions, the algorithm shall generate the keystream based on the direction of transmission.

The value of the DIRECTION is 0 for messages from UE to RNC and 1 for messages from RNC to UE.

An explicit direction value is required in preference to splitting the keystream segment into uplink and downlink portions to allow for asymmetric bearer services.

5.2.7.5 LENGTH p. 17

LENGTH: the required length of keystream.

LENGTH[0], LENGTH[1], …, LENGTH[15]

The length of LENGTH is 16 bits.

For a given bearer and transmission direction the length of the plaintext block that is transmitted during a single physical layer frame may vary. The algorithm shall generate a keystream block of variable length based on the value of the length parameter.

The input parameter LENGTH shall affect only the length of the KEYSTREAM BLOCK, not the actual bits in it.

The maximum RLC PDU / MAC SDU size is 5000 bits. The range of values of the length parameter will depend not only on the RLC PDU / MAC SDU size but also the number of RLC PDUs / MAC SDUs which may be sent in a single physical layer 10ms frame for a given bearer and transmission direction.

Not all values between the maximum and minimum values shall be required but it is expected that the ability to produce length values of whole numbers of octets between a minimum and a maximum value will be required.

5.2.7.6 KEYSTREAM p. 17

KEYSTREAM: the output keystream.

KS [0], KS [1], …, KS [LENGTH-1]

The length of a keystream block equals the value of the input parameter LENGTH.

5.2.7.7 PLAINTEXT p. 17

PLAINTEXT: the plaintext.

PT[0], PT[1], …, PT[LENGTH-1]

The length of a keystream block equals the value of the input parameter LENGTH.

This plaintext block consists of the payload of the particular RLC PDUs / MAC SDUs to be encrypted for a given bearer and transmission direction. It may consist of user traffic or signalling data:

For RLC UM mode, the plaintext block is the UMD PDU excluding the first octet, i.e. excluding the RLC UM PDU header (see TS 25.322).
For RLC AM mode, the plaintext block is the AMD PDU excluding the two first octets, i.e. excluding the RLC AM PDU header (see TS 25.322).
For RLC TM on DCH, the plaintext block consists of all the MAC SDUs containing data for one and the same radio bearer and sent in one Transmission Time Interval. In this case, the CFN part of COUNT-C for the plaintext block is the CFN for the first radio frame of the Transmission Time Interval containing the plaintext block. (see TS 25.321).

5.2.7.8 CIPHERTEXT p. 17

CIPHERTEXT: the ciphertext.

CT[0], CT[1], …, CT[LENGTH-1]

The length of a keystream block equals the value of the input parameter LENGTH.