. 82
( 132 .)


ity of a match will occur after half the keys have been tried. A key length of 128 bits
generates enough possible keys (2128 ) that it would take an unrealistic length of time
to crack. The addition of one extra bit to the key length doubles the number of keys
available. Of course, attacks can be made in other ways, by looking for weaknesses in

the algorithms used. Any secure system should provide for the following framework for
user protection:

• Privacy: ensures that only authorized individuals can read the information.
• Authentication: proves the identity of the message sender.
• Data integrity: ensures data cannot be altered without detection.
• Non-repudiation: undeniably proves that a message was sent, usually including when
it was sent.

From GSM, the following services are retained:

• user authentication
• radio interface encryption
• user identity con¬dentiality
• independent hardware security module (SIM).

However, the following areas have been shown to be weak in GSM:

• no network authentication, hence attack by a ˜false BTS™ is not prevented;
• keys and authentication data are not protected either within or between networks;
• the encrypted relationship is only between the mobile device and the BTS, therefore
data is in plain text beyond the BTS. Often, this data is sent across microwave links
between the BTS and the BSC;
• GSM security algorithms have already been broken;
• there is no provision of a data integrity mechanism;
• the security mechanisms are ¬xed and do not have the ¬‚exibility to be upgradable.

The UMTS architecture addresses all of these issues. The basic services provided are
detailed in the succeeding sections. UMTS does not specify particular algorithms that must
be used, but rather includes a default chosen set of tried and trusted algorithms within
a framework that allows for other algorithms to be introduced. The algorithms included
within the speci¬cations are the f8 ciphering and f9 integrity algorithms, both based on
the Kasumi block cipher algorithm. Kasumi also forms the basis of the A5/3 encryption
algorithm, which has recently been introduced retrospectively to GSM. Unlike the security
algorithms used in GSM, which were developed in secret, the Kasumi algorithm is well
de¬ned and has thus been exposed to the rigours of testing among the broader community.
The Kasumi algorithm, is a variant of the MISTY algorithm, which was developed by
Mitsubishi in 1995.
User protection in the mobile device is provided on the USIM. A user can protect access
to the USIM by using a user-de¬ned password, which must be entered at power-on to
activate the card. The USIM is housed in a UMTS integrated circuit card (UICC), as is

done currently with GSM. This card, which contains the user master key, is designed as
a tamper-proof module which prevents direct access to data stored within.

6.21.1 User identity con¬dentiality
In UMTS this relates not only to the identity of the user, that is the IMSI, but now also to
the location of the user. The method to provide the former is to use temporary identities,
such as the TMSI/P-TMSI, as much as possible. Obviously this is not available the ¬rst
time a user accesses the network; however, subsequently the temporary identity will be
used. In addition, once the security relationship has been established, the network may
periodically reallocate this temporary identity so as to avoid use of the same identity for
a long period of time. Any signalling messages that could potentially reveal the identity
of the user are encrypted.

6.21.2 Authentication
UMTS provides for the mutual authentication of both user and network. This process
ensures that not only is the network ensured that only authorized users can access, but
also that users validate that the network to which they are connecting is authorized by
the user™s home network. This may not seem initially such a major point, since in a GSM
context, the economy of scale is not present for a would-be snooper to acquire a BTS to
eavesdrop on user conversations. However, for the 3G framework, many different radio
access technologies can be integrated into the system. This means that in the future, a
wireless LAN access point could be providing user access to their services.
The authentication procedure ¬‚ows as shown in Figure 6.119. Once a new user attempts
to access the network, for example to perform a location update, the VLR/SGSN will send
an authentication request to the HLR/AuC, identifying the user by its IMSI. The HLR will
then use the user key, K, to generate a set of n authentication vectors, which it returns to
the VLR/SGSN. An authentication vector consists of the following components:

• random number, RAND
• expected response, XRES
• cipher key, CK
• integrity key, IK
• authentication token, AUTN.

The generation of this vector is explained below. The rationale for generating multiple
vectors is that subsequent user authentication requests can be handled at the VLR/SGSN
without recourse to the home environment. The VLR/SGSN can take the next vector from
the set it has stored.
Now the VLR/SGSN sends an authentication request to the user, containing just the
RAND and AUTN components. The user USIM uses the AUTN value to validate that the


Authentication Request

Generate n
authentication vectors

Authentication Response

store authentication
vectors & select next
User Authentication Request

verify AUTN
calculate RES

User Authentication Response

compare RES and XRES
select CK and IK
select CK and IK

Figure 6.119 UMTS authentication procedure

network is trusted, and calculates its result using the RAND and its key, K. The USIM
also uses the AUTN to generate the keys CK and IK. This result, RES, is sent back to
the VLR/SGSN, which compares it to the expected result, XRES, and, if matching, thus
validates the user on the network. Both the USIM and the VLR/SGSN then distribute the
generated keys to the relevant units that will be performing the encryption and integrity
functions. In the case of the VLR/SGSN, this is the SRNC.
The mechanism used in the HLR/AuC to generate the authentication vectors is as shown
in Figure 6.120. First, the HLR/AuC generates a sequence number, SQN, and a random
number, RAND. The sequence number will increment for each new authentication vector.
These are then used with the user key, K, authentication algorithms (f1, f2) and key gen-
eration algorithms (f3“f5) to generate the authentication vector ¬elds. The authentication
token, AUTN, is:

where || means concatenation, and each whole vector, AV, is:


The use of f5 is to protect the sequence number by using an anonymity key, AK. If
this level of protection is not required, then f5 = 0. The authentication and key manage-
ment ¬eld, AMF, can be used to provide services such as support for multiple security

Generate SQN

Generate RAND


f2 f3 f4 f5


Figure 6.120 Authentication vector generation

algorithms. Upon receipt of the RAND||AUTN ¬eld, the USIM uses a similar process
with the same key and algorithms to extract the relevant ¬elds.

6.21.3 Security mode establishment
The entire procedure to establish a secure relationship between a user and the network
is shown in Figure 6.121. Section 6.16.3 showed how an initial signalling connection is
established, and it was seen that the UE responds to the RRC connection setup message
with an RRC connection setup complete message. This message contains all the UE capa-
bilities and includes the supported algorithms for both integrity protection (UMTS integrity
algorithm, UIA) and encryption (UMTS encryption algorithm, UEA). Also included is a
value called START, which is a 20-bit ¬eld stored in the USIM and passed to the mobile
device at power on. This start value is used by the RNC as the most signi¬cant bits of a
counter for subsequent messages, referred to as a hyperframe number (HFN). The reason
this is used is that the standard sequence numbers, for example those used by RRC and
RLC, are not long enough to prevent replays, where old sequence numbers are reused at
some point later in time.
The initial L3 message, which could be, for example, a location update request or a
GPRS attach request, prompts the authentication procedure as described above.
After the authentication procedure has completed, the VLR/SGSN makes a decision
of which integrity and encryption algorithms to use (UIA/UEA) in order of preference,
and issues this information to the SRNC, along with the respective keys, IK and CK, in
the RANAP security mode command. The SRNC compares the selected UIA/UEAs to
those that the UE is capable of, and selects the highest priority match. The UE is then
informed of this choice through the RRC security mode command, which also contains a
random value, FRESH, generated by the SRNC. Attached to this message is the message
authentication code for integrity (MAC-I) ¬eld, which enables the UE to validate that
the message has come from a trusted source, and has not been altered en route. The
UE veri¬es acceptance of the security mode with the RRC security mode complete and


RRC Connection Setup Complete

Storage of HFN and UE
security capability

Initial L3 message

Authentication and key generation procedure

Decision of permitted
RANAP Security mode command

Select UIA/UEA
Generate FRESH
Start integrity protection
RRC Security mode command

Verify message
RRC Security mode complete

Verify message
RANAP Security mode complete

Secure communication

Figure 6.121 Security mode establishment procedure

the entire procedure completes with the transfer of the RANAP security mode complete
message to the core network. There now exists a secure relationship between the UE
and RNC, where all transfers of both control and data can be both integrity checked
and encrypted.
The procedure for generating an integrity check authentication ¬eld for a message is
shown in Figure 6.122. The message is passed in to the f9 algorithm with the integrity
key (IK).
On receipt of a signalling message, the message authentication ¬eld (MAC-I) can be
checked to verify it came from the correct user, and has not been tampered with.
The other components of the integrity check are as follows:

• Count-I: a 32-bit counter, which is incremented for each new signalling messages, so
message sequences can be checked. The format of count-I is as shown in Figure 6.123.
The RRC HFN is initialized by placing the START value in the most signi¬cant 20 bits,
and padding the remaining 8 bits with 0. The lower 4 bits are the sequence numbers

Message COUNT-I Direction

IK f9



. 82
( 132 .)