Helsinki University of Technology Department of Computer Science and Engineering Telecommunications Software and Multimedia Laboratory

Antti Järvinen

Smart Card Based Configuration and Authentication for Mobile IPv4 Master’s Thesis 28th May 2003

Supervisor Instructor

Professor Hannu H. Kari Tom Weckström, M.Sc.

HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering Author: Title: Date: Professorship: Major: Minor: Supervisor: Instructor:

ABSTRACT OF THE MASTER’S THESIS

Antti Järvinen Smart Card Based Configuration and Authentication for Mobile IPv4 28th May 2003 Pages: x + 66 T-79 (Theoretical Computer Systems) Telecommunications Software Embedded Systems Prof. Hannu H. Kari Tom Weckström, M.Sc.

Mobile IPv4 is a IETF supported protocol for mobility management in IPv4 networks. The protocol introduces new functional entities. Mobile devices are called mobile nodes. When a mobile node changes its point of attachment to the Internet, it sends a location update to its home agent. The mobile node needs to know the address of its home agent and the home agent must authenticate the location update. This thesis presents a solution for easy configuration of the mobile node. A prototype implementation of the solution is also made. The implementation showed that the solution works in practice. In the solution Mobile IPv4 settings are stored on a smart card. A typical smart card has couple of kilobytes free memory. The size of the settings is only couple of dozens of bytes, so a card has still space left for other applications and settings. With the help of the solution, a mobile node can be taken into use, just by inserting a card and entering the PIN code. This thesis presents also a public key based authentication between a mobile node and a home agent in Mobile IPv4. In the solution, both the mobile node and the home agent have a RSA key pair and a X.509 certificate for the public key. The solution does not need a new key for the mobile node. If the mobile node has already a RSA key, which is used e.g. with IPSec, the same key can be used in Mobile IPv4 authentication. Keywords

Mobile IP, authentication, smart card, PKI

TEKNILLINEN KORKEAKOULU

DIPLOMITYÖN TIIVISTELMÄ

Tietotekniikan osasto Tekijä: Antti Järvinen Työn nimi: Älykorttiin perustuva konfigurointi ja autentikointi Mobile IPv4:ssä English title: Smart Card Based Configuration and Authentication for Mobile IPv4 Kieli: englanti Päivämäärä: 28th May 2003 Sivumäärä: x + 66 Professuuri: T-79 (Tietojenkäsittelyteoria) Pääaine: Tietoliikenneohjelmistot Sivuaine: Sulautetut järjestelmät Työn valvoja: Prof. Hannu H. Kari Työn ohjaaja: Tom Weckström, DI Mobile IPv4 on IETF:n tukema protokolla liikkuvuudenhllintaan IPv4 verkoissa. Protokolla lisää IPv4 verkkoihin uusia funktionaalisia elementtejä. Liikkuvia laitteita kutsutaan liikkuviksi solmuiksi (mobile node). Kun liikkuva solmu vaihtaa liityntäpistettään Internettiin, se lähettää sijainninpäivityksen kotireitittimelleen (home agent). Liikkuvan solmun pitää tietää kotireitittimen osoite ja kotireitittimen pitää autentikoida sijainninpäivitys. Tämä diplomityö esittää ratkaisun, jolla liikkuva solmu voidaan konfiguroida helposti. Diplomityön puitteissa on myös tehty ratkaisun mukainen prototyyppi-implementaatio, joka osoittaa käytönnässä ratkaisun toimivuuden. Ratkaisussa Mobile IPv4 asetukset on talletettu älykortille. Tyypillisellä älykortilla on vapaata muistia muutaman kilotavun verran. Asetukset vaativat muistia ainoastaan muutaman kymmenen tavun verran, joten älykortille jää vapaata tilaa muille asetuksilla reilusti. Ratkaisun avulla liikkuva solmu voidaan ottaa käyttöön kortinhaltijan omilla asetuksilla laittamalla älykortti kortinlukijaan ja syöttämällä PINkoodi. Tämä diplomityö esittelee myös Mobile IPv4 liikkuvan solmun ja kotireitittimen välillä toimivan julkisen avaimeen perustuvan tunnistuksen. Ratkaisussa liikkuvalla solmulla ja kotiagentilla on oma RSA-avainpari ja siihen liittyvä X.509 sertifikaatti. Ratkaisussa ei vaadita uutta avainta liikkuvaa solmua varten, vaan olemassa olevaa esim. IPSecissä käyttettävää RSA-avainta, voidaan käyttää myös Mobile IPv4 autentikointiin. Avainsanat

Mobile IP, tunnistus, älykortti, PKI

Acknowledgements I wrote this thesis for Secgo Group Oy using Secgo Mobile IP products as a basis for my work. I want to thank the company for making this thesis possible. Especially I want to thank my insctructor Tom Weckström who had time for reviewing the thesis, giving good comments and asking excellent questions. I thank professor Hannu H. Kari for being supervisor of this thesis. I want to thank Björn Andersson for reviewing the thesis and giving good ideas. I want to thank Maria Indeeva for the help with smart cards. Thanks also to the whole Secgo Mobile IP team, Kristian Slavov and Miika Komu for the comments and support. Finally I want to thank my family and especially my wife Kirsi for the support I received while doing this thesis.

Helsinki, 28th May 2003

Antti Järvinen

iv

Contents Abstract

ii

Tiivistelmä

iii

Acknowledgements

iv

List of figures

vii

List of tables

viii

Table of symbols and abbreviations

ix

1

Introduction

1

2

The Problem 3 2.1 The problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2 The scope of this thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3

Criteria

4

Generic Model 15 4.1 X.509 Strong Authentication Model . . . . . . . . . . . . . . . . . . . . 15

5

Related work 5.1 AAA Registration Keys for Mobile IP . . . . 5.2 Internet Key Exchange . . . . . . . . . . . . 5.3 Mobile IP Public Key Based Authentication . 5.4 Mobile IP Registration Protocol: A Security Minimal Public-Key Based Authentication . . 5.5 Session Initiation Protocol . . . . . . . . . .

6

11

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attack and New . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . Secure . . . . . . . .

22 . 22 . 23 . 24 . 27 . 27

Solution 29 6.1 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2 Mobile IPv4 Settings on a Smart Card . . . . . . . . . . . . . . . . . . . 30 6.3 Mobile IPv4 Public Key Authentication Protocol . . . . . . . . . . . . . 32

v

CONTENTS 6.4 7

8

vi

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Analysis 7.1 Security . . . . . . . . . . . . . . . . . 7.2 Compliance with the standards . . . . . 7.3 Operation in heterogeneous environment 7.4 Performance . . . . . . . . . . . . . . . 7.5 Usability . . . . . . . . . . . . . . . . . 7.6 Future Improvements . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

44 44 50 50 51 53 53

Conclusions 55 8.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 8.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

References

57

A Mobile IPv4 settings ASN.1 module

62

B PROD Pr/T definition for the authentication protocol

63

C PROD results

65

List of figures 2.1 2.2 2.3 2.4

Basic operation of Mobile IP . . . . . . . . Authenticated parts of registration messages Structure of a smart card . . . . . . . . . . Different APIs to access a smart card . . . .

4.1 4.2 4.3

X.509 Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 CA Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Cross Certified Root Certificates . . . . . . . . . . . . . . . . . . . . . . 19

6.1 6.2 6.3 6.4 6.5

Mobile IP application directory structure . . . . . . . . Needed extension in PKI-based Mobile IP registration . P/T net . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Node Architecture . . . . . . . . . . . . . . . Home Agent Architecture . . . . . . . . . . . . . . . .

vii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

5 6 7 9

31 38 40 42 43

List of tables 2.1

Mobile-Home Authentication Extension . . . . . . . . . . . . . . . . . .

3.1

Security Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.1

Mobile Node Authentication Extension . . . . . . . . . . . . . . . . . . 25

6.1 6.2 6.3 6.4 6.5 6.6

X.509 Certificate Extension . . . . . . . . . . . . . . . . . . The Generalized Mobile IP MN-HA Key Request Extension The Generalized Mobile IP MN-HA Key Reply Extension . The MN-HA Key Material from PKI Extension data . . . . . Generalized Mobile IP Authentication Extension . . . . . . MN-PKI Authentication Subtype . . . . . . . . . . . . . . .

7.1

Evaluated Security Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 54

viii

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

6

33 34 35 36 36 37

Table of symbols and abbreviations AID Application Identifier API Application Programming Interface ARP Address Resolution Protocol ASN.1 Abstract Syntax Notation number One BER Basic Encoding Rules of ASN.1 CA Certification Authority CER Canonical Encoding Rules of ASN.1 CN Correspondent Node COA Care-Of Address CRL Certificate Revocation List DER Distinguished Encoding Rules of ASN.1 DF Dedicated File DHCP Dynamic Host Configuration Protocol DNS Domain Name Server DN Distinguished Name EF Elementary File FA Foreign Agent GPRS General Packet Radio Service GSM Global System for Mobile Communications HA Home Agent IKE The Internet Key Exchange IPSec Internet Protocol Security ISO International Organization for Standardization ITU-T ITU Telecommunication Standardization Sector ITU International Telecommunications Union LDAP Lightweight Directory Access Protocol MAC Message Authentication Codes MF Master File MN Mobile Node NAI Network Access Identifier PIN Personal Identification Number

ix

TABLE OF SYMBOLS AND ABBREVIATIONS PKCS PKI PPP RFC RID SA SIM SPI USB

Public Key Cryptosystems Public Key Infrastructure Point-to-Point Protocol Request For Comments Registered Application Provider Identifier Security Association Subscriber Identity Module Security Parameter Index Universal Serial Bus

x

Chapter 1 Introduction Business is getting mobile. The market share of laptops in the PC market is increasing all the time. Many of the new laptops have several network interfaces, both wired and wireless, through which a laptop can be connected to the Internet. Working efficiency increases, when a laptop can be easily carried with the worker. The information in company’s internal network can be accessed regardless of the place and time. The information can be fed into the Internet right away in a meeting or the time and the place of the next meeting can be easily agreed, because everyone can access their electronic calendars. In an ideal situation, a laptop can by itself decide which interface it uses for the Internet access. When a fast and cheap connection is available, it will be automatically used. The worker can concentrate on working and let the computer handle connections to the Internet. For example, when the worker is working in his regular working place, the connection to the Internet is made through a fast cable. When he leaves his place and plugs off the cable, the computer would automatically roam to a wireless network. The reality with currently widely used operating systems is totally different. When the user plugs off the cable, active sessions will break, programs using Internet connections will hang up and they have to be restarted, and in the worst case the whole operating system must be restarted. Fortunately, a standardized solution for the problem exists. With the help of external programs, the computer can be made mobile. Mobility can be added deep in the internals of the operating system, so it is totally transparent to 1

CHAPTER 1. INTRODUCTION

2

applications. Applications remain the same and they only see a constant Internet connection. Mobility management systems can be so easy to use that the end-user does not even need to know that such systems are used. However, someone has to set up the system. The mobile computers need to somehow get the configuration and the servers need to recognize the mobile computers. This thesis tries find out how configuring such a system can be made as easy as possible. While the configuring is easy, it usually means that it takes little time to take the system in use, which further implies that deployment costs are low.

Chapter 2 The Problem Use of the Internet has increased enormously during the lifetime of the Internet. The currently widely used Internet Protocol version 4 (IPv4) [44] has been in use since the beginning of the 1980’s. In those days, computers connected to the Internet were mainly at universities and at other research facilities. Nowadays, there are many mobile devices, which will likely use Internet connections while moving. Devices still use the same internet protocol version. However, there are methods to make these devices mobile. This can be done on several different layers. For example, applications can be aware of mobility, but the downside is, that every application should implement their own mobility management solution. IETF’s Request For Comments (RFC) IP Mobility Support for IPv4 [39] defines a solution, which operates at the network layer. While mobility is implemented on the network layer, mobility is transparent to upper layers (transports and applications). IP mobility support introduces three new functional entities, a Mobile Node (MN), a Foreign Agent (FA), and a Home Agent (HA). A mobile node is a host, which changes its point of attachment to the Internet. It has a constant IP address, which in topological sense resides in the node’s home network. Whenever a mobile node changes its location, it acquires from the visited network a new Care-Of Address (COA) and informs it to the home agent. Care-of address can be acquired from a foreign agent. If there is no foreign agent available, the mobile node obtains an IP address through the same mechanisms as 3

CHAPTER 2. THE PROBLEM

4

a normal host and uses the obtained address as a care-of address. A home agent is a router in the mobile node’s home network. It keeps track of mobile nodes’ current location. If a mobile is in its home network, it acts like any other node in the Internet. If a mobile node is in any other network and is registered with its home agent, the home agent intercepts all datagrams destined to the mobile node and tunnels them to the current care-of address of the mobile node. Tunneling means putting the original IP packet inside an IP packet and sending it to mobile node’s care-of address. This is quite analogous to the redirection service of a post office. When a post address changes, the recipient’s old post office puts letters into a new envelope and sends the envelope to the recipient’s new address. A Correspondent Node (CN) is a node, which communicates with a mobile node. The correspondent node does not necessarily know anything about mobility and even less about the mobile node’s current location. The correspondent node sends packets to the mobile node’s home network and a home agent forwards them to the right place, when the mobile node is not in its home network. A foreign agent is a router in the visited network and it advertises its presence to visiting mobile nodes. If a mobile node notices a foreign agent, it registers the care-of address advertised by the foreign agent to its home agent. In that case, the foreign agent de-tunnels datagrams tunneled by the home agent. Using a foreign agent is not mandatory. A mobile node can also get a care-of address using Dynamic Host Configuration Protocol (DHCP), Point-to-Point Protocol (PPP), or a care-of address can be manually configured. Essential is that a mobile node knows its own IP address from the visited network and an IP address of a default gateway to the Internet. In this case, a home agent sends tunneled datagrams directly to the mobile node and the mobile node has to de-tunnel datagrams by itself. Picture 2.1 shows what happens when a correspondent node sends a packet to a mobile node. The correspondent node sends the packet to the Internet, which routes it to

CHAPTER 2. THE PROBLEM

5

mobile node’s home network. The home agent intercepts the packet, looks up the current care-of address of the mobile node and puts the packet into a tunnel towards the mobile node’s care-of address. The mobile node is registered through the foreign agent, so the foreign agent takes the packet out of the tunnel and forwards the packet to the mobile node.

MN Home network

HA

CN Internet

FA

Foreign network MN

Figure 2.1: Basic operation of Mobile IP

Mobile IPv4 Registration Prodecude When a mobile node registers its care-of address to a home agent, the home agent has to authenticate the registration message. Authentication means a cryptographic way to check the identity of the originator of the message. If registration requests were not authenticated, then anyone could send registration requests on the behalf of another mobile node and get another mobile node’s datagrams. Mobile IPv4 uses Security Associations (SA) between different mobile entities for authentication. All entities, mobile nodes, foreign and home agents must support security associations. A SA exists always between two entities, e.g. between a mobile node and a home agent and it is identified by the IP addresses of the two entities. For a mobile node,

CHAPTER 2. THE PROBLEM

6

Table 2.1: Mobile-Home Authentication Extension 01234567 89012345 Type Length SPI (continued)

67890123 45678901 SPI Authenticator...

the home address is used, not the current care-of address. There can be several security contexts between two entities and contexts are identified by a Security Parameter Index (SPI), which ultimately defines authentication algorithm, mode, key, and replay protection type. Every registration request and corresponding registration reply has to be protected using Mobile-Home Authentication Extension. Table 2.1 shows fields of the extension. Authentication is done by using cryptographic functions to calculate a digest over the authenticated fields. The sender of the messages calculates the digest of registration request/reply, extensions prior the mobile-home authentication extension, and extension’s type, length, and SPI fields with the help of the key known by the MN and the HA. The result is placed in the authenticator field of the extension. When the registration message is received, the receiver checks that the authenticator field is valid. Figure 2.2 clarifies which parts of registration messages are authenticated.

IP header

UDP header

Registration request

Optional extensions

Mobile−Home authentication extension

Optional extensions

Mobile−Home authentication extension

Optional extensions

Authenticated fields IP header

UDP header

Registration reply

Optional extensions

Figure 2.2: Authenticated parts of registration messages The default algorithm for calculating a digest in registration messages is HMACMD5 [29]. In general such algorithms are called Message Authentication Codes (MAC). A MAC is a function that takes a variable length input and a secret key and produces

CHAPTER 2. THE PROBLEM

7

a fixed length output. The idea is that the same input always produces the same output and with different inputs, outputs are also different. Because MAC functions produce digests and the output is usually shorter than the input, different inputs can produce the same output. However, without knowing the secret key, it is unfeasible for an outsider to generate a digest, which can be verified by the secret key. So the communicating parties can trust on the authenticity of the message. [52]

Smart cards RFC 3344 defines a mobile node as a host or a router. This implies that the home IP address and authentication keys of the mobile node are stored inside one host. In Global System for Mobile Communications (GSM), the keys and the identities are stored in Subscriber Identity Module (SIM). When a GSM subscriber puts his SIM card into a GSM phone, he is reachable through the same number regardless of the phone being used. [33] In general, a SIM card is a smart card. A smart card is a combination of a small microprocessor, a little memory and an interface to the outside world on a single chip. A smart card is usually packaged in a credit-card size plastic card. [7] Figure 2.3 shows the structure of a smart card.

RAM

co− processor

ROM CPU EEPROM

Figure 2.3: Structure of a smart card There are different kinds of memory units on the card. Volatile and non-volatile, mu-

CHAPTER 2. THE PROBLEM

8

table and immutable. ROM is non-volatile and immutable. The card’s operating system and applications are stored there. RAM is volatile and it is used for run-time storage. EEPROM is volatile and mutable. Keys, configuration settings, and other customer specific data are stored there. Smart cards typically have 16 or 32 kilobytes of EEPROM, which is enough to hold a couple of keys. A smart card typically has an 8-bit microprocessor. Computing power in such a processor isn’t big compared to current desktop computers. To overcome the problem, a smart card can contain a co-processor specialized for cryptographic algorithms. [55] The bus between the memory and the processor is inside a smart card and EEPROM can be protected with a Personal Identification Number (PIN). The card’s operating system is able to protect data so that it can not be moved outside the card. Cards are also physically protected against electromagnetic phenomena, bending, etc. If cryptographic keys are stored in a smart card, authentication can be based on something you have (the keys that can not be extracted from the card) and something you know (the card can not be used without knowing the PIN number) or something you are (owner’s fingerprint is stored on a card and using the card requires showing the owner’s fingerprint). Using at least two different authentication types is more secure than just one. [51] There are also some drawbacks with smart cards. Using a smart card with a normal PC needs a separate smart card reader. Another approach is to combine the chip with an interface that a normal PC already has. Most PCs have a Universal Serial Bus (USB) interface. CPU and memory can be placed in a small device, size of a normal house key with a USB connector [5]. Another problem with smart cards is that there are several standards related to them. Not all of the cards support the same standards, so if an application wants to work with most of the cards, it has to support different parallel standards. International Organization for Standardization (ISO) has created standards for physical characteristics and

CHAPTER 2. THE PROBLEM

9

requirements of smart card operating systems and an interface for the card. RSA Laboratories provides PKCS #11: Cryptographic Token Interface Standard, which offers an Application Programming Interface (API) to devices, which hold cryptographic information and perform cryptographic operations [49]. Programs can be made portable between different platforms, because the API to tokens remains always the same. The downside is that PKCS #11 does not define how the cryptographic keys are stored on a token. In the worst case, this means that keys are stored in different locations inside the token and every token needs their own driver for PKCS #11. RSA Laboratories has noticed also this and it has made a new specification called PKCS #15: Cryptographic Token Information Format Standard. It defines how digital credentials are stored inside the token and what kind of file structure the token has [48]. PKCS #11 is not the only possible API for the smart card applications. There can be several public or proprietary APIs, which can use the PKCS #15 directory structure or store the keys in the locations they want. Figure 2.4 shows how an application can access a smart card.

Applications

PKCS#11 API

any other API

PKCS#15 dir. structure ISO standards

Figure 2.4: Different APIs to access a smart card

CHAPTER 2. THE PROBLEM

10

2.1 The problem statement In this thesis, I focus on solving the problem how a user’s identity, home network settings, and authentication keys can be easily transferred to the terminal used at that moment. An important objective of the thesis is also to define a secure and scalable method for the registration authentication without predefined shared secrets between a mobile node and its home agent. In order to ensure mobility of user’s identity between Mobile IP products from different vendors, a common format for storing user’s identity and home network settings will also be defined.

2.2 The scope of this thesis The scope of this thesis is user’s secure mobility in IPv4 networks, using the Mobile IPv4 protocol. An implementation for a developed solution will also be made. There are also other mobility management systems than Mobile IPv4, e.g. the next version of the IP protocol, IPv6 has its own support for mobility[27]. User’s mobility in other mobility management systems is out of scope of this thesis. This thesis will also not try to solve how a mobile node can authenticate with foreign agents without predefined shared secrets.

Chapter 3 Criteria In order to analyze a solution to the problem described in section 2.1, we need criteria for the analysis. In chapter 7, the solution will be compared against the requirements defined in this chapter. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this chapter are to be interpreted as described in RFC 2119 [10].

Security Security is the most crucial requirement. Since the intention is to modify Mobile IPv4 registration authentication, modifications can not be insecure. It is not enough that the protocol itself is secure. Security has to be considered on several different levels. • The solution must be based on secure algorithms and cryptographic schemes. • The solution itself must be secure. • The implementation of the solution must be secure. Basili’s Goal-Question-Metric approach [8] will be used for creating measurable metrics for these requirements. The actual metrics are listed in Table 3.1.

11

CHAPTER 3. CRITERIA

12

Compliance with the standards The solution must conform to the Mobile IPv4 RFC 3344. Registration procedure must work with a co-located care-of address and through a foreign agent.

Operation in heterogeneous environment The implementation must be based on open standards when communicating with smart cards. The solution must not use undocumented functions or methods, which happen to work with one smart card. The implementation has to work with different smart cards and smart card readers. Especially the electronic identification card issued by The Finnish Population Register Centre [58] should be supported. The implementation of the smart card access must not be tied to any particular operating system. It should be easily ported to new operating systems. Windows 2000 and XP must be supported.

Performance Cryptographic operations used in Mobile IP registration should not be time consuming. In a mobile node and a home agent this means different things: • From a mobile node point of view, time spent on cryptographic operations must be so short that it does not have effect on network connections. This means that TCP connections must not break during the registration and the registration should take less than 4 seconds to avoid user noticeable breaks on network traffic. • From a home agent point of view, the number of mobile nodes that a home agent can serve should not decrease more than 30 % compared to registration using shared secrets.

CHAPTER 3. CRITERIA

13

Usability Implementation of the solution should be easy to use. If the mobile node software is installed on the computer, Mobile IP service should be taken into use just by inserting a smart card and entering the PIN code.

Future Improvements The solution must not prevent adding support for the route optimization [43].

CHAPTER 3. CRITERIA

14

Table 3.1: Security Metrics Criterion 1 Question Metric Question Metric Question Metric Question Metric Criterion 2 Question Metric Question Metric Question Metric Criterion 3 Question Metric Question Metric Question Metric Question Metric Question Metric Question Metric Criterion 4 Question Metric Question Metric Question Metric Question Metric Question Metric Question Metric

Secure Algorithms Number of different algorithms Count Number of published algorithms Count Have standardization bodies standardized used algorithms? Binary, Count Are they any known attacks against used algorithms? Binary, Count Secure Cryptographic Schemes Number of different schemes Count Number of published schemes Count Are they any known attacks against used schemes? Binary, Count Secure Protocol Does the authentication protocol follow any widely used authentication framework? Binary Are the algorithms combined so that they are not vulnerable to any known attacks? Binary Does the protocol ensure that the identity of the communicating parties is verified reliably? Binary Does the protocol open any possibilities to reveal the actual traffic? Binary Does the protocol hide the identity of the communicating parties? Binary Does the protocol have deadlocks or livelocks? Binary Secure Implementation Does the implementation properly handle messages that have incorrect extensions? Binary Is the implementation vulnerable against implementation specific attacks against used algorithms? Binary Does the implementation of the algorithms have any certificates? Binary Are random numbers truly random? Binary Number of real errors found in the source code with RATS [54] Count Number of real errors found in the source code with Flawfinder [60] Count

Chapter 4 Generic Model International Telecommunications Union (ITU) is an international organization within the United Nations. It is working between governments and industry to evolve the development of communications technology. ITU Telecommunication Standardization Sector (ITU-T) works under ITU in order to advance telecommunications interoperability between different organizations. ITU-T creates international standards called recommendations.

4.1 X.509 Strong Authentication Model Recommendation X.509, titled Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks, defines both a simple and a strong authentication model [1]. The basic authentication model is based on client’s distinguished name and optional bilaterally agreed password. In essence, Mobile IPv4 registration using shared secrets is based on basic authentication model. That model is not discussed any further in this thesis.

Public Key Cryptography The strong authentication model is based on Public Key Cryptosystems (PKCS). While symmetric cryptosystems have only one key, which is used for both encryption and decryption, public-key systems have a pair of keys. Each user X has a public key Xp and 15

CHAPTER 4. GENERIC MODEL

16

a private key Xs . The Public key is publicly available e.g. in a directory, from where anyone can get the key. The private key Xs is known only by its owner X. If the private key is stored on a smart card, even the owner of the key does not know the key. The key can still be used for cryptographic operations where an input is given to the card and an output is given to the user. Public and private keys are related, so that anyone can encrypt data with the public key of X, but X is the only one who can decrypt data encrypted with Xp . Notionally represented as Xs [Xp [D]] = D. Important thing is that keys are constructed so that deriving the private key from the public key is mathematically a far too heavy operation that anybody would try it. Encrypting with a public key and decrypting with a private key is analogous with real life example of putting mail to a mailbox and getting it out. Anyone can put the mail in the mailbox (encrypting with the public key). But getting the mail out is hard, unless you have the physical key (decrypting with the private key).[52] With some public key algorithms it is also possible to encrypt data using a private key and decrypt it with the corresponding public key [50].

Certificates If Alice wants to send an encrypted message to Bob1 , she need Bob’s public key. Because anyone is allowed to see Bob’s public key, Bob can put it publicly available. Alice will get Bob’s public key, but how can she trust that the key really belongs to Bob? X.509 also defines a framework for obtaining and verifying the authenticity of user’s public keys. An essential entity in the framework is a Certification Authority (CA), which issues a certificate for the user’s public key. Picture 4.1 shows some of the most crucial fields of the X.509 certificate. Now, if Alice has Bob’s certificate, which is certified by a certification authority trusted by Alice, Alice can also trust that she has Bob’s unforgeable public key. 1

Alice and Bob are traditional individuals used as examples in discussion of cryptographic protocols

CHAPTER 4. GENERIC MODEL

17

Serial number: 145 Signature algorithm: PKCS #1 Issuer:

CN=Test CA, O=CA, C=FI

Valid not before:

Mon Jan 13 2003 12:05:00 UTC

Valid not after: Subject:

Mon Jun 30 2003 23:59:59 UTC CN=Test User, O=HUT, C=FI

Public key:

0x15F3E5A3CE563BF56907684CE3...

Digital signature:

0x42F74AC53E97F23A35B7109EF...

Figure 4.1: X.509 Certificate Trust is achieved using digital signatures. In X.509, digital signature is created by calculating a digest over data to be signed and encrypting the digest with the private key of the signer (certification authority). The signature algorithm field identifies the exact digest and encrypting algorithms. Everyone who knows the signer’s public key, can verify the signature. The signature is encrypted with signer’s public key and the result is verified against the digest calculated over the certificate. The subject field of the X.509 certificate identifies a unique entity associated with the public key. The subject name is represented in Distinguished Name (DN) format defined in ITU recommendation X.500[2]. The certification authority is needed to ensure that entity in subject field really owns the private key associated with the public key. Furthermore the private key should be known only by the key owner. X.509 also mentions that a smart card protected with a pin number would be one possible place to store private keys. The private key itself can be created by the user to whom the key belongs or it can be created by a certification authority or a third party. If the user has created the key by herself, then the user can be sure that key has not been released to another entity. However, in this case the certification authority can not be sure, that the key owner is the

CHAPTER 4. GENERIC MODEL

18

only one who knows the key. For example, the keys on the Finnish electronic identity card are generated by the certification authority; The Finnish Population Register Centre. Its advantage is that service providers can trust the identity of the card user, because no other than the card user has the private key. Regardless of who created the key, it is important that the private key is untampered between creation and certification.

Certification Hierarchy Certification authorities can also certificate other certification authorities. Picture 4.2 shows a little hierarchy with one root and two nodes. Alice’s certificate is certificated by A and Bob’s by B. The certificates of A and B are certified by the Root CA. In this example, the hierarchy is two levels high, but in real world there can be more levels. If Alice now wants to communicate with Bob, she needs Bob’s certificate, A’s certificate and the root certificate. Certificates can be acquired from the directory using a directory protocol, e.g. Lightweight Directory Access Protocol (LDAP) [59]. Alice validates that A’s certificate is signed with root’s certificate and Bob’s certificate is signed by A’s certificate. If validation succeeds and Alice trusts root and have a valid root certificate, Alice also has valid Bob’s certificate. In this case Alice probably has valid root certificate because Alice and Bob share the same root certification authority.

Root CA

CA A

CA B

Alice

Bob

Figure 4.2: CA Hierarchy In practice, not everybody has the same root. In picture 4.3 Alice and Carol don’t

CHAPTER 4. GENERIC MODEL

19

share the same root. If Alice needs to communicate with Carol, Alice needs an authentic Another Root CA certificate. For Alice, obtaining the certificate is much harder than for Root CA. To help the situation, Root CA and Another Root CA could sign each others certificates with their private keys. There are no technical obstacles for this, but there might be problems with different policies among different certification authorities.

Another Root CA

Root CA

CA A

CA B

Alice

Bob

Carol

Figure 4.3: Cross Certified Root Certificates

Certificate Validation Each certificate between communicating parties has to be validated, using the following procedures. A basic requirement for certificate validation is that a validator has the authentic public key of the certification authority, which signed the certificate. A digital signature in the certificate is decrypted with the public key of the certification authority. A digest is calculated over the certificate, excluding the digital signature. Validation can continue, if the digest and the decrypted signature match. A X.509 Certificate has a fixed lifetime. The certificate has two timestamps, between which the certificate is valid. If current time is between the timestamps, validation can continue. In some cases, a certificate has to be revoked before it expires. The private key might be revealed, a smart card can get lost or the information in the certificate is not valid anymore. For these cases, the certification authority or its authorized third party maintains a Certificate Revocation List (CRL), which is a signed list of the serial numbers of the

CHAPTER 4. GENERIC MODEL

20

revoked certificates. During certificate validation, a validator has to have an up-to-date revocation list. If the certificate is not on the list, the certificate can be considered valid.

Strong Authentication Strong authentication is based on the public key certificate framework and the users are identified by the possession of their private keys. The following conditions have to be true for indisputable authentication: • Each user has a unique distinguished name. Each user has to trust naming authorities on this issue. • A private key is only known by the real owner of the key. • There is an unbroken chain of trusted points between users requiring to authenticate each other. This can be achieved with a certification authority that both endpoints trust and from which there is an unbroken chain of certificates to the endpoints.

Procedures X.509 defines one-, two-, and three-way authentication procedures. In all procedures there are two participants: A and B. In the following procedures BA is the return certification path from B to A. A{data} means that A has signed data with A’s public key and Bp [data] means that data is encrypted with B’s public key. tA is a timestamp generated by A, indicating message validity time. rA is a non-repeating number for protecting against replaying attacks and forgery. sgnData means some application specific data which also has to be authenticated. One-way authentication needs one message from A to B. Following actions are taken: • A sends a message BA, A{tA , rA , B, sgnData} to B. Optionally, if a session key or other sensitive information has to be conveyed to B, A sends a message BA, A{tA , rA , B, sgnData, Bp [encData]} to B.

CHAPTER 4. GENERIC MODEL

21

• B verifies the message. B checks the validity of the signed data with the help of methods described in this chapter. B checks that the intended recipient of the message is B itself. B Checks that timestamp is valid. If timestamp has some period of validity, B checks also that r is not replayed during timestamp validity time. As a result of the procedure, following is established: the authentication token was generated by A and it was not used more than once. The message was intended to be sent to B. In addition to one-way authentication, following actions are taken in two-way authentication: • B sends reply B{tB , rB , A, rA , sgnData} to A. Or if there is some encrypted data, B sends B{tB , rB , A, rA , sgnData, Ap [encData]} to A. • A verifies the signature, timestamps, and that A itself was the intended recipient. The same is established as in previous case as well as the authentication token in the reply was generated by B and it was not used more than once. The message was intended to be sent to A. Optionally both parties have mutually agreed on data, which was encrypted. Three-way authentication does not add any new properties, but timestamps are not needed. In addition to steps in two-way authentication, following steps are involved. A checks received rA is identical to the sent one. A sends message A{rB , B} to B. B verifies the signature and that received rB is identical to the sent one.

Chapter 5 Related work 5.1 AAA Registration Keys for Mobile IP AAA Registration Keys for Mobile IP is an Internet-Draft maintained by IETF’s Mobile IP working group. The draft specifies extensions to the base Mobile IPv4 registration messages, which enables mobile nodes and mobility agents to create dynamic security associations.[42] The draft assumes that the mobile node has a valid security association with an AAA server, such as RADIUS [45] or DIAMETER [13]. The AAA server in the home network and the home agent are also assumed to trust each other. In this case the home AAA server can dynamically create keys to be used in security associations between the mobile node and mobility agents. In a foreign network with a foreign agent, a mobile node can request keys for security associations with the following procedures. If the mobile node does not have a security association with the foreign agent, it includes MN-FA Key Request extension to the registration request. Respectively MN-HA Key request extension is included, if the mobile node doesn’t have an appropriate security association with the home agent. If key request extensions are added, the mobile node must also add a MN-AAA authentication extension [41] to the registration request after the key request extension. The foreign agent also acts as an AAA entity. When it receives a registration request with the key extensions, the request is formatted to the appropriate AAA message.

22

CHAPTER 5. RELATED WORK

23

The AAA request message is transferred to the home AAA server for further processing. The home AAA server generates requested keys and distributes the key needed for MNHA security association the home agent. The mobile node receives a registration reply from the foreign agent. If the reply has a MN-HA Key Material extension, the mobile node creates a dynamic security association with its home agent. In this case, the reply contains also Mobile-Home Authentication extension and the reply is verified with the newly created security association. Respectively, if the reply contains MN-FA Key Material extension, the mobile node creates a dynamic security association with the foreign agent. If a mobile node uses an existing security association with an AAA server, the mobile node and its home agent don’t need a security association between each other and thus they don’t need to share a secret. However, the mobile node still needs to share a secret with its home AAA server. Another problem with the draft is that it describes only registration through a foreign agent. The draft does not define how co-located registration works.

5.2 Internet Key Exchange The Internet Key Exchange (IKE) is a protocol, which provides authenticated keying material for security associations in a protected manner [21]. IKE is used as a default automated public-key based key management protocol for Internet Protocol Security (IPSec) [28]. In addition to IPSec, other protocols could also use IKE in key negotiation. IKE negotiation consists of two phases. In phase 1, a security association is negotiated between two peers. As a result of the negotiation the peers have a secure and authenticated channel for further communication. Phase 1 has two alternative modes: Main Mode and Aggressive Mode. In Main Mode, both the initiator and the responder send three messages. In Aggressive Mode, the initiator sends two messages and the responder sends one message. In phase 2, keying material is negotiated on the behalf of

CHAPTER 5. RELATED WORK

24

services, like IPSec. Phase 2 has only one mode: Quick Mode. In phase 2, the initiator sends two messages and the responder sends one message. X.509 certificates can be utilized in phase 1 of the IKE negotiation. In that case peers authenticate each other with a protocol similar to X.509 strong authentication framework. IKE negotiated keying material could be used for creating a dynamic security association between a mobile node and its home agent. However, IKE needs more than one round trip between peers, while Mobile IP registration needs only one round trip. This means that IKE cannot be used in Mobile IP registration without big modifications to the Mobile IP standard. On the other hand, if IKE negotiation is done before Mobile IP registration, there is a chicken-and-egg problem. A foreign agent might not let the IKE negotiation through, before the mobile node is registered, but the mobile node can not register before it has negotiated the keys.

5.3 Mobile IP Public Key Based Authentication An internet draft Mobile IP Public Key Based Authentication made by Stuart Jacobs and Scott Belgard addresses the problems with IKE negotiation and dynamic keys generated by AAA. The draft defines extensions to the Mobile IP base protocol, which uses publickey based authentication with the help of digital signatures and X.509 certificates [26]. Intention in the draft is to change the base protocol minimally. The registration should also work through a foreign agent and with a co-located care-of address. The protocol works as follows. A foreign agent advertises its presence using agent advertisement messages. They are modified from the base protocol so that the foreign agent has digitally signed the message. Message contains also a NAI and a certificate extension. The receiving mobile node verifies the authenticity of the message by the same procedures as in X.509 framework. If the verification succeeds, the mobile node processes the advertisement using the procedures described in the base protocol. When a mobile node sends a registration request using public-key authentication,

CHAPTER 5. RELATED WORK

25

it sets new A bit to 1 in the request. In the original registration request message, A bit was reserved for future use. If the A bit is set, it just means that Network Access Identifier (NAI) extension, a modified mobile node authentication extension and a mobile node certificate extensions are added to the request. The NAI extension contains the NAI of the mobile node and the NAI of the CA, which has signed the certificate of the mobile node. Network access identifiers are ASCII text of an arbitrary format and they must match subject and issuer name in the mobile node’s X.509 certificate. Table 5.1 shows mobile node authentication extension, which is quite similar to mobile-home authentication extension shown in Table 2.1. Both extensions have the same type, 32, but their meaning is different. The extension in the base protocol defines security context between two peers. The extension in the draft authenticates that the corresponding message is originated from the mobile node and anyone can check it. Auth type field defines used public-key algorithm. When the mobile node sends a registration request, it produces a digital signature over the registration request itself, type & length of the extension and all extensions prior to mobile node authentication extension.

Table 5.1: Mobile Node Authentication Extension 01234567 89012345 67890123 45678901 Type Length Auth Type Mobile Node (MN) Digital Signature...

The certificate extension contains the certificate of the mobile node and all needed CA certificates for establishing a trust hierarchy path. The extension is added after the mobile node authentication extension. When the foreign agent receives the registration request, it tries to verify the certificate of the mobile node. The foreign agent might have the same certification authority as the mobile node or the registration request itself may contain needed certificates to

CHAPTER 5. RELATED WORK

26

establish a trust hierarchy. If the foreign agent can not verify the signature, the request is discarded. Otherwise, the authenticity of the request is verified. If verification succeeds, the foreign agent forwards the request to the home agent. The foreign deletes the certificate from the request and adds a new NAI extension and a foreign agent authentication extension to the request. The authentication extension is the same as mobile node authentication extension, except the type is 33. The certificate extension is added after the authentication extension. When the home agent receives the request, it tries to verify the certificate of the foreign agent. If it succeeds, then the request itself is verified. The same procedures are repeated for the mobile node generated part of the request. If all verifications succeed, a registration reply is sent back to the mobile node. The reply has the same extensions and it is verified by the same procedure as the request. The protocol described in the draft, follows two-way authentication defined in X.509 framework. Mobile IP registration request and reply have timestamps, they contain intended recipient and the message itself is signed with the private key of the sender. The certification paths are also created and the certificates are checked against CRL lists. However, there are many problems with the draft: • The solution is not so compatible with the base Mobile IP protocol. The new A bit won’t work with the foreign agents not understanding the new draft. According to RFC 3344, registration requests with the reserved bits should be discarded. However, if the request is forwarded to the home agent, it will be discarded because it does not contain a foreign agent authentication extension. • The solution requires excessive computing power. Four public key operations are needed for a successful registration through a foreign agent. These public key operations are needed in every registration. While public key operations can be 1000 times more time consuming than secret key based [52], foreign and home agents can not serve as many mobile nodes as before. Handover performance can

CHAPTER 5. RELATED WORK

27

also degrade. At least if a mobile node creates the signature on a smart card, where it can take up to one second [5]. • Registration requests might contain many X.509 certificates. If the used key length is 2048 bits, a X.509 certificate for it can take almost 1000 bytes. Normally maximum IP packet size is 1500, so it is very likely that registration packets will be fragmented. • The draft is ambiguous about authentication algorithm on authentication extension. The draft just names the used signature algorithm and key length. Nothing is said about hash algorithms.

5.4

Mobile IP Registration Protocol: A Security Attack and New Secure Minimal Public-Key Based Authentication

Sufatry and Lamky have made a proposal, which tries to solve problems in the Jacobs’ draft[56]. The design principle was that a mobile node doesn’t do any public-key operations. This means that a mobile node won’t suffer from performance and CRL list retrieval problems. Public-key cryptography is used only between a foreign and a home agent. The protocol uses shared secrets in a security association between a mobile node and a home agent. It is quite implicit that the protocol does not solve the problem defined in this thesis.

5.5

Session Initiation Protocol

The Session Initiation Protocol (SIP) solves some of the user’s mobility problems at application level. With the help of SIP, users can have a single externally visible identifier regardless of their network location. [47] Users register their location along with their SIP address, which is just like an email address, to a SIP server. A SIP server keeps track of

CHAPTER 5. RELATED WORK

28

users’ locations and when an user starts a voice, video or text message session between an other user, the SIP server is queried for other user’s location. SIP solves the reachibility problem, but it does not solve the problem in this thesis. SIP works in application level, so it can not provide seamless mobility to all applications and not for any application either.

Chapter 6 Solution 6.1 Design Principles The solution will be based on AAA Registration Keys for Mobile IP and Mobile IP Public Key Based Authentication Internet-Drafts presented in chapter 5. Parts from both of the drafts will be combined to my solution, keeping in mind the following conditions: • X.509 Strong authentication framework is followed. • Smart card will be the most recommended way of storing user’s private keys. • Smart card operations are slow, so their use should be minimized. • RSA Laboratories Public-Key Cryptography Standards will be used where appropriate. These are not real standards, because RSA Laboratories can itself decide about each PKCS specification. However, many of them have become formal or de facto standards. • The prototype of the solution will be implemented using the Secgo Mobile IP product [53]. However, the solution is not exclusively bound to the Secgo Mobile IP.

29

CHAPTER 6. SOLUTION

30

6.2 Mobile IPv4 Settings on a Smart Card All the user’s Mobile IP settings should stored so that it is easy and safe to transfer them from one computer to another. A smart card is an ideal solution for this, while a smart card travels easily along the card owner. A smart card, which also has cryptographic keys, can contain about 5 kilobytes free space for user’s own settings [58]. At minimum, mobile node needs to know only its IP address, its home agent’s IP address, and a security association with its home agent. These settings take a couple of dozen bytes memory, so they fit easily on a smart card. Additionally, there can be more settings, like user’s NAI, Domain Name Server (DNS) addresses and domain search paths. Some or all of these settings can be optional. X.509 certificates are described using Abstract Syntax Notation number One (ASN.1) language [1]. ASN.1 is a notation for defining data types and their values. The standard itself defines some basic data types and rules for combining them into more complex types. The standard does not define the binary presentation of the data types. Instead, the standard is supplemented by specifications called encoding rules, which define bit by bit how the information is transferred [4]. The most used encoding rules are Basic Encoding Rules of ASN.1 (BER) and its derivates Canonical Encoding Rules of ASN.1 (CER) and Distinguished Encoding Rules of ASN.1 (DER) [3]. Mobile IP settings will be stored on a smart card using ASN.1. A program accessing the smart card must already support ASN.1 because of X.509 certificates, so the program does not need any extra libraries to decode Mobile IP settings. ASN.1 is not dependent of the used programming language, therefore Mobile IP products written in different programming languages and from different vendors are able to decode the settings. ASN.1 definition for the home network settings is presented in Appendix A. The definition itself does not contain any cryptographic keys. Instead, the key matching the subject field is retrieved from PKCS #11 or PKCS #15 application. If PKCS #11 API is used, settings are stored as a data object (CKO_DATA) and the

CHAPTER 6. SOLUTION

31

application name will be mipv4. PKCS #11 doesn’t give any special meaning for data objects, it just provides access to the data. PKCS #11 also doesn’t protect the data object from other than Mobile IP applications, PKCS #11 provides only access control to the whole smart card. [49] Smart cards can be accessed also using methods defined in ISO/IEC 7816-4 standard [25]. Picture 6.1 shows logical directory structure for smart card with the Mobile IP settings. Master File (MF) is a mandatory file and it is at the root of the file system. A MF can contain Elementary Files (EF) and Dedicated Files (DF). A DF can contain other DFs or EFs. An EF can not contain other files. Files have a two byte file identifier, which is used for addressing the files. File identifiers can be concatenated in order to address files inside DFs. For example, MF identifier is always 3F00. If we want to address EF 1234, which is under MF, we use 3F001234.

MF

DF MIPv4

DF PKCS#15

PIN1

EF MIP settings

Figure 6.1: Mobile IP application directory structure DFs can be addressed also by their name as defined in ISO/IEC 7816-5 standard [24]. The name is called Application Identifier (AID) and its length is up to 16 bytes. The first 5 bytes are Registered Application Provider Identifier (RID), which is unique among the vendors. The last 11 bytes are used to identify different applications. RID is not registered for the prototype implementation for this thesis. Instead, the

CHAPTER 6. SOLUTION

32

Mobile IP settings are stored under a DF file with AID 00 00 00 00 00 6D 69 70 76 34.

6.3 Mobile IPv4 Public Key Authentication Protocol Public key based operations can not be used in every registration request, because: • Creating a digital signature on a smart card can take more than one second. Round trip time in a cellular network using General Packet Radio Service (GPRS) can be more than one second [15]. This means that handover from wired network to cellular network causes more than two seconds break in data connections. • Public key based operations require much more computing power than secret key based. Number of mobile nodes a home agent can serve will decrease a lot. Instead of using digital signatures in every registration request, dynamic security associations described in AAA Registration Keys for Mobile IP[42] are utilized. If a mobile node and its home agent have a dynamic security association, it is used for creating a mobile-home authentication extension to the registration messages. If the communicating parties do not have the dynamic security association or it is expired, a new dynamic security association is created with the help of public key cryptography using a protocol defined later in this chapter.

Public Key Infrastructure The solution needs at least minimal Public Key Infrastructure (PKI). Both the mobile node and the home agent have to have RSA[50] private keys. There are several public key algorithms, but RSA is the only one which is implemented in several smart cards [5, 55, 32] The private keys must have a corresponding X.509 version 3 certificate and signer’s certificate must be trusted and securely transferred to the opposing side.

CHAPTER 6. SOLUTION

33

The certificates have to be in the format defined in RFC 3280 [22]. The X.509 Framework [1] defines standard extensions to the certificate, but they are far too general to make interoperable applications. RFC 3280 defines a subject alternative name extension, which allows additional identities to be bound to the subject of the certificate. These include e.g. IP or email address. At least home agent’s certificate should include its IP address.

Sending a registration request using PKI The registration request and a reply itself are same as in RFC 3344. Public key functionality is added by new extensions:

X.509 Certificate Extension X.509 certificate extension is needed for carrying certificates along the registration messages. The extension is optional, because the receiving party can already have the certificate or it can be fetched from a directory. For a mobile node fetching the certificate might be impossible, if the mobile node does not have network access.

Table 6.1: X.509 Certificate Extension 01234567 Type

89012345 67890123 45678901 Subtype Length X.509 Certificate (continued)

Table 6.1 shows fields of the extension. The extension uses the Long Extension Format [39], because x.509 certificates are usually longer than 256 bytes, which is maximum length in the Short Extension Format. The downside with the Long Extension Format is that the extension will be non-skippable and they are numbered between 0–127. If a foreign agent receives a non-skippable extension and it does not recognize the extension, the whole message must be discarded. The Long Extension Format extensions are

CHAPTER 6. SOLUTION

34

non-skippable because of compatibility with the RFC 2002, the old Mobile IP RFC [38]. The old RFC uses only one octet for the extension length field, while the Long Extension Format uses two octets. A RFC 2002 compliant foreign agent can not parse such extensions. In this thesis, the used type number is 45. The subtype field identifies whether the extenstions contains an actual certificate in the format defined in RFC 3280 (subtype value 1) or just a Uniform Resource Identifiers (URI) for the certificate (subtype value 2). URI subtype will only be useful in a home agent. The agent usually has a fast Internet connection, so it can retrieve the certificate. A mobile node might not have a network connection at the point when it needs the actual certificate. The length field indicates the length of the data in X.509 Certificate field.

MN-HA Key Request from PKI Extension The MN-HA Key Request from PKI Extension is not itself an extension. It is actually a MN-HA Key Request from PKI Subtype of the Generalized MN-HA Key Request Extension, but in this thesis it is shortened for simplicity. The Generalized MN-HA Key Request Extension [42] is shown in Table 6.2

Table 6.2: The Generalized Mobile IP MN-HA Key Request Extension 01234567 Type

89012345 67890123 45678901 Subtype Length Mobile Node SPI MN-HA Key Request Subtype Data

Internet Assigned Numbers Authority (IANA) has not yet allocated a number for the extension, but several implementations use number 42, which is from the non-skippable number range. In this thesis, the same number is used. The length field identifies the length of the extension, in which the Type, Subtype and Length fields are not included. Mobile Node SPI is the SPI that the mobile node will assign for the dynamically created

CHAPTER 6. SOLUTION

35

security association. MN-HA Key Request Subtype Data has the subtype specific data needed to create the dynamic registration key. MN-HA Key Request from PKI Extension will use 4 as a subtype number. Subtype data must contain user’s subject name, if the user’s X.509 certificate does not have email address in subject alternative name. If the certificate has the email address as an alternative subject name, the subject name is not needed in the key request extension. Instead, the Mobile Node NAI extension [40] must be added to the registration request. This is because the X.509 strong authentication model requires that authentication messages have the identity of the sender.

MN-HA Key Material from PKI Extension The MN-HA Key Material from PKI Extension is a subtype of the Generalized Mobile IP MN-HA Key Reply Extension [42]. The extension is shown in Table 6.3

Table 6.3: The Generalized Mobile IP MN-HA Key Reply Extension 01234567 Type

89012345 67890123 45678901 Subtype Length Lifetime MN-HA Key Reply Subtype Data

IANA has not allocated a type number for the extension. Several implementations use 43, which is from the non-skippable number range. In this thesis, the same number will be used. The Length field is the same as in the key request extension. The Lifetime field indicates how long (in seconds) the created key is valid. The Subtype number for the MN-HA Key Material from PKI Extension is 4. Subtype data contains an encrypted key and all the necessary information for creating a dynamic security association between a mobile node and its home agent. Subtype specific data of The Generalized Mobile IP MN-HA Key Reply Extension is shown in Table 6.4

CHAPTER 6. SOLUTION

36

Table 6.4: The MN-HA Key Material from PKI Extension data 01234567

89012345 67890123 45678901 SPI HA SPI Algorithm Identifier Replay Method Key Material Length Key Material Key Material (continued) Signature Length Signature Signature (continued)

The SPI field is same as in the key request. It is needed to determine which security context is used for decoding the key material. HA SPI is the SPI to be used in the dynamic security association. Algorithm Identifier and Replay Method are also needed when creating the dynamic security association. Numbers are same as in AAA Keys for Mobile IP draft. Key Material field contains the encrypted session key. The session key is encrypted with the public key of the user registering with the home agent. Signature field contains the session key signed with the private key of the home agent.

MN-PKI Authentication Extension MN-PKI Authentication Extension is a subtype of the Generalized Mobile IP Authentication Extension [41] (Table 6.5). The idea with the extension is to collect all new authentication applications into a single extension with different subtypes. IANA has assigned 36 as a type number for this extension.

Table 6.5: Generalized Mobile IP Authentication Extension 01234567 Type

89012345 67890123 45678901 Subtype Length SPI Authenticator

The maximum length of the Mobile-Home Authentication Extension is 256 bytes.

CHAPTER 6. SOLUTION

37

PKI authentication can not use that extension because the length of the digital signature can be more than 256 bytes. Generalized Mobile IP Authentication Extension is used instead and a new subtype for it is created. Used subtype number is 4. Authenticator field in the Generalized Authentication Extension is replaced with the fields shown in Table 6.6

Table 6.6: MN-PKI Authentication Subtype 01234567 89012345 67890123 45678901 Algorithm Identifier Replay Method Authenticator

Because a mobile node and a home agent are using public key based methods, they do not share a security association and SPI field can not identify used authentication algorithms and replay methods. Consequently, a value should be assigned from reserved SPI range (0–255) to be used with a public key based security association. In the implementation for this thesis number 4 is used. Algorithm Identifier and Replay Method fields are added in order to inform the home agent about used methods. Replay method values are same as in AAA Keys for Mobile IP Internet Draft [42]. Authenticator field contains a digital signature calculated over the registration request, extensions prior the MN-PKI Authentication Extension and other than authenticator field of the extension. The digital signature is calculated using RSASSA-PSS signature scheme defined in PKCS #1 [50]. Algorithm identifier field indicates the used hash algorithm. Defined values are: 1 for SHA-1 [35] and 2 for RIPEMD-160 [18]. Figure 6.2 shows needed extensions for making a successful PKI-based registration.

CHAPTER 6. SOLUTION IP header

UDP header

Registration request

38 MN−HA key request extension

Certificate extension

Optional extensions

Mobile IP PKI authentication extension

Optional extensions

Optional extensions

Mobile−Home authentication extension

Optional extensions

Authenticated fields IP header

UDP header

Registration reply

MN−HA key reply extension

Certificate extension

Figure 6.2: Needed extension in PKI-based Mobile IP registration

Protocol Operation 1. A mobile node tries to register with its home agent. The mobile node notices that it does not share a normal security association with its home agent. So it adds the MN-HA Key Request from PKI Extension, the X.509 Certificate Extension and the MN-PKI Authentication Extension to the request and sends it to the home agent. 2. The home agent receives the request, checks it as described in RFC 3344 and does additional checks because of the new extensions. The home agent finds out who signed the request and creates certification path up to the certificate trusted by the home agent. The validity of the user’s certificate is checked by the procedures described in the X.509 specification. If the certificate is not considered valid, the home agent sends a registration reply back with the error code 131: mobile node failed authentication described in RFC 3344. Otherwise the home agent verifies the signature using RSASSA-PSS signature verification scheme described in PKCS #1 specification. The hash algorithm for the verification is selected according to the algorithm identifier in the MN-PKI Authentication Extension. If the verification fails, a registration reply with the error code 131 is sent back to the mobile node. 3. The home agent continues with the creation of the session key. The key is random data with the length of at least 32 bytes (256 bits). The key will be sent over the insecure Internet, so it is encrypted with the public key of the user sending the registration request. The key is also signed with the private key of the home agent.

CHAPTER 6. SOLUTION

39

Same schemes and hash algorithms are used as in the MN-PKI Authentication Extension of the request. 4. The home agent creates a dynamic security association and records used algorithms and replay methods along with the signed and encrypted key material to the MN-HA Key Material from PKI Extension. The home agent adds also X.509 Certificate Extension to the reply. Finally, the reply is authenticated with the MN-HA Authentication Extension using the newly created dynamic security association. 5. When the mobile node receives the reply, it is processed as described in the Mobile IP base protocol. Additionally, new extensions are processed. The key material is decrypted using user’s private key. The authenticity of the signature is checked using the same procedures as in the home agent. Additionally, if the home agent’s certificate has the IP address in subject alternative name, the IP address must match the home agent field in the registration reply. If the verification succeeds, the mobile node creates the dynamic security association with the information obtained from the MN-HA Key Material from PKI Extension. Finally, the dynamic security association is used for the verification of the reply. 6. As long as the dynamic security association is valid, it is used in the subsequent registration requests. When an association’s lifetime expires, it is removed and the next registration is done using PKI authentication. A Formal description of the protocol using Petri nets [34] is in Figure 6.3. The Petri net will be used in Chapter 7, when analyzing the protocol.

6.4

Implementation

A prototype of the protocol was made as an add-on to Secgo Mobile IP client (mobile node) and Secgo Mobile IP server (home agent). The Secgo Mobile IP products itself are

CHAPTER 6. SOLUTION

40 no DSA

error/lost message no DSA

process registration generate DSA

DSA expires

send pki rreq

DSA expires

DSA

accept reg

DSA

send normal reg

process normal reg

receive error normal reply

Mobile node

Home agent

Figure 6.3: P/T net commercial, the thesis related smart card and PKI authentication modules are the only part of the implementation which is prototype. Because of the modular architecture of Secgo Mobile IP products, adding new features was easy. Changes to the existing code were minimal.

Mobile Node Figure 6.4 shows the mobile node architecture at a coarse level. The smart card subsystem is a totally new component. It monitors available smart cards and provides a simple and uniform API to the rest of the program, regardless of the used smart card. Subsystem accesses smart cards through PC/SC Resource Manager [12] and the exact API is the Smart Card Resource Manager API defined by Microsoft [31]. PC/SC Resource Manager implementations using the same API exists also for other platforms [16], but the mobile

CHAPTER 6. SOLUTION

41

node prototype was made only for Windows. Furthermore, only smart cards with PKCS #15 directory structure are supported. The subsystem monitors smart card readers. If it notices that a new card is inserted, it tries to read the Mobile IP settings. If the settings are protected with a PIN code, a dialog is shown to ask the code. When the code is entered, ASN.1 representation of the settings are decoded and the right RSA key is searched from the PKCS #15 application. The settings are stored only in mobile node’s memory, nothing is written to the hard disk. When all the information is read from the card, a new home network is added to the mobile node engine and a new public key based security association is added to the security subsystem. When the mobile node engine notices that a new home network is added, it tries to register with the home agent. During the registration, the New Extensions module searches for available security associations. The module founds that the mobile node has a public key based security association with the home agent. The Certificate and the Key Request extension are added to the request. The request is signed on a smart card and the authentication extension is added to the request. The New Extensions module investigates registration replies. If a key material extension is found, a dynamic security association is created. The Key material is decrypted on a smart card. The mobile node needs a trusted certificate for the verification of the reply. The implementation can use the certificates with the CA bit on a smart card or trusted certificates may be read from the filesystem. When the smart card subsystem notices that a card is removed, the memory of the home network settings, the public key security association and the dynamic security association is freed. This also means that the settings are completely removed, because the settings are not written to the hard disk.

CHAPTER 6. SOLUTION Mobile Node Engine

42 Extension Subsystem ExtensionHandler + RegisterExtension

HomenetHandler + AddHomenet + RemoveHomenet

Smart Card Subsystem

New Extensions

Old Extensions

SA Subsystem

CardHandler

DynamicSA + CreateDynSA PkiSA ISO7816Interface + AddPkiSA + Sign + Verify

Figure 6.4: Mobile Node Architecture

Home Agent Figure 6.5 shows the home agent architecture in coarse level. Changes are quite similar as in the mobile node code. The home agent is implemented on the Linux platform. The smart card subsystem is not included in the home agent. Smart card operations are so slow that the number of served mobile nodes will decrease, if a home agent does digital signatures on a smart card. Instead, all PKI based operations are made on the software. However, the public key security association implementation is exactly the same as in the mobile node, only the back-ends differ. A certificate retrieval e.g. from LDAP is not implemented, the implementation can

CHAPTER 6. SOLUTION

43

verify a registration only if the request contains all the needed certificates.

Home Agent Engine

Extension Subsystem ExtensionHandler + RegisterExtension

New Extensions

Old Extensions

SA Subsystem

Crypto Protorocls

DynamicSA + CreateDynSA PkiSA RSA + AddPkiSA + Sign + Verify

Figure 6.5: Home Agent Architecture

Chapter 7 Analysis This chapter evaluates the quality of the results of this thesis. The analysis covers the produced specification and the prototype implementation. The evaluation criteria presented in Chapter 3 are used as a base for the analysis.

7.1 Security Security is the most crucial requirement for the new authentication protocol. However, proving that the solution is secure is not straightforward. In this analysis, used algorithms are first analyzed, followed up by the analysis of the protocol created by combining the algorithms. Finally, the actual implementation is analyzed.

Algorithms The new algorithms introduced in the PKI authentication protocol are: SHA-1 [35] and RIPEMD-160 [18] (one-way hash functions) and RSA [23] (public-key cryptography functions). The base Mobile IP protocol defined in RFC 3344 uses MD5 hash function [46]. All the Mobile IP implementations have the MD5, but it will not be used in the PKI authentication protocol, which uses hash function with signature schemes. Hans Dobbertin has found a collision in MD5 [17], so MD5 is not recommended to be used with signature schemes. Instead, Dobbertin recommends SHA-1 and RIPEMD-160. RFC 3344 uses 44

CHAPTER 7. ANALYSIS

45

MD5 in conjunction with HMAC [29], which is not vulnerable to collision attacks [17]. National Institute of Standards and Technology (NIST) has developed SHA-1 with the help from National Security Agency (NSA). SHA-1 specification is freely available from NIST web site [35] and it is also published as American National Standards Institute (ANSI) standard. It produces a digest with the length of 160-bits. SHA-1 is a technical revision of SHA-0. NIST has not published flaws in SHA-0 or any detailed design criteria of the algorithm. There exists a theoretical attack against SHA-0 with the complexity of 261 [14]. The same attack does not work against SHA-1. It is not known, is this the attack that NIST did not published. Currently there are not any known cryptographic attacks against SHA-1. RIPEMD-160, as its name implies, produces digests with the length of 160-bits. Hans Dobbertin, Antoon Bosselaers and Bart Preneel have designed it and its design principles are open. Neither any standardization body has standardized RIPEMD-160 nor any government is recommending using it. Currently there are not any known attacks against RIPEMD-160. However, RIPEMD-160 is not so widely used as SHA-1, so the cryptanalysts have not researched it as much as SHA-1. RSA algorithm, which is named after its inventors Ronald L. Rivest, Adi Shamir, and Leonard Adleman, was invented back in 1977. The algorithm specification is publicly available e.g. from RSA Security’s web site [50]. Institute of Electrical and Electronics Engineers (IEEE) has also standardized it [23]. The security of RSA algorithm is based on the problem of factoring large numbers. It has not been mathematically proven that factoring large numbers is the only way to break up RSA. On the other hand, it has not either been mathematically proven that there exists other ways to break up RSA. NIST recommends that if the secret is wanted to be secret up to year 2015, RSA key size should be at least 1024-bit [36]. The Finnish electronic identification card has a RSA key with the size of 1024-bit and it is valid three years [58]. Using the card with Mobile IP PKI authentication protocol should be secure enough.

CHAPTER 7. ANALYSIS

46

Cryptographic Schemes One-way hash functions and the RSA algorithm are combined together and used in encryption schemes and signature schemes with appendix. The exact schemes are RSASSAPSS for signature and RSAES-OAEP for encryption [50]. There are not any known attacks against RSASSA-PSS. RSASSA-PSS can be considered as secure as the plain RSA algorithm [50]. RSASSA-PSS scheme is also primary recommendation for a digital signature according to the NESSIE project [37]. To the current understanding, there are no known attacks against RSAES-OAEP. There has been discussion whether RSAES-OAEP is vulnerable against adaptive chosen ciphertext attacks [9]. However, recent results have showed that RSAES-OAEP is secure against adaptive chosen ciphertext attacks [20]. So, breaking RSAES-OAEP is as hard as breaking the plain RSA algorithm.

The Authentication Protocol Even if RSAES-OAEP is vulnerable to chosen ciphertext attacks, it will not matter in this case. In chosen ciphertext attack, adversary selects the ciphertext and somehow gets the corresponding plaintext. The home agent can select the ciphertext in key material, but it is not able to get plaintext back from a mobile node. When the mobile node decrypts the ciphertext, it notices that the decrypted text is not singed by the home agent and discards the message. Another flaw with using the RSA algorithm is to encrypt the plaintext and after that sign the ciphertext [6]. The protocol does not suffer from this. A registration reply contains a session key both signed and encrypted. Because the signature of the session key is in the reply without encryption the receiver can not claim that any other than the real key was received. Because of performance reasons, only the session key is encrypted. The length of the session key is less than mobile node’s public key. This ensures that mobile node has to

CHAPTER 7. ANALYSIS

47

do only one decryption operation on a smart card. If the home agent signs the session key and then encrypts the key and signature, the length of the data to be encrypted will be longer than mobile node’s key and mobile node has to do two costly operations on a smart card. The protocol follows X.509 strong authentication framework [1]: • The registration request message contains the identity of the mobile node. Either in a MN-HA Key Request extension or in a NAI extension. Authentication is actually generated by the mobile node, it is signed with the private key corresponding the identity the request has and the validity of the certificate is checked. The request contains recipient’s identity (IP address) in the actual request defined in RFC 3344. The request can not be replayed, because it is replay protected by the normal means defined in RFC 3344. • The authentication token in the reply is actually generated by the home agent, because the token is signed with the session key. The session key is signed with the private key of the home agent. The reply is intended to be sent to the right mobile node, because the request and reply contains a 64-bit identification field for matching requests with replies; the mobile node checks that the reply is for the request it has sent. The reply can not be replayed because it is replay protected by the normal means defined in RFC 3344. The mobile node does not do CRL checking for home agent’s certificate. However, when using shared secrets there are not any ways of checking whether the home agent is the only party knowing the shared secret. Because X.509 strong authentication framework is followed and because the protocol is based on secure algorithms and schemes, it can be safely assumed that the protocol verifies the identity of the communicating parties at least as reliably as with shared secrets. The protocol does not open any new possibilities to reveal the actual traffic. The Mobile IP protocol is not responsible of encrypting the mobile node’s actual traffic. The

CHAPTER 7. ANALYSIS

48

actual traffic can be encrypted e.g. using IPSec [28]. IPSec uses IKE [21] for negotiation the actual session keys. IKE can use same private keys for the negotiation as the protocol developed in this thesis. However, even if the Mobile IP session keys are revealed, adversary can not exploit session keys when trying to break the actual IPSec protected traffic. The protocol does not hide the identity of the communicating parties during registration. The registration request has the user’s subject name or NAI. If an eavesdropper can monitor the request packets between the mobile node and its home agent, it is possible to follow mobile node’s movements. However, situation is not worse than in the base Mobile IP protocol using NAIs. In that case user’s NAI is also transmitted in clear text over the Internet. Petri net in Figure 6.3 is converted to PROD’s net description language [57]. The definition is in Appendix B. With the help of the PROD, the protocol was verified not to have deadlocks or livelocks. Appendix C shows the results of the verifications.

The Implementation The implementation consists of several parts: PKI authentication specific code written by the author of the thesis, existing code of Secgo Mobile IP, libraries provided by operating system’s vendor and third party public key crypto libraries. Operating system code and existing code of Secgo Mobile IP are not analyzed, because their security is out of the scope of this thesis. One of the important things in the implementation of cryptographic functions is that random numbers are truly random. For example, PKCS #1 encryption requires that the encrypted text is padded with random bytes. If an adversary can predict random numbers beforehand, it is easier to break the encrypted text. The crypto library used in the prototype implementation follows RFC 1750 randomness recommendations [19] and it produces random numbers with a good quality. The crypto library SHA-1 implementa-

CHAPTER 7. ANALYSIS

49

tion is certified by NIST and the library is continuously updated if new flaws are found. Currently there are not any attacks against crypto library implementation. The library is not vulnerable to the recently found RSA timing attack [11]. The implementation is not tied to any specific third party crypto libraries. As Figures 6.4 and 6.5 shows, PkiSa package is the only package, which is calling public key functions. Home agent and mobile node have the same PkiSa package, but they are using different functions, so replacing the whole crypto library is an easy task. The code, which is parsing the new extensions, is the most vulnerable to remote exploits. A home agent and a mobile node are listening for registration packets coming from the Internet. Anyone can send a malformed registration packet to Mobile IP entities. Malformed packets might have wrong length fields. For example, the X.509 certificate extension could indicate that the length of the certificate is 1000 bytes, while the whole registration message would only have 800 bytes. If the implementation does not check the validity of every length field, it tries to read 1000 bytes, and a buffer overflow occurs when no more data is available. In the worst case, the malformed packet contains code which is executed when a buffer overflows occur. The implementation was tested both statically and dynamically against malformed packets. Static test were done using RATS [54] and Flawfinder [60] tools, which inspect the code and report if any suspicious code is found. The tools did not found any real errors in the source code. Dynamic testing was done by sending registration packets with the new extensions, but with wrong length fields. Both the mobile node and the home agent survived without crashing.

Security Conclusion Table 7.1 shows how the security criteria defined in Chapter 3 was met. The protocol does not hide the entity of the communicating parties. The base Mobile IP protocol has the same property, so the solution can be considered as secure as the base protocol.

CHAPTER 7. ANALYSIS

50

7.2 Compliance with the standards The solution is compatible with RFC 3344. The registration request and reply messages are exactly same as in normal Mobile IP. The new MN-PKI Authentication Extension is compatible with the Generalized Mobile IP Authentication Extension [41]. The solution is compatible with Mobile IP NAT/NAPT Traversal using UDP Tunnelling [30]. And therefore the solution works if there are devices doing Network Address Port Translation (NAPT) between a mobile node and its home agent. The solution works with the co-located care-of address without any problems. Registration through a normal RFC 3344 foreign agent does not work. This is because the new extensions are non-skippable. The extensions are non-skippable because RFC 3344 defines that extensions using the Long Extension Format are non-skippable. Using the Long Extension Format is in practice the only choice, if digital signatures using RSA algorithm are used. If the key length of the used RSA key is 2048-bit, the signature is also 2048-bit and it will not fit in the Short Extension Format, which has a maximum length of 256 bytes. However, if the foreign agent just understands that the new extensions are needed only between a mobile node and a home agent, the solution works through a foreign agent. Smart card operations are compatible with the Mobile IP RFCs. Smart cards are only used for storing settings and keys and they are not visible outside the mobile node. RFCs do not specify how settings are stored.

7.3 Operation in heterogeneous environment The implementation does not use any undocumented functions or methods when communicating with smart cards. PC/SC architecture [12] is used for managing smart card resources. This ensures that the implementation is not dependent on any specific smart

CHAPTER 7. ANALYSIS

51

card reader. Instead, the implementation works with every smart card reader, which conform to PC/SC specifications. In practice, every smart card reader is compatible with the PC/SC specifications, because the Microsoft Windows supports only PC/SC compatible smart card readers, so in practice the implementation works with all commercially available smart card readers. The implementation works with smart cards, which have an ISO 7816-4 [25] interface and a PKCS #15 [48] directory structure. The implementation is tested with Setec [55] and Miotec [32] smart cards. The Mobile IP settings were put also on The Finnish electronic identification card and the registration worked without any problems with the keys issued by The Finnish Population Register Centre. The prototype mobile node implementation works with Windows 2000 and XP. The only operating system specific code in the implementation is a dialog asking for a PIN code. The implementation uses PC/SC Resource Manager API, which is defined by Microsoft. However, because there are implementations providing the same API for several UNIXes [16], porting to other operating systems is easy. The source code remains same; the compiled code is only linked with a different library.

7.4 Performance Mobile Node The performance of the mobile node was tested on Microsoft Windows 2000 running on an Intel Pentium 3 700MHz laptop with a Utimaco CardMan 4000 PCMCIA smart card reader and a Setec smart card. The registration took on average 3 seconds. The public key based registration was done through ethernet network and the home agent was in the same subnet. Even if the registration takes 3 seconds, there would not be any breaks in the data flow in the most cases. The public key based registration is done only when a dynamic security association expires and the actual data keeps flowing during registration, if the mobile node does not roam when waiting for the reply. There might be

CHAPTER 7. ANALYSIS

52

a little break, if dynamic security association expires at the same time when the mobile node roams to different subnet. 3 seconds break in data flow is so short, that ongoing TCP connections will not terminate. However, if the mobile node roams continuously between different subnets and it is staying less than 3 seconds in one subnet, it can not establish a new dynamic security association.

Home Agent The performance of the home agent was tested on Linux Operating System running on a desktop computer with an AMD Duron 700 Mhz processor and an Intel EtherExpress Pro 100 Mbit network interface card. Processing one public key based registration request took on average 110 milliseconds. Processing a normal registration request with the same computer took on average 2 milliseconds. If the lifetime of the dynamic security association is one hour, following calculations show that the number of mobile nodes the home agent can serve is decreased by less than 30 %. A home agent uses processor time for processing registration requests and for forwarding and tunneling the actual traffic. If the computer described above can serve 5000 normal mobile nodes, which are registering every two minute, processing registration requests during one hour takes 5 minutes of processor time. Then the home agent can use 660 milliseconds of processor time per one mobile node for routing the actual traffic. If public key based registration is used and number of mobile nodes is 3500 (70 % of 5000). Processing public key based registrations takes 6 minutes 25 seconds and normal registration takes 3 minutes 30 seconds. In this case the home agent can spend 859 milliseconds per one mobile node for routing the actual traffic. So the home agent can serve more than 3500 mobile nodes or the number of mobile nodes is decreased less than 30 %.

CHAPTER 7. ANALYSIS

53

7.5 Usability The implementation is easy to use. A user just has to insert a smart card to a reader. The implementation checks if the card has the Mobile IP settings. If the settings are found, a dialog is shown asking for a PIN code. When the PIN code is entered, settings and CA certificates are read from the card and mobile node registers automatically with its home agent. The user does not have to configure anything and there is no need to have any settings on a host computer, because all the needed settings are read from the card. The settings are keeped only on memory, nothing is written to the hard drive of the host computer. When the user removes the card from the reader, all the settings are removed from the host computer. After that the mobile node is ready to use a new user profile from a different smart card.

7.6 Future Improvements The solution does not prevent adding support for route optimization [43]. Route optimization defines four new message types, which are used for informing mobile node’s current location to correspondent nodes. New messages are sent to same UDP port as registration request and reply messages and they can use same extensions. The public key based authentication protocol does not conflict with this. If route optimization is used, there is no need to use the extensions defined in this thesis. Route optimization messages have to be authenticated somehow, so it should be investigated if the extensions defined in this document can be used for the authentication of the route optimization.

CHAPTER 7. ANALYSIS

54

Table 7.1: Evaluated Security Metrics Criterion 1 Question Metric Question Metric Question Metric Question Metric Criterion 2 Question Metric Question Metric Question Metric Criterion 3 Question Metric Question Metric Question Metric Question Metric Question Metric Question Metric Criterion 4 Question Metric Question Metric Question Metric Question Metric Question Metric Question Metric

Secure Algorithms Number of different algorithms 3 Number of published algorithms 3 Have standardization bodies standardized used algorithms? Yes, 2 Are they any known attacks against used algorithms? No, 0 Secure Cryptographic Schemes Number of different schemes 2 Number of published schemes 2 Are they any known attacks against used schemes? No, 0 Secure Protocol Does the authentication protocol follow any widely used authentication framework? Yes Are the algorithms combined so that they are not vulnerable to any known attacks? Yes Does the protocol ensure that the identity of the communicating parties is verified reliably? Yes Does the protocol open any possibilities to reveal the actual traffic? No Does the protocol hide the identity of the communicating parties? No Does the protocol have deadlocks or livelocks? No Secure Implementation Does the implementation properly handle messages that have incorrect extensions? Yes Is the implementation vulnerable against implementation specific attacks against used algorithms? No Does the implementation of the algorithms have any certificates? Yes Are random numbers truly random? Yes Number of real errors found in the source code with RATS [54] 0 Number of real errors found in the source code with Flawfinder [60] 0

Chapter 8 Conclusions 8.1 Summary I have created a method for transferring user’s Mobile IPv4 settings easily from one mobile node to another. All the settings and also the registration keys are stored on a smart card. The method simplifies deployment of Mobile IPv4. Because the method does not require any user specific settings stored on a mobile computer, a mobile node software can be included on an operating system image and the exactly same image is installed on every mobile computer. When the user wants to make his computer mobile, he just gets a personal smart card from an administrator. After the user has inserted the smart card in a reader and entered his PIN code, the computer is mobile. The method is not restricted to credit card size smart cards. If a computer does not have a smart card reader, tokens connected directly to an USB connector can be used. I also created a public key based authentication protocol for Mobile IPv4. The protocol enables mobile nodes and home agents to establish dynamic security associations without sharing a secret between a mobile node and a home agent beforehand. The protocol eases Mobile IPv4 key management. A mobile node does not need anymore a new key to be used only in Mobile IPv4. Instead, the mobile node can use the same public/private key pair as it uses already e.g. with IPSec. Even though public key operations are time consuming, the protocol is quite efficient. A mobile node normally does not no-

55

CHAPTER 8. CONCLUSIONS

56

tice any extra delays A home agent can not serve as many mobile nodes as with normal registration, but the decrease is not remarkable. The security of the protocol is at least as good as with shared secrets. In addition to creating a solution to the problem, I also made an implementation of the solution. The implementation is just a prototype, but it shows that the theory works in practice. With little improvements, the implementation can be used in real environments. The created solution solves the problem well. Most of the criteria were fullfilled. The biggest limitation with the solution is that it does not work with foreign agents not understanding the new extensions.

8.2 Future work This thesis has raised at least following research topics: 1. The public key based authentication protocol works only between a mobile node and a home agent. In the future, the protocol might be extended to work between mobile nodes and foreign agents. 2. With the help of the protocol, a home agent can reliably authenticate a mobile node. The protocol only authenticates the mobile node, it does not decide which mobile nodes are authorized to use the Mobile IP service. It should be decided is authorization a protocol or implementation issue. 3. The certificate retrieval e.g. from LDAP and the CRL checking of the certificate should be implemented and their impact on performance should be researched. 4. Mobile IP settings are not the only settings, which can be put on a smart card. Applicability of putting IPSec settings on a smart card should be reseached.

References [1] Information technology - open systems interconnection - the directory: Public-key and attribute certificate frameworks. Technical report, International Telecommunication Union, 2000. [2] Information technology - open systems interconnection - the directory: Overview of concepts, models and services. Technical report, International Telecommunication Union, January 2001. [3] Information technology - abstract syntax notation one (asn.1): Specification of basic notation. Technical report, International Telecommunication Union, July 2002. [4] Information technology - asn.1 encoding rules: Specification of basic encoding rules (ber), canonical encoding rules (cer) and distinguished encoding rules (der). Technical report, International Telecommunication Union, July 2002. [5] Aladdin Knowledge Systems. etoken pro ftp://ftp.ealaddin.com/pub/etoken/enterprise/fs_pro.zip.

specifications,

2002.

[6] R. Anderson and R. Needham. Robustness principles for public key protocols. In CRYPTO: Proceedings of Crypto, 1995. [7] R. J. Anderson. Security Engeering: A Guide to Building Dependable Distributed Systems. Wiley Computer Publishing, 2001. [8] V. R. Basili, G. Caldieira, and H. D. Rombach. The goal question metric approach. Technical report, 1994. [9] M. Bellare and P. Rogaway. Optimal Asymmetric Encryption - How to Encrypt with RSA. In In A. De Santis, editor, Advances in Cryptology . Eurocrypt .94, volume 950 of Lecture Notes in Computer Science, pages 99–111. Springer Verlag, 1995. [10] S. Bradner. Key words for use in rfcs to indicate requirement levels IETF RFC 2119. March 1997. [11] D. Brumley and D. Boneh. Remote timings attacks are practical, 2003. [12] Bull CP8, Gemplus, Hewlett-Packard, IBM, Microsoft, Schlumberger, Siemens Nixdorf, Sun Microsystems, Toshiba and VeriFone. Interoperability Specification 57

REFERENCES

58

for ICCs and Personal Computer Systems: Part 1. Introduction and Architecture Overview, December 1997. [13] P. R. Calhoun and et.al. Diameter base protocol. IETF Internet Draft. December 2002. (work in progress) [14] F. Chabaud and A. Joux. Differential Collision in SHA-0. In H. Krawczyk, editor, Advances in Cryptology - CRYPTO ’98, volume 1462, pages 56–71, 1998. [15] R. Chakravorty, J. Cartwright, and I. Pratt. Practical Experience with TCP over GPRS. In Proceedings of the IEEE Global Communications Conference (IEEE GLOBECOM 2002), Nov. 2002. [16] D. Corcoran. MUSCLE PC/SC Lite API: Toolkit API Reference Documentation, March 2001. Referred 6.3.2003, http://www.linuxnet.com/middleware/files/pcsclite-1.1.1.tar.gz. [17] H. Dobbertin. The Status of MD5 After a Recent Attack in RSA Laboratories’ CryptoBytes Volume 2, Number 2 – Summer 1996. Referred 18.4.2003, ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf. [18] H. Dobbertin, A. Bosselaers, and B. Preneel. RIPEMD-160: A Strengthened Version of RIPEMD, April 1996. [19] D. Eastlake, S. Crocker, and J. Schiller. Randomness recommendations for security; IETF RFC 1750. December 1994. [20] E. Fujisaki, T. Okamoto, D. Pointcheval, and J. Stern. RSA-OAEP is Secure under the RSA Assumption. In In J. Kilian, editor, Advances in Cryptology . Crypto 2001, volume 2139 of Lecture Notes in Computer Science, pages 260–274. Springer Verlag, 2001. [21] D. Harkins and D. Carrel. The internet key exchange (ike); IETF RFC 2409. November 1998. [22] R. Housley. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile; IETF RFC 3280. April 2002. [23] IEEE Std 1363-2000: Standard Specifications for Public Key Cryptography, January 2000. [24] International Organization for Standardization. Iso/iec 7816-5: Identification cards – integrated circuit(s) cards with contacts – part 5: Numbering system and registration procedure for application identifiers. Technical report, 1994. [25] International Organization for Standardization. Iso/iec 7816-4: Information technology – identification cards – integrated circuit(s) cards with contacts – part 4: Interindustry commands for interchange. Technical report, 1995.

REFERENCES

59

[26] S. Jacobs and S. Belgard. Mobile ip public key based authentication. Internet Draft. July 2001. (work in progress, expired) [27] D. B. Johnson, C. E. Perkins, and J. Arkko. Mobility support in IPv6. IETF Internet Draft. October 2002. (work in progress) [28] S. Kent and R. Atkinson. Security architecture for the internet protocol; IETF RFC 2401. November 1998. [29] H. Krawczyk, M. Bellare, and R. Canetti. Hmac: Keyed-hashing for message authentication; IETF RFC 2104. February 1997. [30] H. Levkowetz and S. Vaarala, editors. Mobile IP NAT/NAPT Traversal using UDP Tunnelling. IETF Internet Draft. November 2002. (work in progress) [31] Microsoft Corporation. Platform SDK: Security: Smart Card Resource Manager API, February 2003. Referred 6.3.2003, http://msdn.microsoft.com/library/default.asp?url=/library/enus/security/security/smart_card_resource_manager_api.asp. [32] Miotec Oy. Miotec PKI Card Technical Data Sheet, January 2003. Referred 6.5.2003, http://www.miotec.fi/communications/presentation_material/brochures/Miotec PKI Card DS v1[1].04.pdf. [33] M. Mouly and M.-B. Pautet. The Gsm System for Mobile Communications. Telecom Publishing, 1992. [34] T. Murata. Petri Nets: Properties, Analysis and Applications. In Proceedings of the IEEE, pages 541–580, Apr. 1989. NewsletterInfo: 33Published as Proceedings of the IEEE, volume 77, number 4. [35] National Institute of Standards and Technology. FIPS PUB 180-1: SECURE HASH STANDARD, April 1995. [36] National Institute of Standards and Technology. Key Management Guideline, Workshop Document, November 2001. Referred 18.4.2003, http://csrc.nist.gov/CryptoToolkit/kms/key-management-guideline(workshop).pdf. [37] NESSIE consortium. Portfolio of recommended cryptographic primitives, February 2003. Referred 24.4.2003, https://www.cosic.esat.kuleuven.ac.be/nessie/deliverables/decision-final.pdf. [38] C. Perkins, editor. IP mobility support; IETF RFC 2002. October 1996. [39] C. Perkins. IP mobility support for IPv4; IETF RFC 3344. August 2002.

REFERENCES

60

[40] C. E. Perkins and P. R. Calhoun. Mobile IP Network Access Identifier Extension for IPv4; IETF RFC 2794. March 2000. [41] C. E. Perkins and P. R. Calhoun. Mobile IPv4 Challenge/Response Extensions; IETF RFC 3012. November 2000. [42] C. E. Perkins and P. R. Calhoun. AAA registration keys for mobile IP. IETF Internet Draft. March 2003. (work in progress) [43] C. E. Perkins and D. B. Johnson. Route optimization in mobile IP. IETF Internet Draft. September 2001. (work in progress, expired) [44] J. Postel, editor. Internet protocol. September 1981. DARPA Internet program protocol specification. [45] C. Rigney, A. C. Rubens, W. A. Simpson, and S. Willens. Remote Authentication Dial In User Service (RADIUS); IETF RFC 2865. June 2000. [46] R. L. Rivest. The MD5 Message-Digest Algorithm; IETF RFC 1321. April 1992. [47] J. Rosenberg and et. al. SIP: Session Initiation Protocol; IETF RFC 3261. June 2002. [48] RSA Laboratories. Pkcs #15 v1.1: Crpytographic token information syntax standard. Technical report, June 2000. [49] RSA Laboratories. Pkcs #11 v2.11: Crpytographic token interface standard. Technical report, November 2001. [50] RSA Laboratories. Pkcs #1 v2.1: Rsa crpytography standard. Technical report, June 2002. [51] B. Schneier. Crypto-Gram Newsletter September 30, 2001. Referred 13.4.2003, http://www.counterpane.com/crypto-gram-0109a.html. [52] B. Schneier. Applied Cryptography Second Edition: protocols, algorithms, and source code in C. John Wiley & Sons Inc., 1996. [53] Secgo Group Oy. Secgo Mobile IP product, January 2003. Referred 2.2.2003, http://www.secgo.com/products/secgo_mobile_ip.html. [54] Secure Software, Inc. RATS - Rough Auditing Tool for Security, March 2003. Referred 13.4.2003, http://www.securesoftware.com/download_rats.htm. [55] Setec Oy. SetCard Secure http://www.setec.fi/techdocs/EID_tech.pdf.

electronic

identity,

2002.

[56] Sufatrio and K. Y. Lam. Mobile ip registration rrotocol: A security attack and new secure minimal public-key based authentication. In 1999 International Symposium on Parallel Architectures, Algorithms and Networks (ISPAN ’99), 1999.

REFERENCES

61

[57] K. Varpaanniemi, J. Halme, K. Hiekkanen, and T. Pyyssalo. PROD Reference Manual, August 1995. [58] Väestörekisterikeskus. Väestörekisterikus - yleistä / sähköinen henkilökortti. Referred 10.12.2002, http://www.fineid.fi/. [59] M. Wahl, T. Howes, and S. Kille. Lightweight directory access protocol (v3); IETF RFC 2251. December 1997. [60] D. A. Wheeler. Flawfinder, March 2003. http://www.dwheeler.com/flawfinder/.

Referred 13.4.2003,

Appendix A Mobile IPv4 settings ASN.1 module MobileIPv4SettingsDefinitions DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS InetAddressIPv4 FROM INET-ADDRESS-MIB Name FROM PKIX1Explicit88;

DnsServerList ::= SEQUENCE OF InetAddressIPv4 DnsSuffixList ::= SEQUENCE OF VisibleString MobileIPv4Settings ::= SEQUENCE { profile subject homeIpAddress homeNetmask homeAgentIpAddress dnsServers dnsSuffixList

BMPString, Name, InetAddressIPv4, InetAddressIPv4, InetAddressIPv4, DnsServerList OPTIONAL, DnsSuffixList OPTIONAL

} END

62

Appendix B PROD Pr/T definition for the authentication protocol #place mn_no_dsa mk () #place mn_dsa #place #place #place #place

ha_no_dsa mk () ha_process_reg ha_process_normal_reg ha_dsa

#trans send_pki_req in { mn_no_dsa: ; } out { ha_process_reg: ; #endtr

}

#trans generate_dsa in { ha_process_reg: ; ha_no_dsa: ; } out { ha_dsa: ; mn_dsa: ; } #endtr #trans error_pki_req in { ha_process_reg: ; } out { mn_no_dsa: ; } #endtr #trans ha_dsa_expires in { ha_dsa: ; } out { ha_no_dsa: ; } #endtr 63

APPENDIX B. PROD PR/T DEFINITION FOR THE AUTHENTICATION PROTOCOL64

#trans mn_dsa_expires in { mn_dsa: ; } out { mn_no_dsa: ; } #endtr #trans send_normal_reg in { mn_dsa: ; } out { ha_process_normal_reg: ; } #endtr

#trans accept_normal_reg in { ha_process_normal_reg: ; ha_dsa: ; } out { mn_dsa: ; ha_dsa: ; } #endtr #trans receive_error_normal_reply in { ha_process_normal_reg: ; } out { mn_dsa: ; } #endtr /* Check for deadlocks */ #ifdef WITH_DEADLOCK_TESTER #place tester lo() hi() mk() #tester tester deadlock() #endif /* Check for livelocks */ #ifdef WITH_LIVELOCK_TESTER #place tester lo() hi() mk() #tester tester livelock() #endif

Appendix C PROD results WITH_DEADLOCK_TESTER defined:

ajjarvin@vipunen:~/projects/dt$ prod auth_protocol.init ajjarvin@vipunen:~/projects/dt$ ./auth_protocol -. ajjarvin@vipunen:~/projects/dt$ strong auth_protocol ajjarvin@vipunen:~/projects/dt$ probe auth_protocol 0#statistics Number of nodes: 8 Number of arrows: 16 Number of terminal nodes: 0 Number of nodes that have been completely processed: 8 Number of strongly connected components: 1 Number of nontrivial terminal strongly connected components: 0 0#sets One strongly connected component: %%0 Special sets: %0: 0#showends %0 0 path end nodes -----------------------------------------------0# --WITH_LIVELOCK_TESTER defined: ajjarvin@vipunen:~/projects/dt$ prod auth_protocol.init ajjarvin@vipunen:~/projects/dt$ ./auth_protocol -.

65

APPENDIX C. PROD RESULTS

66

ajjarvin@vipunen:~/projects/dt$ strong auth_protocol ajjarvin@vipunen:~/projects/dt$ probe auth_protocol 0#statistics Number of nodes: 8 Number of arrows: 16 Number of terminal nodes: 0 Number of nodes that have been completely processed: 8 Number of strongly connected components: 1 Number of nontrivial terminal strongly connected components: 0 0#sets One strongly connected component: %%0 Special sets: %0: 0#showends %0 0 path end nodes -----------------------------------------------0#