User Data Confidentiality – Encryption

The purpose of user data encryption is to ensure the confidentiality and privacy of user data
on physical connections by preventing its availability or disclosed to unauthorised
individuals, entities or processes.
Encryption will normally be applied to all voice and non-voice communications. Although a
standard algorithm (A5) will normally be employed, it is permissible for the mobile station
and/or PLMN infrastructure to support more than one algorithm. In this case, the
infrastructure is responsible for deciding which algorithm to use (including the possibility not
to use encryption, in which case confidentiality is not applied).
When encryption is requested, the MS signals to the network indicating which of up to seven
ciphering algorithms it supports (see GSM 02.07). The serving network then selects one of
these and signals this to the MS. The selected algorithm is then used by the MS and network.

User Data Encryption

• Benefits of user data encryption include:
• Provides confidentiality for user data across air interface
• Selection from seven encryption algorithms
• Capability is mandatory for MS and network
• Implementation is optional
• Does not provide for end-to-end encryption

Ciphering Key Sequence Number (CKSN)
In order to allow ciphering to commence on a RR connection without authentication (for
example after an MSC failure) ciphering key sequence numbers are used. The sequence
number is managed by the network in the way that the AUTHENTICATION REQUEST
message contains the sequence number allocated to the key which may be computed from the
RAND parameter carried in that message.

The Mobile Station stores this number with the key, and indicates to the network in the first
message (LOCATION UPDATING REQUEST, CM SERVICE REQUEST, PAGING
RESPONSE, CM REESTABLISHMENT REQUEST) which sequence number the stored key
has. When the deletion of the sequence number is described this also means that the
associated key shall be considered as invalid.
In certain circumstances, the network can start ciphering with the stored key if the CKSN
associated with that key is the same as CKSN stored with the key in the MS.

STEP 1 – Determining the A5 Algorithm
Assuming authentication has already taken place, when an MS wishes to establish an
encrypted connection to the network, the A5 algorithm is first negotiated on the DCCH
channel in accordance with the following priorities:
1. If the MS and the network have no common versions of the A5 algorithm and the
network and/or MS is not prepared to use an unencrypted connection, then the
connection is released.
2. If the MS and the network have at least one version of the A5 algorithm in common,
then the network selects one of the mutually acceptable versions for use on that
connection.
3. If the MS and the network have no common versions of the A5 algorithm and the
network is willing to use an unencrypted connection, then an unencrypted
connection is established.
STEP 2 – Kc Key Generation
Using the Ki key, unique to each MS, and the RAND generated by the AuC, the Kc is
generated at both the MS and AuC. The AuC Kc key is passed to the MSC/VLR along with
the RAND and SRES as part of each Triplet.

STEP 3 – Transition to Cipher Mode
Encrypted data is produced by passing the Kc key and the clear user data through the A5
algorithm, stored in both the MS and BSS. The transition from clear mode to ciphered mode
proceeds as follows:
· deciphering starts in the BSS, which sends a clear text ‘Start Cipher’ message to the
MS
· Once this message has been received correctly, both the enciphering and deciphering
start on the MS side.
· Enciphering on the BSS side starts as soon as synchronisation has been achieved and
an encrypted MS-generated frame or a message has been correctly deciphered at the
BSS
When a TCH is allocated for user data transmission, the key used for TCH encryption is the
one set during the preceding DCCH session (Call Set-up). The enciphering and deciphering
processes start immediately.
Handover Requirements
When a handover occurs, the necessary information (e.g. key Kc, initialisation data) is
transmitted within the system infrastructure to enable the communication to proceed from the
old BSS to the new one, and the Synchronisation procedure is resumed. The key Kc remains
unchanged at handover.