UMTS Security / Edition 1

Hardcover (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $39.92
Usually ships in 1-2 business days
(Save 73%)
Other sellers (Hardcover)
  • All (7) from $39.92   
  • New (4) from $109.24   
  • Used (3) from $39.92   


UMTS (Universal Mobile Telecommunication System) systems are third-generation systems designed for multimedia communication. UMTS Security covers the security aspects of third-generation mobile networks based on WCDMA technology. WCDMA (Wideband Code Division Multiple Access) is the main air interface used for third generation mobile communication systems. UMTS (Universal Mobile Telecommunication System) will offer a consistent set of services to mobile computer and phone users and numerous different radio access technologies may co-exist within the UMTS system's core network. Network security is, therefore, of the utmost importance. UMTS Security brings together material previously only available in specifications, design documents and presentations in one concise form. It is intended to provide a self-contained treatment of the security issues involved and ranges from introductory material to detailed discussions of advanced topics. It will present features and background information that existing experts in the field will find informative. Provides a detailed description of UMTS security architecture Explains the security principles behind UMTS security Includes detailed descriptions of the cryptographic solutions in UMTS Presents the theoretical background and the design process of the UMTS cryptographic algorithms Discusses the new security features to be included in future releases Examines other wireless security solutions Essential reading for UMTS network security & wireless specialists, operators and manufacturers, wireless network researcher, academics and postgraduate students, security engineers, researchers and consultants.

Read More Show Less

Product Details

  • ISBN-13: 9780470847947
  • Publisher: Wiley
  • Publication date: 1/9/2004
  • Edition number: 1
  • Pages: 286
  • Product dimensions: 6.87 (w) x 9.96 (h) x 0.85 (d)

Table of Contents

Preface xi


1 Introduction to Security and to UMTS 3

1.1 Security in Telecommunications 3

1.1.1 General security principles 4

1.1.2 GSM security 7

1.2 The Background to 3G 11

1.3 The 3G Partnership Project (3GPP) 12

1.4 3GPP Network Architecture 14

1.4.1 Elements in the architecture 15

1.4.2 Protocols in the 3GPP system 18

1.5 WCDMA Radio Technology 20

1.5.1 CDMA: an example 22

1.5.2 Basic facts of WCDMA 23

1.5.3 Handovers 25

1.5.4 Power control 25

2 UMTS Security Features in Release 1999 29

2.1 Access Security to UMTS 29

2.1.1 Mutual authentication 30

2.1.2 Temporary identities 42

2.1.3 UTRAN encryption 44

2.1.4 Integrity protection of RRC signalling 54

2.1.5 Set-up of UTRAN security mechanisms 59

2.1.6 Summary of access security in the CS and PS domains 63

2.2 Interworking with GSM 63

2.2.1 Interworking scenarios 65

2.2.2 Cases with SIM 66

2.2.3 Cases with USIM 67

2.2.4 Handovers from one system to another 68

2.3 Additional Security Features in Release 1999 69

2.3.1 Ciphering indicator 69

2.3.2 Identification of the UE 69

2.3.3 Security for Location Services (LCs) 70

2.3.4 User-to-USIM authentication 70

2.3.5 Security in the USIM application toolkit 70

2.3.6 Mobile Execution Environment (MExE) 70

2.3.7 Lawful interception 71

3 Security Features in Releases 4 and 5 73

3.1 Network Domain Security 73

3.1.1 MAPsec 74

3.1.2 IPsec 81

3.1.3 IPsec-based mechanisms in UMTS 84

3.1.4 Role of firewalls 86

3.2 IMS Security 87

3.2.1 Basics of SIP 87

3.2.2 IMS architecture 90

3.2.3 Architecture for securing access to the IMS 91

3.2.4 Principles for IMS access security 93

3.2.5 Use of HTTP Digest AKA 95

3.2.6 Security mode set-up 100

3.2.7 Integrity protection with ESP 101

3.2.8 Error case handling 104

3.3 Other Security Systems 106

3.3.1 Higher layer security systems 106

3.3.2 Link layer security systems 108


4 Introduction to Cryptography 113

4.1 The Science of Cryptology 113

4.1.1 Cryptographic systems 113

4.1.2 Security and vulnerability 115

4.1.3 Developing cryptology into a publicly available science 116

4.1.4 Public cryptographic development efforts 118

4.2 Requirements and Analysis of Cryptographic Algorithms 119

4.2.1 Block ciphers 120

4.2.2 Stream ciphers 125

4.2.3 Message authentication codes 127

5 3GPP Algorithm Specification Principles 131

6 Confidentiality and Integrity Algorithms 135

6.1 Requirements for the Confidentiality Algorithm 135

6.1.1 Functional requirements 135

6.1.2 Algorithm operation 136

6.1.3 Interfaces to the algorithm 137

6.2 Requirements for the Integrity Algorithm 139

6.2.1 Overview 139

6.2.2 Interface 140

6.3 Design Task Force 142

6.4 Getting Started 142

6.4.1 SAGE contribution to SA3 143

6.4.2 Modes around MISTY1 143

6.4.3 Particular security criteria 144

6.5 Design Process 144

6.5.1 The teams 145

6.5.2 Design documentation 145

6.5.3 Conclusion of evaluation 148

6.6 Confidentiality Algorithm 149

6.6.1 The f8 stream cipher mode 149

6.6.2 Description of f8 149

6.6.3 Security 151

6.7 Extension of the UMTS Confidentiality Algorithm 152

6.7.1 Background 152

6.7.2 List of variables 153

6.7.3 Core function KGCORE 154

6.7.4 A5/3 algorithm for GSM encryption 157

6.7.5 A5/3 algorithm for ECSD encryption 158

6.7.6 GEA3 algorithm for GPRS encryption 160

6.7.7 Specification of the 3GPP confidentiality algorithm f8 161

6.7.8 Summary of the confidentiality functions 162

6.8 Integrity Algorithm 163

6.8.1 The f9 MAC mode 163

6.8.2 Description 164

6.8.3 Security 165

6.9 Implementation 168

6.9.1 Length of data 168

6.10 IPR Issues and Exportability 169

6.10.1 IPR issues 169

6.10.2 Exportability 169

7 Kernel Algorithm KASUMI 171

7.1 Introduction 171

7.2 MISTY Block Cipher Algorithms 172

7.2.1 Design principles of MISTY1 172

7.2.2 Security of MISTY 176

7.3 Changes between MISTY1 and KASUMI 178

7.3.1 Changes to the data encryption part 178

7.3.2 Changes to the key-scheduling part 179

7.4 Description of KASUMI 179

7.4.1 General structure 179

7.4.2 KASUMI encryption function 181

7.4.3 Key schedule 187

7.5 Mathematical Analysis of KASUMI by the Task Force 188

7.5.1 Properties of components 188

7.5.2 Differential cryptanalysis 192

7.5.3 Truncated differentials 195

7.5.4 Linear cryptanalysis 196

7.5.5 Higher order differential attacks 196

7.6 Public Research on KASUMI 197

7.7 Implementation issues 198

7.7.1 Parallel operation 198

7.7.2 Implementation attacks 199

8 Authentication and Key Generation Algorithm 201

8.1 Design Task Force 201

8.2 Requirements 202

8.2.1 Authentication specification 202

8.2.2 Functional requirements for UMTS authentication 205

8.2.3 General requirements 209

8.2.4 Additional requirements from SA3 209

8.3 Design Process 210

8.3.1 Work plan 210

8.3.2 SAGE’s contribution to the UMTS security architecture 212

8.3.3 Cryptographic requirements 213

8.3.4 Operator-variant algorithm configuration field 214

8.3.5 Criteria for the cryptographic kernel 214

8.4 Description of the Modes 216

8.4.1 The algorithm framework 216

8.4.2 Notation 216

8.4.3 Specification of the modes 217

8.5 The MILENAGE Architecture 219

8.5.1 Use of OP 220

8.5.2 Rotation and offset constants 220

8.5.3 Protection against side-channel attacks 220

8.5.4 The number of kernel operations 220

8.5.5 Modes of operation 221

8.6 Kernel Algorithm 221

8.6.1 Block ciphers versus hash functions 221

8.6.2 The kernel of MILENAGE 223

8.7 Customization Options 224

8.7.1 Operator variant parameter 224

8.7.2 Kernel algorithm 225

8.7.3 Rotation and offset parameters 225

8.7.4 Length of RES 226

8.8 Conversion to and Compatibility with A3/A8 226

8.8.1 Conversion rules 227

8.8.2 GSM–MILENAGE 228

8.9 Security analysis of MILENAGE 230

8.9.1 Assumptions and security claims 230

8.9.2 Operational context 231

8.9.3 The soundness of the f2–f5* construction 232

8.9.4 Soundness of the f1–f1* construction and its cryptographic separation from the other modes 234

8.9.5 Investigation of forgery or distinguishing attacks with 264 queries 236

8.9.6 Conclusions 240

Notation of Parameters, Sets and Functions 243

Abbreviations 249

References 257

Index 267

Read More Show Less

First Chapter

UMTS Security

By Valtteri Niemi Kaisa Nyberg

John Wiley & Sons

ISBN: 0-470-84794-8

Chapter One

UMTS Security Features in Release 1999

2.1 Access Security to UMTS

Radio access technology will change from TDMA (Time Division Multiple Access) to WCDMA (Wideband Code Division Multiple Access) when the Third Generation (3G) mobile networks are introduced. Despite this shift, requirements for access security will not change. It is an absolute prerequisite of UMTS (Universal Mobile Telecommunications System) that end-users of the system are authenticated (i.e., the identity of each subscriber is verified): nobody wants to pay for fraudulent calls that are made by others.

The confidentiality of voice calls is protected in the Radio Access Network (RAN), as is the confidentiality of transmitted user data. This means that the user has control over choosing the parties he or she wants to communicate with. Users also want to know that confidentiality protection is really applied and so visibility of applied security mechanisms is needed. Privacy of a user's whereabouts is generally appreciated; most of the time an average citizen does not care whether it is possible to trace where he or she is, but if persistent tracking occurs the user would rightly be irritated. Similarly, precise information about the location of people would be useful to burglars. The privacy of user data is another issue that is critical during transfer through thenetwork (privacy and confidentiality are largely synonymous in this presentation).

UMTS accessibility is clearly important for subscribers who are paying for it, but network operators consider reliability of network functionality to be equally important: they need control within network functions to be effective. This is guaranteed by the integrity of radio network signalling, which checks that all control messages have been created by authorized elements of the network. In general, integrity checking protects against any manipulation of a message (e.g., insertion, deletion or substitution).

The most important ingredient in providing security for network operators and subscribers is cryptography, which consists of various techniques that have their roots in the science and art of secret writing. It is sometimes useful to make communication deliberately incomprehensible (i.e., using ciphers or, synonymously, encryption). This is the most effective way to protect communications against eavesdroppers. Cryptographic issues are thoroughly discussed in Part II.

In the present chapter, we go through the security features introduced in the first release of the 3GPP system specifications (Release 1999).

2.1.1 Mutual authentication

There are three entities involved in the authentication mechanism of the UMTS system:

Home Environment (HE);

Serving Network (SN);

terminal, more specifically USIM (Universal Subscriber Identity Module), typically in a smart card.

The basic idea is that the SN checks the subscriber's identity (as in GSM-Global System for Mobile communications) by a challenge-and-response technique while the terminal checks that the SN has been authorized by the home network to do so. The latter part is unique to UMTS (not available with GSM) and through it the terminal can check that it is connected to a legitimate network.

The mutual authentication protocol itself does not prevent the active attack scenario of Figure 1.1, but in combination with other security mechanisms it guarantees that the active attacker cannot get any real benefit out of the situation. The only possible gain for the attacker is to be able to disturb the connection (but an attacker could also do this by means of radio-jamming). At the moment no protocol method can circumvent such an attack.

The cornerstone of the authentication mechanism is a master key or a subscriber authentication key K, which is shared between the USIM of the user and the home network database, Authentication Centre (AuC). The key is permanently kept secret and has a length of 128 bits. The key K is never transferred from these two locations (i.e., the user has no knowledge of the master key).

Apart from mutual authentication, keys for encryption and integrity checking are also derived. These are temporary keys (with the same length of 128 bits) and are derived from the permanent key K during every authentication event. It is a basic principle in cryptography to keep the use of permanent keys to a minimum and, instead, derive temporary keys from it for protection of bulk data.

We now describe the Authentication and Key Agreement (AKA) mechan ism at a general level. The design of the mechanism was begun by combining two different authentication mechanisms: GSM's authentication and key agreement mechanism and a generic authentication mechanism based on sequence numbers specified in an ISO standard.

The authentication procedure begins when the user is identified in the SN. Identification occurs when the identity of the user (i.e., permanent identity International Mobile Subscriber Identity (IMSI), or temporary identity Temporary Mobile Subscriber Identity (TMSI), or Packet TMSI (P-TMSI)), has been transmitted to the VLR (Visitor Location Register)or SGSN (Serving GPRS Support Node). Then the VLR or SGSN sends an authentication data request to the AuC in the home network.

The AuC contains the master key of each user and, based on the knowledge of IMSI, the AuC is able to generate authentication vectors for the user. The generation process contains executions of several cryptographic algorithms, which are described in more detail in Chapter 8. The generated vectors are sent back to the VLR/SGSN in the authentication data response. This process is depicted in Figure 2.1. These control messages are carried on the MAP (Mobile Application Part) protocol .

In the SN, one authentication vector is needed for each authentication instance (i.e., for each run of the authentication procedure). This means that the (potentially-long distance) signal ling between SN and AuC is not needed for every authentication event and that in principle this signalling can be done independently of user actions after initial registration. Indeed, the VLR/SGSN may fetch new authentication vectors from AuC well before the number of stored vectors runs out.

The SN (VLR or SGSN) sends a user authentication request to the terminal, containing two parameters from the authentication vector, called RAND and AUTN. These parameters are transferred to the USIM, which exists inside a tamper-resistant environment (i.e., in the Universal Integrated Circuit Card-UICC). The USIM contains the master key K and, using it with the RAND (random number) and AUTN (authentication token) parameters along with other input values, USIM carries out a computation that resembles the generation of authentication vectors in AuC. This process also involves running several algorithms, just as in the corresponding AuC computation. The result of the computation gives the USIM the ability to verify whether the AUTN parameter:

was indeed generated in AuC;

was not sent beforehand to the USIM.

In the positive case, the computed RES parameter is sent back to the VLR/SGSN as part of the user authentication response. Now, the VLR/SGSN is able to compare the user response (RES) with the expected response (XRES), which is part of the authentication vector. If they match, authentication ends positively. This part of the process is depicted in Figure 2.2.

The keys for Radio Access Network (RAN) encryption and integrity protection (namely, Cipher Key (CK) and Integrity Key (IK)) are created as a by-product in the authentication process. These temporary keys are included in the authentication vector and, thus, are transferred to the VLR/SGSN. These keys are later transferred to the Radio Network Controller (RNC) in the RAN when encryption and integrity protection start. Respectively, the USIM is able to compute the CK and IK after it has obtained the RAND (and verified it through the AUTN). Temporary keys are subsequently transferred from USIM to the Mobile Equipment (ME) where the encryption and integrity protection algorithms are implemented.

In the following sections we take a more detailed look at the mechanisms needed for authentication and key agreement. Authentication vector generation

We now take a closer look at the generation of authentication vectors in the AuC. An illustration of the process is given in Figure 2.3. The process begins by picking an appropriate sequence number (SQN). Roughly speaking, what is required is that SQNs are chosen in ascending order. A more detailed description about how to create SQNs is given in Section The purpose of the SQN is to provide the user (or more technically the USIM) with proof that the generated authentication vector is fresh (i.e., it has not been used before in an earlier run of authentication). In parallel with the choice of SQN, a 128-bit long RAND is generated. This is a demanding task in itself, but in this presentation we just assume that a cryptographic pseudorandom generator is in use that is able to produce large amounts of unpredictable output bits, when a good physical random source is available to produce smaller amounts of random bits that can be used as an input (seed) for the pseudorandom generator.

The key concept in authentication vector computation is a mathematical function, called one-way function, which is relatively easy to compute but practically impossible to invert. In other words, as long as we have input parameters there exists a fast algorithm to compute output parameters, but if the output parameters are not known, then there exist no efficient algorithms to deduce any input that would produce the output. Of course, there is a simple algorithm, called the exhaustive search algorithm, that can be used to find the correct input by trying all possible choices until one gives the requisite output. However, this algorithm quickly becomes extremely inefficient as the length of input increases.

In total, five one-way functions are used to compute the authentication vector. These functions are denoted by f1, f2, f3, f4 and f5. The function f1 differs from the other four in that it takes four input parameters: master key K, RAND, SQN and finally an administrative Authentication Management Field (AMF). All other functions from f2 to f5 only take K and RAND as inputs. The requirement of the one-way property is common to all functions f1-f5. They can all be built around the same core function. However, it is essential that they differ from each other in a fundamental way so that the output of one function reveals no information about the outputs of the other functions. The output of f1 is Message Authentication Code (MAC) (64 bits) and the outputs of f2, f3, f4 and f5 are, respectively, XRES (32-128 bits), CK (128 bits), IK (128 bits) and AK (64 bits). The authentication vector consists of the parameters RAND, XRES, CK, IK and the authentication token (AUTN). The last one is obtained by concatenating three different parameters: SQN added bit by bit to AK, AMF and MAC. All of the functions involved in the AKA procedure are studied in detail in Chapter 8 of this book. Authentication on the USIM side

We now take a closer look into the handling of authentication on the USIM side (illustrated in Figure 2.4). The same functions f1-f5 are involved on this side but in a slighty different order. The function f5 has to be computed before the f1, since f5 is used to conceal the SQN. This concealment is needed in order to prevent eavesdroppers from getting information about the user identity through the SQN. The output of the function f1 is marked XMAC (or XMAC-A) on the user side. This is compared with the MAC received from the network as part of the parameter AUTN. If there is a match it implies RAND and AUTN have been created by some entity that knows K (i.e., the AuC of the user's home network).

Of course, there is still the possibility that some attacker who has recorded an earlier authentication event could ascertain the RAND and AUTN. However, as mentioned above, the SQN protects against this threat. The USIM should simply check that it has not seen the same SQN before, and the easiest way to do this is to require that SQNs appear in ascending order. It is also possible for the USIM to allow some SQNs to arrive out of order (e.g., by maintaining a shortlist of the greatest SQNs received so far). In the next sections we will take a closer look at this issue.

Since the transfer of authentication vectors from the AuC and the actual use of these vectors for authentication are done somewhat independently, there are several reasons why it is possible that authentication vectors may be used in a different order from which they were originally generated. The most obvious reason for this is because of the fact that mobility management functions for the CS (Circuit Switched) and PS (Packet Switched) domain are independent of each other, implying that authentication vectors are fetched to the VLR and SGSN independently of each other and that the vectors are also used independently.

The choice of algorithm (f1-f5) is in principle operator-specific, because they are only used in the AuC and in the USIM and the same home operator controls both of these entities. An example set of algorithms (called MILENAGE) exists in the Third Generation Partnership Project (3GPP) specification TS 35.206 (these algorithms are discussed thoroughly in Chapter 8). SQN generation in the AuC

SQN management is also operator-specific in principle. There are two basic strategies at work in creating SQNs: each user may have an individual SQN, or SQN generation may be based on a global counter (e.g., universal time). A combination of these two strategies is also possible in which the most significant part of the SQN is user-specific but the least significant part is based on a global counter.

In the 3GPP specification 33.102 there is an informative annex C that describes three different options for generating SQNs. Because this part of the specification is only for informative purposes, the network operator is also free to choose some other way of generating SQNs while remaining fully compliant with 3GPP standards. However, it has been observed in practice that excessive diversity inside one standard tends to lead in the long run to interoperability problems of some sort or another. This observation is by no means limited to security mechanisms.

Let us discuss this important issue a bit further. There is a widely-held agreement inside the 3GPP that different optional functionalities for the same purpose in the same standard should be avoided if ever possible.


Excerpted from UMTS Security by Valtteri Niemi Kaisa Nyberg Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)