WILEY CELLULAR AUTHENTICATION Service Manual
CELLULAR
AUTHENTICATION
FOR MOBILE AND INTERNET
SERVICES
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg,
Pekka Laitinen and N. Asokan
All at Nokia Research Center, Helsinki, Finland
A John Wiley & Sons, Ltd, Publication
CELLULAR
AUTHENTICATION
FOR MOBILE AND INTERNET
SERVICES
CELLULAR
AUTHENTICATION
FOR MOBILE AND INTERNET
SERVICES
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg,
Pekka Laitinen and N. Asokan
All at Nokia Research Center, Helsinki, Finland
A John Wiley & Sons, Ltd, Publication
This edition fi rst published 2008.
© 2008 John Wiley & Sons, Ltd.
Registered offi ce
John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom
For details of our global editorial offi ces, for customer services and for information about how to apply for
permission to reuse the copyright material in this book please see our website at www.wiley.com.
The right of the author to be identifi ed as the author of this work has been asserted in accordance with the
Copyright, Designs and Patents Act 1988.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in
any form or by any means, electronic, mechanical, photocopying, recording or otherwise, except as permitted by
the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be
available in electronic books.
Designations used by companies to distinguish their products are often claimed as trademarks. All brand names
and product names used in this book are trade names, service marks, trademarks or registered trademarks of
their respective owners. The publisher is not associated with any product or vendor mentioned in this book.
This publication is designed to provide accurate and authoritative information in regard to the subject matter
covered. It is sold on the understanding that the publisher is not engaged in rendering professional services. If
professional advice or other expert assistance is required, the services of a competent professional should be
sought.
Library of Congress Cataloging-in-Publication Data
Cellular authentication for mobile and Internet services / Silke Holtmanns . . . [et al.]
p. cm.
Includes bibliographical references and index.
ISBN 978-0-470-72317-3 (cloth)
1. Mobile communication system–Access control. 2. Internet–Access control.
3. Cellular telephone systems–Access control. 4. Wireless LANs–Access control.
5. Authentication. I. Holtmanns, Silke.
TK6570.M6.C44 2008
005.8 – dc22
2008018998
A catalogue record for this book is available from the British Library.
ISBN 978-0-470-72317-3 (HB)
Set in 11/13pt Times by SNP Best-set Typesetter Ltd., Hong Kong
Printed in Singapore by Markono Print Media Pte Ltd, Singapore.
Contents
Preface ix
Acknowledgements xi
1 Introduction 1
1.1 Authenticated Key Agreement 1
1.2 The Challenge in Authenticated Key Agreement 2
1.3 How to Read this Book? 5
Reference 6
2 Classical Approaches to Authentication and Key Agreement 7
2.1 Existing Mobile Security Solutions 7
2.1.1 UMTS Security Infrastructure 7
2.1.2 Issues in Securing Services with Radio Layer Security 14
2.2 General-Purpose Approaches to Authentication and Key Management 16
2.2.1 Public Key Infrastructure (PKI) 16
2.2.2 Passwords 18
2.2.3 Kerberos 19
2.2.4 Radio Layer and General Purpose Security Mechanisms 19
2.3 Requirements for GAA 20
References 21
3 Generic Authentication Architecture 23
3.1 Overview of Generic Authentication Architecture 23
3.1.1 Rationales for Design Decisions 23
3.1.2 A Bird’s Eye View of GAA 25
3.2 Foundations of GAA 30
3.2.1 Architectural Elements of GAA 30
3.2.2 Bootstrapping 33
3.2.3 Authentication 39
vi Contents
3.3 Variations of the Generic Bootstrapping Architecture 41
3.3.1 GBA_ME 42
3.3.2 GBA_U 42
3.3.3 2G GBA 47
3.3.4 Detection of Bootstrapping Variants by the NAF 48
3.3.5 3GPP2 GBA 54
3.4 Building Blocks of GAA 66
3.4.1 Introduction 66
3.4.2 PKI Portal 72
3.4.3 HTTPS Support 74
3.4.4 Key Distribution Service 74
3.4.4.1 Key Distribution for Terminal to Remote Device Usage 74
3.4.4.2 Key Distribution for UICC to Terminal Usage 77
3.5 Other Architectural Issues 79
3.5.1 Access Control Mechanisms in GAA 79
3.5.1.1 Local Policy Enforcement in the BSF 80
3.5.1.2 USS usage for NAFs 81
3.5.2 Identities in GAA 82
3.5.3 Identity Privacy and Unlinkability 84
3.5.4 Usability and GAA 84
3.5.5 Split Terminal 87
3.5.6 Interoperator GAA: Using GAA Across Operator Boundaries 89
3.5.7 Security Considerations of GAA 91
3.6 Overview of 3GPP GAA Specifi cations 96
References 100
4 Applications Using Generic Authentication Architecture 105
4.1 Standardized Usage Scenarios 105
4.1.1 Authentication Using GAA 105
4.1.1.1 HTTP Digest Authentication 107
4.1.1.2 Pre-Shared Key TLS 111
4.1.1.3 Proxy Mode Authentication 112
4.1.1.4 Referrer Mode Authentication 116
4.1.2 Broadcast Mobile TV Service 119
4.1.2.1 Security Goals 123
4.1.2.2 Service Architecture 123
4.1.2.3 Message Flow Example 126
4.1.2.4 Tracing Source of Leaked Keys 130
4.1.3 Further Standardized Usage Scenarios 131
4.2 Additional Usage Scenarios 135
4.2.1 Secure Enterprise Login 136
4.2.2 Personalization for Payments and Securing Public
Transport Tickets 138
4.2.3 Secure Messaging in Delay and Disruption-prone Environments 140
4.2.4 Terminal to Terminal Security 141
Contents vii
4.2.5 Transitive Trust in IP Multimedia Subsystems (IMS) 144
References 148
5 Guidance for Deploying GAA 153
5.1 Integration with Application Servers 153
5.1.1 Introduction 153
5.1.2 Username / Password Replacement 154
5.1.3 NAF Library 155
5.1.3.1 Apache Web Server 156
5.1.3.2 J2EE Servers 157
5.1.3.3 Direct Usage of NAF Library 158
5.1.4 Web Services Direct Usage 159
5.2 Integration with OS Security 159
5.2.1 Threats for GAA Implementations in Open Platform UEs 160
5.2.2 Access Control Requirements 161
5.2.3 Basic Access Control in Practice: Integration in the Series 60 Platform 162
5.2.4 Extended Access Control: Design Options 163
5.2.5 Other Platforms 165
5.3 Integration with Identity Management Systems 166
5.3.1 Introduction 166
5.3.2 GAA Interworking with Liberty ID-FF 167
5.4 Integration of GAA into Mobile Networks 170
5.4.1 Integration of HLR into GAA 170
5.4.2 Key Lifetime Setting in BSF 173
5.4.3 Usage of SIM Cards in GAA (2G GBA) 175
5.4.4 Charging and GAA 177
5.4.5 GAA Integration into Large Networks 178
References 180
6 Future Trends 183
6.1 Standardization Outlook 183
6.1.1 GBA Push 183
6.1.2 GAA User Privacy 185
6.1.3 GAA in Evolved Packet Systems (EPSs) and Mobile IP (MIP) 187
6.2 Outlook for GAA 189
References 192
Terminology and Abbreviations 193
Index 201
Preface
Like many useful and successful systems, the Internet was not designed with security
in mind. Consequently, authentication on the Internet has been a vexing problem
ever since it was opened up to the larger public in the early 1990s. The fact that most
computers on the Internet are general-purpose devices has made this problem more
acute. Peter Steiner’s famous New Yorker cartoon with the caption ‘On the Internet,
nobody knows you are a dog’ continues to remain apt. However, there is an existing
useful and successful system that has struck the right balance among security, cost,
and usability: this is the worldwide cellular authentication infrastructure. This is the
infrastructure that allows a mobile network subscriber to travel halfway across the
world, have the local mobile network operator authenticate the subscriber, provide
cellular services, and subsequently charge him for those services. Naturally, many
people have wondered whether it is possible to use this large-scale infrastructure to
secure services on the Internet. Already in the late 1990s, there were examples of
using short message service (SMS) messages to pay for soda on a vending machine.
These are ad hoc means of bootstrapping security for new applications from the
existing cellular security infrastructure.
Back in 2000, we started to think about designing a systematic approach to bootstrap cellular authentication for Mobile and Internet Services. What began as a small
Nokia Research Center project grew into a standardization work item in 3
tion Partnership Project (3GPP). The fi rst version of the standardization of the basic
Generic Authentication Architecture (GAA) features was completed in 2006. Two
lead applications for GAA emerged: Multimedia Broadcast/Multicast Services specifi ed by 3GPP and Smart Card Profi le for broadcast Mobile TV, specifi ed by Open
Mobile Alliance.
There are a number of detailed specifi cation documents of GAA and its applications. In 2005, we published a paper titled ‘Extending cellular authentication as a
service’ at the First IEE International Conference on Commercialising Technology
rd
Genera-
x Preface
and Innovation. While GAA was being specifi ed, it was of primary interest to engineers involved in standardization. The existing standards documents were suffi cient
to meet the needs of this group.
In the last two years, several new groups of people have become interested in
GAA, including technical architects, software developers, executive decision makers,
and academic researchers. So far, there has been no single source for a comprehensive, yet readable treatment of GAA, which will present the technology in a form
that is accessible to these groups of people. Our desire in writing this book is to
address this gap.
Deployment of broadcast Mobile TV is expected to begin in the latter half of 2008.
We expect this will introduce GAA to more people who would want to learn more
about the technology. We hope that this book will help them.
Many people helped along the way to take GAA where it is today. Several colleagues at Nokia Research Center contributed to the NRC GAIN project where we
conceived and did much of the early work. Standardization delegates from various
companies took active roles in developing GAA and its applications, not only in
3GPP SA3 working group, but also in other fora. Several people in Nokia and other
companies were instrumental in transforming this technology from research to
product. Our sincerest thanks to all of them; without their hard work, we would not
have had the possibility to write this book.
Acknowledgements
3GPPTM TSs and TRs are the property of ARIB, ATIS, ETSI, CCSA, TTA and TTC,
who jointly own the copyright in them. They are subject to further modifi cations and
are therefore provided ‘as is’ for information purposes only. Further use is strictly
prohibited.
All images of Nokia devices are reproduced with the kind permission of Nokia.
1
Introduction
Over the last few decades, information technology has changed the world in two
major ways. The fi rst development is computerization. Computers have gradually
entered into almost every walk of life. Many services that used to require interaction
with humans are now provided by computers. When you withdraw money from your
bank account, or look for a book in the library, or check in at the airport, chances
are that you are interacting with computer systems hosting these services.
The second development is the immense and increasing popularity of an open
network of interconnecting computers, the Internet. Access to computerized and
automated services now takes place over this open network: when you use online
banking to make payments from your bank account, or order books from an online
bookstore, or browse the online photo albums of your friends, you are using the
Internet, as well as a variety of communication links to access the Internet.
In this chapter, we will discuss what is needed to secure the access to appli cations and services over open networks, what the primary diffi culty in achieving
security is, and why Generic Authentication Architecture (GAA) helps solve this
problem. We will also outline how this book is structured and how to go about
reading it.
1.1 Authenticated Key Agreement
Although the nature of accessing services has changed, many of these services
require some form of controlled access: for example, only you should be able
Cellular Authentication for Mobile and Internet Services
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg, Pekka Laitinen and N. Asokan
© 2008 John Wiley & Sons, Ltd
2 Cellular Authentication for Mobile and Internet Services
to make payments from your bank account. Usually, controlling access to services
is contingent on identifying who is requesting access and verifying the
requestor’s identity. In other words, the serving computer has to authenticate the
requestor.
In a closed network, like the plain old telephone system, authentication can be
implicit based on the presumed physical security of the network. But in an open
network like the Internet, physical security is not relevant – it is easy to claim any
identity towards a distant server. Worse still, it is easy to pretend to be a distant server
towards an unsuspecting client (for example, using IP address spoofi ng). Therefore,
we need to make use of cryptographic techniques for mutual authentication in order
to have suffi cient trust in the authentication process.
In open networks, authenticating the parties at the beginning of a communication
session is not suffi cient: An attacker may wait for authentication to complete and
then hijack the session by inserting, modifying or deleting the messages being
exchanged. To prevent this, the authentication process should also establish session
keys which can be used to guarantee the integrity of the entire communication
session.
In some services, the messages exchanged may need to be private. For example,
suppose you have an online photo album accessible only to family and friends. When
a friend is legitimately viewing the pictures on your album, the information has to
travel from the album server to your friend’s browser. It may traverse several communication links with varying levels of physical security. For example, your friend’s
computer may be connected to her access router over an open wireless link. You do
not want anyone eavesdropping along the way to be able to see your pictures. Cryptographic techniques for encryption can protect the messages while en route. Session
keys established during the initial authentication can be used for encrypting messages
exchanged during the session.
The process of mutual authentication and session key agreement is known as
authenticated key agreement.
1.2 The Challenge in Authenticated Key Agreement
Mechanisms and protocols for performing authenticated key agreement are well
known. For example, every time you access a protected web server, your browser
and the web server engage in the Transport Layer Security (TLS) handshake protocol
for authenticating the server and agreeing on a session key. The challenge in the
authentication is in the task of initializing the necessary credentials at the parties
involved in the authentication.
Consider what typically happens when you enrol into the authentication system
in the bank. You have to visit the bank in person, and possibly show some photo
identifi cation to open an account and provide a mailing address. The bank will then
Introduction 3
send you the credentials needed to access the bank account, for example, a bank card
and the personal identifi cation number (PIN) in separate mails. The process costs
time and money. One approach to reduce the cost of initialization is to relax the
expected level of security and usability. This is the approach taken by popular free
e-mail services: initialization is done by the user visiting a signup page and choosing
a username and setting a password. The user ends up using the same password for
many different services or puts up with the inconvenience of remembering many
different passwords. This may in turn cause that users are more frequently calling
the help desk, or a special password recovery tool is required, which also introduces
costs to the service provider.
An alternative approach is to bootstrap the needed credentials from an existing
security infrastructure. One such security infrastructure is the cellular security
infrastructure. The cellular security infrastructure has several characteristics that
make it a particularly attractive infrastructure to bootstrap security for applications
from.
The fi rst and foremost characteristic is its scalability. The Global System for
Mobile Communications (GSM) and Universal Mobile Telecommunications System
(UMTS) infrastructure consists of hundreds of participating mobile operators and
over two billion subscribers worldwide. Most mobile operators have roaming and
billing agreements with many other operators. Once you enrol as a GSM / UMTS
subscriber with a local operator in your home country, you will be able to authenticate
to many mobile operators, and use their networks to make phone calls or send and
receive messages.
The second characteristic is its ease-of-use. Cellular authentication is an example
of security that remains under the hood and just works. Users are not required to
perform any verifi cation or understand technical security concepts.
The third characteristic is its level of security. Authentication in cellular
systems is based on the possession of smart cards. Even though some of the
cryptographic algorithms in earlier versions of GSM have been broken, the entire
system has stood the test of time. GSM / UMTS security architecture is beginning
to be acknowledged as an example of the principle of ‘good enough’ security
of striking the right balance among cost-effectiveness, security and usability
[Sandhu03].
GAA consists of a set of specifi cations that describe how the cellular security
infrastructure can be used to provide a general-purpose authentication service for
applications and services. It has been standardized both in the 3
ship Project (3GPP) and its North American counterpart the 3
rd
Generation Partner-
rd
Generation Partnership Project 2 (3GPP2). Deployment of GAA in mobile devices and mobile networks
is expected to start in 2008.
The GAA concept is illustrated in Figure 1.1. GAA is a generic architecture for
mutual authentication and key agreement (AKA). Its fundamental building block is
Generic Bootstrapping Architecture (GBA). GBA enables automatic provisioning of
4 Cellular Authentication for Mobile and Internet Services
Subscribers
databases
GBA
HTTPS
Application
server
Mobile
terminal
certificates
Key
Center
Authentication/Key agreement
Figure 1.1. Generic Authentication Architecture (GAA) concept
shared keys between the mobile terminal and an application server (provided that
the user has a valid subscription
1
to cellular network services).
Other GAA constituents are built on top of GBA (new GAA building blocks con-
tinue to be specifi ed):
Support for subscriber certifi cates (SSC) specifi es procedures for the registration
•
of user’s public keys. Those procedures are authenticated with GBA.
Access to application servers with HTTPS specifi es how to use shared keys
•
created with GBA in conjunction with server-authenticated HTTPS to establish
secure and mutually authenticated HTTP communication between mobile terminal
and application server.
Key Centre enables creation of keys shared between terminals.
•
Broadcast mobile television and Multimedia Broadcast/Multicast Service (MBMS),
in which encrypted content is wirelessly broadcast, or multicast, are the lead applications driving the deployment of GAA. In those applications, the delivery of service
keys that are needed to decrypt the received content is secured with GAA. This makes
valid cellular subscription a prerequisite for, e.g., watching mobile television programs. Also, when generating charges for mobile television and MBMS, the person’s
cellular identity, which is verifi ed with GAA, is used.
1
Valid subscription implies that the mobile terminal and subscriber’s databases have a copy of shared
key that is used in cellular authentication.
Introduction 5
1.3 How to Read this Book?
Our goal in writing this book is to explain what GAA is and how it can be used. We
have four different types of readers in mind:
Developers are software designers who design and implement new applications
•
and services. We show how developers can make their application software use
GAA for authentication.
Architects are technical experts who design protocols and systems. We explain
•
the GAA concepts and technical details and show examples of how GAA is integrated into existing protocols so that architects can determine if and how GAA
could be used to solve the authentication needs of the systems they are
designing.
Executives are decision makers in companies who need to fi gure out whether need
•
to deploy GAA. We provide a general overview of GAA and brief analyses of its
benefi ts and tradeoffs that can serve as background materials for decision
making.
Academics are university professors, researchers and students studying computer
•
science or communication systems. We explain the principles and technical details
in the design of GAA that can serve as starting points for academics interested in
analyzing and evaluating GAA, comparing it to other authentication systems, and
designing authentication systems for the future.
The chapters are arranged in the logical order in which we recommend the reader to
proceed. Table 1.1 indicates which sections are likely to be of interest to different
types of readers.
Table 1.1. How to read this book
Section Developer Architect Executive Academic
1. Introduction
1.1 Authenticated Key Agreement
1.2 The Challenge in Authenticated
Key Agreement
1.3 How to Read this Book?
2. Classical Approaches
2.1 Existing Mobile Security
Solutions
2.2 General-Purpose Approaches
2.3 Requirements for GAA
✓✓✓ ✓
✓✓✓ ✓
✓✓✓ ✓
✓✓ ✓
✓✓
✓✓✓ ✓
6 Cellular Authentication for Mobile and Internet Services
Table 1.1. (continued)
Section Developer Architect Executive Academic
3. Generic Authentication
Architecture (GAA)
3.1 Overview of GAA
3.2 Foundations of GAA – Generic
Bootstrapping Architecture
(GBA)
3.3 Variations of GBA
3.4 Building Blocks of GAA
3.5 Other Architectural Issues
3.6 Overview of 3GPP GAA
Specifi cations
4. Applications Using GAA
4.1 Standardized Usage Scenarios
(incl. Broadcast Mobile TV)
4.2 Additional Usage Scenarios
5. Guidance for Deploying GAA
5.1 Integration with Application
Servers
5.2 Integration with OS Security
5.3 Integration with ID
Management Systems
5.4 Integration of GAA into Mobile
Networks
✓✓✓ ✓
✓✓ ✓
✓✓
✓✓
✓✓
✓✓
✓✓✓
✓✓✓
✓✓
✓✓
✓✓✓ ✓
✓
6. Future Trends
Terminology and Abbreviations
✓✓✓ ✓
✓✓✓ ✓
Reference
[Sandhu03] Ravi S. Sandhu: Good-Enough Security: Toward a Pragmatic Business-Driven Discipline.
IEEE Internet Computing 7(1): 66–68 (2003).
2
Classical Approaches to Authentication and Key Agreement
In this chapter, we look at existing approaches to AKA in order to set the stage for
discussing the motivation for and the design of GAA. We begin by examining the
security architectures in mobile networks and then take a broader look at other more
general-purpose AKA mechanisms. We then identify requirements for bootstrapping
an authentication architecture from existing infrastructures.
2.1 Existing Mobile Security Solutions
In the last two decades, several different mobile network architectures have been
designed and deployed. By far, the most widespread have been the UMTS and especially its predecessor GSM infrastructures. Therefore, in this section, we focus on
the security of these infrastructures.
2.1.1 UMTS Security Infrastructure
As we pointed out in Chapter 1, there are many compelling reasons for bootstrapping
credentials from the existing, widely used, cellular security infrastructures. Before
we go on to describe the design and details of the GAA, let us briefl y describe the
UMTS security infrastructure and the associated terminology in order to motivate
the need and the requirements for GAA.
Cellular Authentication for Mobile and Internet Services
Silke Holtmanns, Valtteri Niemi, Philip Ginzboorg, Pekka Laitinen and N. Asokan
© 2008 John Wiley & Sons, Ltd
8 Cellular Authentication for Mobile and Internet Services
One of the cornerstones of GAA is the HTTP Digest authentication using
AKA protocol (HTTP Digest AKA) [RFC3310]. The UMTS AKA protocol (AKA)
has been originally designed for the purpose of securing subscriber access to
cellular networks, more specifi cally, Universal Mobile Telecommunication System
(UMTS) or 3G networks [Niemi07], [TS33.102]. The authentication part of the AKA
protocol of the UMTS security is needed to verify the subscriber’s identity while
key agreement is used for generating keys that are subsequently used in encryption
of traffi c in the radio network and also for protecting integrity of the signalling
messages.
These security features are applied for all user data. Therefore, all applications
and services used over the cellular access automatically gain a certain basic security
level. Because the security protocols and cryptographic algorithms used in UMTS
networks are up-to-date with the state of the art in the area, this basic security level
is fairly good in many respects. For example, 128-bit keys are used in the cryptographic algorithms and all details of these algorithms are publicly known, and therefore, open for public domain scrutiny as well.
In the rest of this subsection, we give a brief description of the most essential
security features in UMTS infrastructure. The UMTS infrastructure consists of a
number of mobile operators with UMTS networks. For each subscriber, there is a
home network run by the operator with whom the subscriber entered into a business
relationship, for example, by opening a billing relationship or purchasing a prepaid
subscription. Each subscriber has a unique identifi er known as the International
Mobile Subscriber Identity (IMSI).
Cutting a few corners, the security architecture of GSM networks can be viewed
as a subset of that of UMTS networks.
In Figure 2.1, we have six different entities, each of which can exist in many
instances in a real network. There is a fair amount of symmetry in this security
architecture. We continue by describing UMTS security architecture via these symmetries, fi ve of them in total.
The fi rst symmetry is on the generation of the keys and other authentication
data.
Beginning from the top of Figure 2.1, the Authentication Center (AuC) is the
network element responsible for storing the permanent cryptographic keys bound to
the subscription and computing the session keys and the authentication data. The
AuC is usually implemented as an integral part of Home Location Register (HLR)
or in latter releases of the 3GPP specifi cations Home Subscriber Server (HSS) which
is the main operator database, containing all subscriber data, including information
about the whereabouts of the subscriber. Often the HSS is implemented as an HLR
with extended functionality.
In the AuC calculations, the permanent key for a subscriber is denoted by K.
Another security-relevant parameter is the sequence number SQN
. As the name
AuC
already indicates, sequence numbers are constantly changing, in contrast to the
Classical Approaches to AKA 9
Home Network
Visited Network
VLR
User Equipment
K
AKA Algorithms
Authentication Vectors
CKCS, IK
RAND, AUTNRES
CS
Encryption and Integrity
Protection Algorithms
SQN
AuC
CKPS, IK
Secure
communication
AuC
SGSN
PS
RNC
Encryption and Integrity
Protection Algorithms
CKCS, IK
K SQN
AKA Algorithms
CS
USIM
CKPS, IK
PS
USIM
Figure 2.1. Summary of the UMTS access security features
ME
10 Cellular Authentication for Mobile and Internet Services
master key K. AKA algorithms are used to create a UMTS Authentication Vector
(AV), containing a quintuple of:
RAND: random 128-bit number generated by AuC
•
XRES: derived by a one-way function from K, RAND and SQN
•
CK: a session key that is also derived by a one way function from the same input
•
parameters
IK: another session key derived similarly
•
AUTN: an authentication token containing SQN
•
istrative fi eld AMF and a message authentication code (MAC) that protects the
integrity of the AV.
Moving next to the bottom, we fi nd the counterpart of the AuC on the user side:
UMTS Subscriber Identity Module (USIM). This is an application residing in a
special kind of smart card, the Universal Integrated Circuit Card (UICC). The technical representation of the subscription is the subscriber-specifi c shared master key K.
Thus, the master key K is stored permanently in the USIM, as well as in the AuC.
If two of the AV parameters, RAND and AUTN, are given as input parameters to
the USIM, very similar set of algorithms, compared to those used in the AuC, are
used to calculate CK, IK and another parameter RES that should be identical to
XRES if everything has been done correctly. The subscriber’s device, called Mobile
Equipment (ME) is capable of interfacing with the UICC.
Next, we describe the second symmetry: this is related to the architecture of the
UMTS as a whole.
There are two different domains that act independently in many respects. In Figure
2.1, there are two elements on the second layer from the top:
in encrypted form, an admin-
AuC
AuC
Visitor Location Register (VLR) belongs to the Circuit-Switched (CS) domain
•
while the
Serving GPRS Support Node (SGSN) belongs to the Packet-Switched (PS) domain.
•
The main service provided by the CS domain (resp. PS domain) is the voice calls
(resp. data transfer). Both VLR and SGSN fetch authentication vectors from the
HLR/AuC node whenever a subscriber has attached to them and there is need for
authentication of the subscriber. The session keys in these AVs for each domain are
marked by the subscripts ‘CS’ and ‘PS’.
Our third symmetry is related to the authentication: the network wants to authen-
ticate the subscriber. On the other hand, it is also in the subscriber’s interest to
authenticate the network to avoid, for example, false base-station attacks.
For each of the domains, the authentication of the subscriber is carried out in an
identical manner. First, VLR (resp. SGSN) sends the two parameters RAND and
AUTN to the USIM. (There are several network elements on the path but they are
Classical Approaches to AKA 11
irrelevant in this context.) The USIM checks fi rst that the Message Authentication
Code (MAC) in the AUTN is correct. Next, the USIM checks that it has not seen
the sequence number hidden in the AUTN before. If these two checks lead to a positive end result, it is concluded, fi rst, that the parameters have truly been generated
in the AuC and, second, that the parameters are used fi rst time in this particular
authentication (this is usually called protection against replay attacks). What follows
is that the USIM sends the calculated response parameter RES back to the VLR
(resp. SGSN). A comparison with the parameter XRES concludes the authentication
procedure.
The generated session keys lead us to the fourth symmetry.
The VLR (resp. SGSN) transfers the session keys CK and IK to the Radio Network
Controller (RNC). Similarly, the USIM provides identical keys to the ME. Note that
in the case of successful authentication, the parameters RES and XRES have found
to be identical and there is a great probability that the session keys on both sides are
identical as well.
Our fi fth symmetry is between the usage of the session keys CK and IK.
Indeed, CK is used for confi dentiality protection purposes while the IK is used for
integrity protection purposes. In addition to these session keys, appropriate cryptographic algorithms are needed here. In UMTS Release 99 specifi cations, one confi dentiality algorithm and one integrity algorithm were defi ned [TS35.201]. Both
algorithms are based on the same block cipher cryptographic algorithm called
KASUMI [TS35.202]. KASUMI uses 128-bit keys and a block size of 64 bits. One
difference between the confi dentiality and integrity protection mechanisms is that
the former is applied to both user traffi c and signalling traffi c, while the latter is only
used for signalling traffi c.
Next, we briefl y list the main differences between the Global System for Mobile
communication (GSM) access security architecture and the UMTS access security
architecture.
Our fi rst symmetry exists also for the GSM access parameters. Instead of the
5-parameter long AV, only three parameters are in use:
random challenge (RAND),
•
(expected) response (now called SRES) and
•
the cipher key (now called Kc).
•
The counterpart of the AuC on the user side is called the Subscriber Identity
Module (SIM). The SIM is a smart card itself. The second symmetry is visible also
in GSM. Actually, the UMTS core network architecture is inherited from the GSM
and its packet-switched extension, GPRS. The third symmetry does not exist in
GSM / GPRS: in these systems, only authentication of the subscriber is carried out.
The fourth symmetry is visible in GSM and GPRS but there are differences, both
compared to the UMTS system and also between the solutions of GSM and GPRS.
12 Cellular Authentication for Mobile and Internet Services
In GSM, the cipher key Kc is transferred all the way to the Base Station (BS) while,
on the other hand, in GPRS, the cipher key stays in the SGSN, it is only transferred
to the ciphering function. The fi fth symmetry is not applicable to GSM since there
is no separate integrity protection mechanism in GSM (or in GPRS).
The ciphering algorithms are also different in GSM / GPRS compared to those
used in UMTS. The most notable difference is length of the key: the key Kc of GSM
/ GPRS has a length of 64 bits. The specifi cations of the fi rst two versions of both
GSM and GPRS encryption algorithms (A5/1 and A5/2 for GSM, GPRS Encryption
Algorithm (GEA) versions, GEA1 and GEA2, for GPRS) have been kept private and
available only to the mobile operators and to vendors of the infrastructure elements
and terminals. There are also KASUMI-based public version A5/3 and GEA3 available nowadays which address some shortcomings of the previous algorithms.
Some other security features of UMTS and GSM / GPRS relevant for the rest of
the book are briefl y described in the balance of this section.
The user identity is protected by the usage of temporary identities. As soon as the
permanent identity of the subscriber, the IMSI (International Mobile Subscriber
Identity), is known to the network (i.e., VLR or SGSN), the network begins to use
a temporary identity, TMSI (Temporary Mobile Subscriber Identity) instead. The
TMSI is sent to the User Equipment (UE) over the encrypted channel. The UE is a
mobile terminal with a smart card inserted. Whenever the TMSI has been used by
the UE to, for example, set up a call, receiving a call or location update, the network
provides a new TMSI for the UE. The TMSI mechanism does not give protection of
user identity confi dentiality against active attacks because the attacker can always
pretend to be a network element that has lost the TMSI, and thus, requests the permanent identity from the UE. But the TMSI protects against passive attacks like
eavesdropping.
The session keys CK, IK and Kc may be used for several sessions. In other words,
authentication is not required for each session. There is no lifetime associated to the
keys, though. In UMTS, there is a possibility to restrict how much of data is protected
by the same session key but this amount is typically very high and the protection is
intended for extremely long sessions only. The reason for omission of the lifetime
is that in case a subscription itself expires, information about this is carried to the
serving network that can technically then simply cut down the session.
In Figure 2.2 we show the information fl ow related to the AKA protocol.
Figure 2.2 shows the exchanges involved in the UMTS AKA protocol. Subscribers
access services by connecting to a serving network. The serving network depends
on the subscriber’s present location: when he is at home, the serving network is
the same as the home network; when he is travelling elsewhere, it is usually a
network of a different operator who has a roaming agreement with the home network
operator.
The subscriber’s USIM and the Home Network share a long-term key K and
maintain a running sequence number SQN.
Classical Approaches to AKA 13
K, SQN
RAND K
RES SQN’ CK
AUTN
IK
Check if SQN’ is big enough
UE Serving Network
IMSI/TMSI
IMSI
<RAND, AUTN, XRES, IK,CK>
RES
Check if RES = XRES
AKA Credential Fetching Protocol
Home Network
IMSI K
… …
… …
RAND
XRES
HSS
K
AUTN CK
SQN
…
…
SQN
IK
Figure 2.2. UMTS authentication and key agreement (AKA) protocol
1. The authentication procedure is triggered by the UE sending its permanent identity to a server in the serving network (home or visited network). The fi rst time
UE connects to a serving network it has to use its true IMSI as the identifi er. But
on successful authentication, the serving network may provide a temporary identifi er TMSI. The serving network maintains the mapping of TMSIs to IMSIs.
2. The serving network forwards the IMSI to the home network which chooses a
random challenge RAND and looks up K and the current SQN for IMSI. RAND,
K and SQN are fed into a set of cryptographic algorithms to produce four values:
an authenticator AUTN to prove that RAND was sent by the home network, an
expected response XRES for the given RAND and two cryptographic session keys
CK and IK to be used to protect confi dentiality and integrity of subsequent communication between the UE and the serving network.
3. The Home Network sends these four values along with the corresponding RAND
to the serving network.
4. The serving network forwards RAND and AUTN to UE.
5. The UE’s USIM takes RAND, AUTN and K as input to the same set of cryptographic algorithms as in step 2 to produce a response RES, the sequence number
SQN’ used by the Home Network, and the two keys IK and CK.
14 Cellular Authentication for Mobile and Internet Services
6. The USIM checks if the value SQN’ is big enough given its own sequence number
value SQN. If so, it accepts the authentication and sends RES back to the serving
network. If RES is the same as XRES, the serving network accepts the authentication as well.
Thus, AKA provides mutual authentication between the subscriber and the network
operator. It also results in temporary session keys shared between the UE and the
serving network. The above is an extremely simplifi ed overview of the UMTS security architecture intended to present only those aspects relevant for eliciting the
requirements for GAA. Readers interested in a comprehensive description of UMTS
security architecture should consult [Niemi07].
In normal AKA usage, the UE sends and receives AKA message over its radio
interfaces. But there is nothing inherent in AKA that binds it to UMTS radio layer.
Therefore, in course of time, two new transports for AKA signalling were specifi ed.
The fi rst is HTTP Digest AKA [RFC3310]. HTTP Digest AKA defi nes a new
‘algorithm’ for the HTTP Digest authentication scheme [RFC2617] by mapping AKA
parameters to the information elements required by HTTP Digest authentication.
Essentially, HTTP Digest AKA encodes the RAND and AUTN parameters into the
nonce fi eld of an HTTP Unauthorized response from the server; the client extracts
RAND and AUTN, applies the normal AKA processing, and uses the resulting RES
parameter of AKA as the ‘password’ for HTTP Digest Authentication, thereby turning
HTTP Digest into a one-time password scheme. The resulting IK and CK can be
used to protect the subsequent communication between the client and the server.
Usually, HTTP Digest authentication is used in conjunction with a server-authenticated TLS tunnel so that subsequent communication between the server and the client
is protected by the TLS session key. However, HTTP Digest AKA authentication
must not be used in this manner because an attacker pretending to be a serving
network could easily get RES from a UE using regular AKA (see [Asokan05] for
details of this type of man-in-the-middle attacks).
The second alternative transport for AKA is over Extensible Authentication Protocol (EAP) defi ned in the EAP-AKA RFC [RFC4187]. This specifi cation defi nes a
new EAP authentication method to transport AKA signalling. This allows AKA to
be used in applications that support EAP, usually for access authentication, e.g., in
WiFi networks.
2.1.2 Issues in Securing Services with Radio Layer Security
Many service providers have concluded that the basic security level provided by the
radio layer (i.e., the link layer) is suffi cient for their services that are provided on
higher layers. From the point of view of confi dentiality, this conclusion may be well
justifi ed in many cases. Indeed, the radio interface is the one that is most vulnerable
to the eavesdroppers. Encryption on the radio layer provides protection against such
Classical Approaches to AKA 15
attackers for all data in higher layers as well. On the other hand, from the point of
view of authentication, the situation is more complicated.
This is because the well-accepted layered approach in communications (e.g.,
OSI 7-layer model, IETF 5-layer model) does not fi t optimally with authentication.
The reason for this stems from the following facts:
Authentication is always done in relation to a certain identity, i.e., verifying that
•
identity.
The layers use different identities (e.g., MAC address, IP address, Session Initia-
•
tion Protocol (SIP) identity).
Therefore, we have to choose one of the following approaches:
(a) execute authentication in many layers (which obviously adds complexity to the
system);
(b) let some identities be unauthenticated (which implies that certain threats cannot
be addressed at all); and
(c) bind different identities together.
The last solution has also drawbacks:
The binding has to be done securely which adds the need for a new security feature
•
to the system. Also, the binding may change frequently and cause quite some load
to the systems. Network Address Translation (NAT)
complexity if used together with identity binding for IP addresses.
The binding causes a violation against the core idea of the layered communication
•
model.
In 3GPP systems, all of these approaches are in use, e.g., in IP Multimedia Core
Network Subsystem (IMS):
Full IMS with IP Multimedia Subsystem Identity Module (ISIM) application on
•
the UICC is an example of approach (a) [TS31.103], [TS33.203]. This is a very
secure and scalable approach; the largest drawback is that the penetration of ISIM
applications on the UICC is still limited and the network support for this is not
that wide.
HTTP digest authentication over insecure access. This has been specifi ed as an
•
optional mechanism for fi xed networks in ETSI TISPAN. This is an easy, but not
very secure, approach. It is an example of approach (b) in the sense that access-
level identities are not assumed to be authenticated.
1
http://en.wikipedia.org/wiki/Network_address_translation
1
servers may cause additional
16 Cellular Authentication for Mobile and Internet Services
Early IMS security [TR33.978], i.e., IP address binding is an example of approach
•
(c). This approach works, but has some scalability issues, when a large range of
users using a large set of service (potentially with NATs deployed in the system).
Also IP address spoofi ng may become an issue with this approach. Frequent IP
address changes cause additional complexity and load to this approach.
Network Attachment Subsystem (NASS)-IMS bundled authentication, i.e., binding
•
to the calling line identifi er [TS33.203] is another example of approach (c). This
approach works well enough for simple use cases, but does not support mobility.
If mobility or several users behind one line should be supported, then additional
features or functionalities are required.
2.2 General-Purpose Approaches to Authentication and Key Management
2.2.1 Public Key Infrastructure (PKI)
Public key cryptography was invented in the mid-1970s [Diffi e76]. Two groundbreaking concepts were introduced:
(1) Separation of keys used for encryption and decryption. As a consequence, one
of the keys could be made public without revealing the other key.
(2) Digital signature. It became possible to verify authenticity of a completely digital
document in a way that also enabled unforgeability: only the source could have
created the document with the digital signature.
It was fi rst thought that concept (1) would make key management of a big system
very easy. Every entity in the system could have its own private key, stored and
protected in one single entity. The corresponding public key could be made available
for every other entity in the system by including it in an appropriate database. Soon
it was observed, however, that when the system becomes even bigger and less centrally managed, the database solution for managing public keys does not scale
anymore. It becomes diffi cult to guarantee access to the database in a secure manner,
and, on the other hand, it becomes, more and more diffi cult to guarantee that the
public keys in the database are authentic themselves.
Fortunately, concept (2) provided solutions to these problems. Public keys could
be digitally signed by an authority, thus creating a certifi cate. Then there is no need
to have a secure online access to a centralized authentic database: if you want to
send a message to a person, you could fi nd the digitally signed certifi cate from
whatever source (e.g., from the Internet).
However, the issue is not so straightforward: verifying of digital signatures itself
requires authentic keys. In the setting described above, the sender of the message
Loading...