Secure Identity Management and Mobile Payments Using Hand-Held Devices

KUOPION YLIOPISTON JULKAISUJA H. INFORMAATIOTEKNOLOGIA JA KAUPPATIETEET 14 KUOPIO UNIVERSITY PUBLICATIONS H. BUSINESS AND INFORMATION TECHNOLOGY 14

KONSTANTIN HYPPÖNEN Open Mobile Identity Secure Identity Management and Mobile Payments Using Hand-Held Devices

Doctoral dissertation To be presented by permission of the Faculty of Business and Information Technology of the University of Kuopio for public examination in Auditorium ML1, Medistudia building, University of Kuopio, on Friday 13th March 2009, at 12 noon

Department of Computer Science University of Kuopio

JOKA KUOPIO 2009 Distributor: Kuopio University Library P.O. Box 1627 FI-70211 KUOPIO FINLAND Tel. +358 40 355 3430 Fax +358 17 163 410 www.uku.fi/kirjasto/julkaisutoiminta/julkmyyn.shtml

Series Editors: Professor Markku Nihtilä, D.Sc. Department of Mathematics and Statistics

Professor Hannu Tanninen, D.Sc. (Econ) Department of Business and Management

Author’s address: Department of Computer Science University of Kuopio P.O. Box. 1627 FI-70211 KUOPIO FINLAND Tel. +358 40 355 2208 E-mail: [email protected]

Supervisors: Docent Elena Trichina, Ph.D. Department of Computer Science University of Kuopio

Professor Martti Penttonen, Ph.D. Department of Computer Science University of Kuopio

Reviewers: Professor Günter Müller, Ph.D. Department of Telematics University of Freiburg, Germany

Professor Tuomas Aura, Ph.D. Department of Computer Science and Engineering Helsinki University of Technology, Finland

Opponent: Professor David Naccache, Ph.D. Département d’Informatique École Normale Supérieure Paris, France

ISBN 978-951-781-993-0 ISBN 978-951-27-0112-4 (PDF) ISSN 1459-7586 Kopijyvä Kuopio 2009 Finland Hyppönen, Konstantin. Open Mobile Identity: Secure identity management and mobile payments using hand-held devices. Kuopio University Publications H. Business and Infor- mation Technology 14. 2009. 79 p. ISBN 978-951-781-993-0 ISBN 978-951-27-0112-4 (PDF) ISSN 1459-7586

Abstract

Identity proofs play an important role in our lives. They are performed both in face- to-face situations and remotely via computer networks. With the recent switch to new electronic identity documents such as biometric passports and chip-based identity cards, an increasing proportion of identity proofs takes place in the electronic realm. However, the security of new electronic documents is primarily focused on counterfeit protection, whereas privacy issues have been addressed only marginally. At the same time, when documents are read by electronic means, a lot of information is not only revealed but also can be copied, stored and processed without our consent. In this thesis, we present a technology for performing identity proofs using one’s own hand-held device. The technology is based on the design for privacy principle, enabling the user to provide ﬂexible identity proofs that reveal only the minimally required set of personal information. This controlled identity revelation technique turns the hand- held device into the user’s personal identity assistant that can replace electronic identity documents in many circumstances. In addition, we show how privacy-aware biometric authentication can be performed as part of an identity proof. The system relies on the currently available handset technology. The user’s identity information is securely stored on the standard subscriber identity module (SIM) of a GSM mobile phone. The information is accessed through a program called identity proxy and communicated to identity veriﬁers only if the user’s consent for this is acquired. We show how to perform strong two-factor mobile user authentication remotely using credentials stored on the SIM, without using the mobile network operator’s authentication services. Furthermore, we demonstrate how such authentication can be used in a secure mobile payment system based on a government-supported public key infrastructure (PKI). Other scenarios include using the hand-held device as a secure authentication token for producing one-time passwords, challenge responses, or digital signatures. In conclusion, the studies presented in this thesis demonstrate how one’s own hand- held device can be used as a reliable and trustworthy electronic identity document and payment tool.

Universal Decimal Classiﬁcation: 004.056, 004.056.523, 621.395.721.5, 654.034, 658.88 AMS (MOS) Classiﬁcation: 94A60, 94A62 INSPEC Thesaurus: security; security of data; mobile communication; telecommuni- cation security; mobile handsets; mobile computing; electronic commerce; electronic money; public key cryptography; message authentication; data privacy; biometrics (access control)

Acknowledgments

In the course of doing this research work I received help and support from many people and institutions. I am grateful to the East Finland Graduate School in Computer Science and Engineering, whose research grant made it possible for me to concentrate on research. I thank the Department of Computer Science for the financial support of my research and for travel grants. I am profoundly indebted to my principal supervisor, Dr. Elena Trichina, who gave her time and knowledge generously, encouraging my work and assisting me in each step to complete this thesis. I thank my second supervisor, Prof. Martti Penttonen, for his support, help and guidance not only during my postgraduate studies but all the time since 2001, when I came to Kuopio. Prof. Günter Müller and Prof. Tuomas Aura, the officially appointed pre- examiners of this dissertation, are gratefully acknowledged for their constructive criticism of this work and for their detailed comments which helped to improve this dissertation. I thank Marko Hassinen, my main colleague and co-author, for his participation in this research, and his enthusiasm and guidance. His experience, openness to any ideas, and sense of humour all have been of great help. I thank Keijo Haataja for his assistance and for doing other security-related research together with me. I express my gratitude to the staff of the Department of Computer Science for friendly work atmosphere and for relaxing coffee breaks and lunches. Many have supported this work directly, most importantly Tapio Grönfors, Virpi Hotti, Seppo Lammi and Pekka Toivanen. Pekka Kilpeläinen, Paavo Pakoma, Jyrki Wessman, Merja Leppänen and Leila Tiihonen have been of great help in administrative issues, and not only in them. I thank Vivian Michael Paganuzzi for the careful revision of the language of this thesis. I am the only person responsible for any remaining errors in the text. My special gratitude goes to my international friends: Darius, Rimant˙e, Martin, Boryana, Gogo, Laura, Roman, Olli, Ursi, Ferdinand, Viktoria, Sveta, Rustam, Irina, Jakub for exciting parties, tasty dinners, mökki weekends, sport activities, and many discussions which were often related to postgraduate studies. I also thank my Russian friends: Yury Vinokur and the whole families of Kornilov, Grigoriev, Grebeshov, Fridriksson, and Talbonen for keeping in touch and for providing all the support that I could ask for. Thanks go to my whole family, who have been an important and indispensable source of spiritual support. Ñïàñèáî! And finally, but not least, I thank my wife Jelena for everything that I told you many times already, and for much more that I cannot put in words.

List of original publications

This dissertation is based on the following publications, which are referred to in the text by their Roman numerals (I–V):

I Marko Hassinen, Konstantin Hyppönen. Strong Mobile Authentication. Pro- ceedings of the 2nd International Symposium on Wireless Communication Systems, pp. 96–100. IEEE, 2005. II Marko Hassinen, Konstantin Hyppönen, Elena Trichina. Utilizing national public-key infrastructure in mobile payment systems. Electronic Commerce Research and Applications 7 (2), pp. 214–231, Elsevier, 2008. III Konstantin Hyppönen, Marko Hassinen, Elena Trichina. Pseudonymous Mo- bile Identity Architecture Based on Government-Supported PKI. Proceedings of the TRUST2008 Conference on Trusted Computing, Villach, Austria, March 11–12, 2008. Vol. 4968 of Lecture Notes in Computer Science, pp. 107–118, Springer, 2008. IV Konstantin Hyppönen, Marko Hassinen, Elena Trichina. Combining Biomet- ric Authentication with Privacy-Enhancing Technologies. Proceedings of the TRUST2008 Conference on Trusted Computing, Villach, Austria, March 11–12, 2008. Vol. 4968 of Lecture Notes in Computer Science, pp. 155–165, Springer, 2008. V Konstantin Hyppönen. An Open Mobile Identity Tool: An Architecture for Mobile Identity Management. Proceedings of the Fifth European PKI Work- shop (EuroPKI 2008), Trondheim, Norway, June 16–17, 2008. Vol. 5057 of Lecture Notes in Computer Science, pp. 207–222, Springer, 2008.

Author’s contribution

This dissertation is the result of research carried out within an informal security group at the Department of Computer Science, University of Kuopio, during 2005–2008. The research work of the group was focused on the security and reliability of embedded systems, wireless network security, and cryptoalgorithms and protocols.

Publication I introduces the idea of using a national public key infrastructure for strong authentication of mobile users. Furthermore, it envisages the use of such authentication for message exchange and mobile payments. Smart card implementation and simulation software were developed by the author. The original payment protocol introduced in the paper was designed by Marko Hassinen. He also implemented software for the mobile phone and back-end systems. Publication II describes the architecture and infrastructure of the mobile payment system and the protocols it is based on. The paper provides a wider view of mobile payments in general, and their security in particular. The protocols were jointly reﬁned with Marko Hassinen. The article went through several revisions, during which all the authors co-authored most of the text. Publication III describes the design and implementation of an identity tool on the mobile phone. The concept, architecture and its implementation were designed by the author. Parts of software were implemented by Marko Hassinen, who also wrote parts of the article. Elena Trichina participated in the project by providing general guidance. Publication IV presents a way of combining privacy-enhancing technologies with biometric authentication of the users. The main idea and its proof-of- concept implementation were developed by the author. Parts of software implemented earlier by Marko Hassinen were reused; Marko also co- authored some parts of the text. Elena Trichina participated in the project by providing general guidance. Publication V extends the mobile identity architecture presented in III, providing support for multiple partial identities. The tool is open in the sense that partial identities can be loaded by arbitrary identity providers.

Abbreviations

AC attribute certiﬁcate LDAP Lightweight Directory Access APDU application protocol data unit Protocol API application programming ME mobile equipment interface MITM man-in-the-middle

ATM automatic teller machine MNO mobile network operator BAC Basic Access Control MRTD machine-readable travel CA certiﬁcate authority document

CSR certiﬁcate signing request NFC Near Field Communication

DNA deoxyribonucleic acid ObC OnBoard Credentials EAC Extended Access Control OCSP Online Certiﬁcate Status eID electronic identity Protocol

ETSI European PDA personal digital assistant Telecommunications PET privacy-enhancing Standards Institute technologies FINEID Finnish electronic identity PIN personal identiﬁcation FINUID Finnish electronic user number identity PKI public key infrastructure GAA Generic Authentication Architecture PKI-SIM SIM card which contains a private key belonging to a PKI GPRS General Packet Radio Service POS point of sale GSM Global System for Mobile Communications PRC Finnish Population Register Centre ICAO International Civil Aviation Organization RFID radio frequency identiﬁcation

ID identity SAT SIM Application Toolkit

IDE integrated development SATSA security and trust services environment SIM subscriber identity module IrDA Infrared Data Association SMS Short Message Service J2ME Java 2 Mobile Edition SSO single sign-on J2SE Java 2 Standard Edition URI universal resource identiﬁer JCE Java Cryptography Extension WLAN wireless local area network JCRMI Java Card Remote Method Invocation WTK Wireless Toolkit

Contents

1 Introduction 15

2 Literature review 17 2.1 Mobile identity...... 17 2.1.1 Terminology...... 17 2.1.2 Security and privacy requirements...... 20 2.1.3 Electronic identity types...... 21 2.1.4 Identity management...... 28 2.2 Mobile payments...... 31 2.2.1 Security and privacy requirements...... 32 2.2.2 Mobile payment schemes...... 33 2.2.3 Security of payments...... 33

3 Aims of the study 37 3.1 Motivation...... 37 3.2 Research hypotheses...... 38 3.3 Research methods...... 39

4 Results 41 4.1 Mobile user authentication...... 41 4.1.1 Data ﬂow...... 41 4.1.2 Applications...... 43 4.1.3 Evaluation...... 43 4.2 Mobile payment systems...... 44 4.2.1 Protocols and implementation...... 44 4.2.2 Security, privacy and usability...... 49 4.3 Open Mobile Identity...... 51 4.3.1 Mobile terminal as a personalised electronic identity tool. 52 4.3.2 Architecture and infrastructure...... 52 4.3.3 Flexible identity proofs based on a single identity proﬁle. 53 4.3.4 An open mobile identity tool...... 55 4.3.5 Security evaluation...... 58 4.4 Combining biometric authentication and privacy-enhancing technologies...... 60 4.4.1 Biometric authentication and unlinkability...... 60 4.4.2 Trusted user interface...... 61

5 Conclusions 65 5.1 Contributions of the thesis...... 65 5.2 Limitations of the study...... 67 5.3 Future work...... 67

Bibliography 69

1 Introduction

The number of mobile subscriptions enjoys steady growth worldwide [49]. The main mobile applications are voice and text messaging, but other services are also being constantly deployed. Due to the variety of services available in mobile networks, users have started to perceive the nature of their mobile devices as increasingly personalised [104]. Conversely, the personal nature of the hand- held device has been used for customer identification and authentication in new services. Customer authentication is an important requirement in many mobile services, as it is used for enabling transactions, and in particular providing their authorisation and non-repudiation. In some applications, such as downloading ringtones or music, or getting weather forecasts, authentication does not need to be strong, and it can be based on the mobile network subscriber identity. In other applications, such as payments, banking, or governmental services, authentication by the mobile network operator is not considered adequate [54, 110]. It is difficult to strongly authenticate mobile users remotely and provide an adequate level of non-repudiation of transactions. Current solutions addressing this need are based on infrastructures maintained by mobile network operators (MNOs) or banks. A public-key infrastructure can be used for authentication: the customer’s subscriber identity module (SIM) card contains a private key, and the related public key is stored in a database maintained by the MNO. A challenge- response protocol is then used to authenticate the customer. By entering her personal identification number (PIN) code, the customer permits the SIM card to sign a challenge sent by the MNO. Such authentication is considered to be secure enough for most business applications. However, if customer authentication services lie in the full control of MNOs or financial institutions, it may be hard or expensive for third parties to use the services. As the authentication service providers are mostly interested in increasing their revenue, they charge both the customers and the third parties

15 Chapter 1. Introduction for using the system. Consequently, non-profit organisations, for instance, may face problems in developing mobile services for their members. Furthermore, it is questionable whether such authentication may be accepted for e-government applications, such as civil or municipal services. The national electronic identity systems of a few countries are now available for use in connection with services provided by mobile phones. Secure storage of the user’s credentials on the SIM combined with the flexibility of the user interface and the variety of communication technologies turn the hand-held device into a powerful mobile identity tool. At the same time, both technologically and psychologically it is different from current identification cards and passports. The possibilities for the use of such mobile identity tool have not yet been studied well. In addition to the use in on-line services, hand-held devices can facilitate proximity transactions [88], and such use has been predicted to grow with the introduction of Near Field Communication (NFC) in mobile phones [87, 90]. Credentials such as pseudonyms, passwords, and keys for different services can be stored on the hand-held device. This opens new ways for using the hand-held device for user identification or authentication in proximity scenarios, and at the same time brings up the topic of mobile identity management. Can the mobile phone become a ubiquitous personal assistant that facilitates identity proofs and secure mobile payments, at the same time preserving its user’s privacy? What are the requirements for device hardware, software technology, security enablers, and protocols that should be used for such scenarios? What infrastructure is needed? In this study issues of mobile user identification and authentication are examined, and architectures for mobile identity management and secure mobile payments are presented. In addition, the study provides insights into currently deployed person identification practises with electronic identification documents, and examines ways for performing privacy-aware biometric authentication of persons. Proof-of-concept implementations of the proposed solutions are also described, showing their reliance on currently available handset technology.

16 2 Literature review

With more than 111% mobile subscribers penetration [26], the mobile phone is one of the most common personal devices in the European Union. Given the popularity of mobile communication, the search for new “killer applications” has been active among researchers. In order to set up the context for the contribution of the thesis, in this chapter two aspects of such research are reviewed, namely mobile identity management and mobile payments.

2.1 Mobile identity

Due to the personal nature of a hand-held device, it is seen as a suitable medium for storing personal information and credentials for access to various services. Indeed, almost all mobile phone users store their personal phone books in the memory of their devices. In addition, the devices are often used for storing personal notes, calendar items, photos, and even credit card information. As a result, the mobile device becomes the owner’s identity-on-the-move, which we refer to as a mobile identity.

2.1.1 Terminology The mobile identity is composed of various components which we define in this section. However, before moving on to identity-related notions, we first define the basic security concepts that will be used throughout the text. Authentication is the process by which a party (e.g., a computer or a person) proves that it is who it claims to be. In what follows, we concentrate on the authentication of persons only. There are three basic ways to authenticate some- one: by something the person knows (for example, a password, secret key or a PIN code), by something the person has (for example, a physical key, passport,

17 Chapter 2. Literature review

or a SIM card), and by something the person is (biometrics such as a fingerprint, signature or a deoxyribonucleic acid (DNA) test). Identification and authorisation are concepts that are close to authentication, yet differ from it substantially. Identification is essentially a process through which one answers the question “Who are you?”, telling their name or other attributes. Identification is often followed by authentication, whereby the person provides a proof of their identity statement. Authorisation is a process by which a person’s rights to access or use some resource or service are determined. There are many definitions for the concept of privacy, which differ in philo- sophical, political, and technological discussions. In 1890 Brandeis defined privacy as “the right to be left alone” [113], and in 1967 Westin projected this definition on the concept of information privacy as “the claim of individuals, groups or institutions to determine for themselves when, how, and to what extent information about them is communicated to others” [114]. In the text, we use this definition, concentrating mostly on the privacy of individual information. Security is a concept that is normally defined in terms of requirements specific to a given system. Security requirements for mobile identity management are presented in section 2.1.2. For defining identity-related concepts, we use the Pfitzmann-Hansen terminology [95], extended with a few other terms regarding a person’s identity. Here we recall the most important notions. Normally (especially in officially recognised practises), persons are authenticated using their biometric patterns. Examples of biometrics are photos, fingerprints, iris scan, or DNA. The least intrusive biometrics in modern society are voice and photos. A digital representation of a biometric pattern is called a biometric identifier. For example, a cryptographic hash of a biometric pattern can serve as such an identifier. For security reasons, it is important that the biometric patterns (and consequently identifiers) of different persons are always different. In addition, the process of turning biometric patterns into biometric identifiers must preserve this feature of uniqueness. In the case of cryptographic hashes, the pre-image resistance (both first and second) of the hash function is important. In addition to the real name1, one can use different pseudonyms in different circumstances. A pseudonym is an identifier of a person other than one of the person’s real names. Biometric identifiers can work as pseudonyms in some cases. Other examples include one’s customer numbers with different service providers. An attribute is a quality or characteristic of a person. Attributes are the building blocks of a person’s identity. Examples of attributes are surname, blood group, or employer’s name. Biometric patterns can also be regarded as attributes. Attributes have names (or codes) and values. An identity is a subset of a person’s attributes that sufficiently identifies this person within any set of people. Often it characterises only a particular aspect of the person, i.e., a role, position or status of the person in a given social, business or official context. In this case only authentication of the person’s role, position or status is needed, and authentication of the person is not required. Identities can be either complete or partial. A complete identity is the union of

1Real names, or their representation, can be difficult to define. The author has been using four different ways of writing his surname, three of which (but not the one written on the cover page of this book) were officially recognised in different countries.

18 2.1. Mobile identity all the person’s attributes, whereas a partial identity is a subset of the attributes of the complete identity. Individuals use different partial identities in different situations. Henceforth, “identity” refers to a partial identity unless otherwise indicated. An identity issuer or identity vendor is an organisation or company determining and attesting the attributes of an identity. Identity issuers can only issue partial identities (we assume that there are no complete identity issuers). Identity vendors can issue certificates attesting the connection between given attributes, biometric patterns and documents. The certificates can be either digital or issued on paper or plastic. Using these certificates, persons can prove the integrity and authenticity of information about them. We denote an identity profile as a partial identity along with certificates of its integrity and authenticity, and other partial identity related information, such as keys or attribute certificates. A party to which a person reveals values of certain attributes from a partial identity or a number of partial identities, and proves their authenticity and integrity, is called an identity verifier. In identification or authorisation scenarios, the person presents an identity profile to the verifier. Ideally, only the minimal set of attributes and pseudonyms required by an identity verifier to identify a person or to correctly establish the person’s role, position or status should be used. We refer to such minimal sets as to minimal identities, and denote the requirement for using only minimal identities as data minimisation. In addition, finding connections (links) between different transactions should be made difficult for identity verifiers and third parties, even if they collude and share all information about their transactions. This requirement prevents the tracking of one’s actions, and is called unlinkability. Personal information is defined as any part of an identity profile that does not feature unlinkability. Examples of personal information are values of attributes, certificates, pseudonyms or biometric identifiers. Identity management is a set of procedures used for managing a person’s various partial identities. It includes the administration of identity attributes including the development and selection of partial identities and the pseudonyms to be used in specific contexts or roles. Naturally, there are three parties in identity management: a person, an identity issuer, and an identity verifier. A storage device for one or more partial identities used by a person to reveal and prove her identity is called an identity token. Examples of identity tokens are ordinary identity and loyalty cards, electronic keys, or tickets. Further, we denote an interactive device for storing and managing one or more partial identities used by a person to reveal and prove her identity as an identity tool. The identity tool manages identities in a digital form. Interactivity means that the selection of a partial identity in a particular situation is possible through a user interface with input and output capabilities. A privacy-enhancing identity tool is an identity tool that can be used in identity management with data minimisation. A privacy- enhancing identity tool (a) informs the person about the set of information requested by the identity verifier, and (b) allows the person to comply with the request or reject (or modify) it.

19 Chapter 2. Literature review

2.1.2 Security and privacy requirements In the previous section, we mentioned two privacy requirements that should be implemented by identity management schemes, namely data minimisation and the unlinkability of transactions performed by users. Here we extend them with additional requirements concerning security and usability. The parties participating in an identiﬁcation or transaction authorisation scenario are an identity prover (Peggy) and an identity veriﬁer (Victor). Victor needs certain proof of Peggy’s identity or her rights. There is also a Trusted Third Party (TTP, Trent), which is an authority that has issued Peggy her partial identity. The following properties should hold true:

Data minimisation Victor requests and receives only the necessary information about Peggy’s identity or her rights.

User consent Peggy is informed about the set of information requested by Victor. She can either accept of reject the request. Victor receives no information about Peggy if she chooses to reject the request.

Unlinkability If Peggy performs two or more different authorisation transactions with Victor, he should not be able to sufﬁciently distinguish whether they are related to the same person or not. The property should hold true also in the case of two (or more) different identity veriﬁers.

Authenticity and integrity Peggy cannot forge or modify the information about herself stored by Trent in her identity tool. Victor can verify that the information presented by Peggy is authentic. Nobody can impersonate Peggy, even if they have physical access to Peggy’s identity tool.

Conﬁdentiality (a) Nobody can read any information from Peggy’s identity tool, unless she speciﬁcally allows this. The property holds true also in the case when the device is lost or stolen. (b) Nobody can learn any information about Peggy’s identity by eavesdropping on the communication between Peggy and Victor.

Easiness of revocation If Peggy’s identity tool is stolen or lost, Peggy can easily place it on a black list of revoked identities, for example by contacting Trent.

One can see that most of the security requirements for mobile identity are the same as for ordinary identification documents. However, the privacy requirements are set higher. With ordinary identification documents, the person can choose to whom she shows them; however, it is difficult to restrict data collection from them, as the identity verifier can read all attribute values. Revoking ordinary identification documents is also cumbersome: in most cases, a criminal can use a stolen passport or driving license until its expiry date. The reason for the introduction of more stringent privacy requirements is the increase in the number of identity theft incidents [46]. Identity theft is a crime in which an impostor obtains key pieces of personal information such as social security numbers and driver’s license numbers and uses them for their

20 2.1. Mobile identity

own personal gain2. With the introduction of electronic identity documents which are read by electronic means it has become easier to copy, store and process personal information. Although protection against excessive collection of personal information is provided by privacy-related laws in many countries, such laws normally place limits only on the procedures for collecting and storing this information, and do not restrict normal identity checks. At the same time, with eIDs, the difference between an identity check and the collection of personal information has become vague. This underlines the importance of informed user consent for providing personal information in normal identity veriﬁcation scenarios. An important requirement in any identity management scheme is its usability. Good usability has a clear impact on the security of the system and on its acceptance by the users. At its best, an identity management scheme should be based on devices and interfaces whose operation is already known to most users. The speed of operation also plays a crucial role in improving usability.

2.1.3 Electronic identity types A person’s identity is composed of a number of identity profiles, which are used in different social and business scenarios [25]. Even within the same organisation a person can have several different identity profiles, or roles. For example, in a hospital a doctor can use the role “employee” for opening the front door, and the role “neurophysiologist in charge” for signing an electroencephalography analysis. In computer networks, roles have been successfully used for many years for access control (role-based access control). In everyday life, the diversity of identity profiles can be seen in the numerous cards and certificates that the average person has. Examples of such tokens are given in Table1 . The governments of many countries all over the world have introduced various types of chip-based identification documents for their citizens (see examples in Fig.1 ). The main objectives for the switch to eIDs are better resistance to forgery, and their use in new electronic governmental services [21]. Another big group of eIDs consists of the various types of identity cards and tokens used in the corporate world, both for employees and the customers of companies. These IDs are not generally recognised officially, with some notable exceptions, such as the possibility of using bank-issued credentials for accessing some national services in Finland and Sweden. Next, we provide a short overview of currently used official eIDs.

Biometric passports

New biometric passports based on radio frequency identiﬁcation (RFID) (also called e-passports or Machine Readable Travel Documents, MRTDs) are now issued by many countries. All the data on the information page of the passport is also stored in a chip embedded into the page. In addition to the main biometric, namely the electronic face photograph of the passport’s owner, other biometric information is also projected to be stored in the chip in future generations

2http://www.idtheftcenter.org

21 Chapter 2. Literature review

Table 1: Possible identity proﬁles of a person

Document/card type Examples Issuer Citizen ID Passport, identity card Government License Driving license, pilot Government or a certifying license, firearm license authority Insurance card or Social insurance card, Government or an insurance certificate travel insurance company certificate Visa or residence permit Consulate, police, or other authority of a foreign country Loyalty card Customer ID card, library Store(chain), library, airline card, customer group card, mileage card Blood donor card Red Cross or another organisation Organisation member Student card, employee Organisation or company card card Payment card Bank card, credit card, Financial institution preloaded value card Ticket Ski lift ticket, public Transport or other company transport ticket Electronic key Employer or security company Business card Employer or person him/herself

of the passport. Fingerprints or iris codes are the most likely choices. Besides better resistance to forgery, another security goal for the new passports was the prevention of “look-alike” frauds, i.e. the cases when a passport is used by a person who resembles the rightful owner of the passport [56]. Such fraud can be prevented only if verification against the biometric pattern is done automatically; so far, it is mostly performed by humans. The biometric passport security features are based on the international standards issued by the International Civil Aviation Organization (ICAO)[59]. The standards cover the integrity, confidentiality and authenticity of the passport data and the contents of messages sent between the passport and a passport reader. In the current generation of the passports this is achieved by a mechanism called Basic Access Control (BAC). In order to communicate with the passport chip, the reader must first optically read the machine readable zone printed at the bottom of the main data page. From this data, the reader constructs the access key, which is then used for encrypting the commands sent to the chip and decrypting the answers received from it. This mechanism prevents the remote skimming of passport data without its owner’s consent: in order to access the chip, the reader must possess the physical document. However, it has been shown in several studies [56, 66, 115] that part of the contents of the machine readable zone can be easily guessed, making it possible to guess the access key in a relatively short amount of time. ISO 14443 tokens, used as chips

22 2.1. Mobile identity

Figure 1: Officially recognised electronic IDs in Finland: biometric passport, identity card, PKI-SIM card. in biometric passports, can be activated from a distance of up to 29 cm, and read from a distance of 15 cm [51]. Although the numbers do not look that impressive, remote skimming of passports in a crowded area is feasible. Extended Access Control (EAC)[45], a standard developed by the European Union, can solve the problem of remote skimming, as it requires that the reader must first authenticate itself to the chip. A challenge-response mechanism is used for reader authentication: the reader proves that it possesses the private key for a certificate trusted by the chip. It must be noted, however, that key management is not easy in this scheme. For example, as the chip does not have a reliable source of time, it cannot reliably check whether the certificate presented by the reader is valid. This makes it possible for malicious terminals to use old expired certificates for compromised keys in some cases. In addition, the use of EAC is only mandatory to access the most sensitive information, such as fingerprints or iris codes. For access to face photographs, on the other hand, its use is only recommended. Nonetheless, EAC is still a good improvement over BAC. The main problem, however, is that currently most passports use BAC, not EAC. Even if EAC is used, an adversary can mount a relay attack to impersonate the rightful passport owner [50, 55]. In a relay attack the adversary works as a man- in-the-middle (MITM) between a valid passport and a valid reader. The attacker presents a maliciously crafted device to the reader. The device is connected over a high-speed wireless communication technology to another reader that accesses the victim’s passport. The attack is difficult to prevent because all replayed messages follow the standard protocol and their contents are not changed. A possible countermeasure is a distance-bounding protocol [52], which is based on the fact that relaying introduces detectable delays in the communication. Distance bounding, however, is not used in currently deployed passports. Other countermeasures aimed at improving the security and privacy of biometric passports include using zero-knowledge proofs for authenticating the chip of the passport [81] and using optical memory instead of (or in addition to) the machine-readable zone as a source of the key data [72]. Neither of these countermeasures have been implemented so far. A good overall conclusion, supported by many studies, is given in the Budapest Declaration on Machine Readable Travel Documents [44], where the FIDIS project states that new biometric passports “dramatically decrease security and privacy and increase the risk of identity theft.”

23 Chapter 2. Literature review

Electronic identity cards

Most European countries have introduced electronic identity cards, driven by the demands set by common European legislation, namely the Digital Signature Directive [105]. Electronic identity cards are already in use also in some Asian countries3. In the USA, a federal chip-based ID card (Real ID) is currently under development. However, many privacy-protecting organizations4 are objecting to it. As an example of an identity card, we briefly describe here the Finnish electronic identity (FINEID) card. The card (see Fig.1 ) along with the supporting infrastructure [97] is a system maintained by the Finnish Population Register Centre (PRC). The card is a usual microprocessor smart card which is accepted as a travel document in all European Union countries and several others. It contains two Citizen Certificates (public key certificates): the authentication certificate of the card holder and the signature certificate of the card holder. The private keys of both certificates are generated by the card and stored exclusively in its protected memory. Additionally, the card contains the PRC’s own certificate authority (CA) certificate. The card can perform operations involving a private key (e.g., calculate a digital signature) after the user has entered the PIN code corresponding to the key. No biometric information is stored in the chip. The PRC maintains an online certificate directory (FINEID directory). Each registered individual gets a unique Finnish electronic user identity (FINUID) number. The public keys of each user can be downloaded via a search with the appropriate criteria. In addition, a revocation list of invalid certificates is available from the FINEID directory. The validity of a certificate can be checked against the revocation list, or using the Online Certificate Status Protocol (OCSP) [83]. The facilities of the FINEID card are mainly used for user authentication in online services. For example, one can request a tax card or check one’s pension accrual on the Internet, by inserting the card into a card reader and entering the PIN code. It is also possible to use the card for customer authentication in commercial applications: for example, some post, bank, and loyalty applications can be accessed with the card. Privacy considerations have been taken into account in the design of the card. For instance, FINUID is not the same as the social security number, nor can it be used for deriving the social security number, unless the service provider has access to the PRC data. On the other hand, the social security number is printed on the front of the card, and is therefore available to anyone who gets physical access to the card. Since June 2005, FINEID cards are based on the Java Card technology [24]. The technology enables running several programs (Java Card applets) on the card and downloading new applets on the chip in the post-issuance phase of the card’s lifetime. Post-issuance downloading of applets has, however, security implications associated with the bytecode verification of downloaded programs [73]. Bytecode verification, which is a static analysis of the applet, is a crucial component of the Java security model. If a malicious applet (which contains

3http://www.asiaiccardforum.org 4See, e.g., http://www.realnightmare.org

24 2.1. Mobile identity ill-typed operations, for example) can bypass bytecode veriﬁcation, it can potentially enable a security attack. Because smart cards are resource-constrained devices, and the standard bytecode veriﬁcation algorithm requires a considerable (and a priori unlimited) amount of random-access memory, many cards do not implement it. Partly due to this fact, users are not allowed to install new applets on their FINEID cards. Electronic use of the card is therefore currently restricted by the features of the FINEID applet only. The card itself is hardly the weakest link in the security of the scheme whereby an eID is used for online user authentication. Indeed, a much easier attack vector for an adversary is to concentrate efforts on the computer at which the card is used. Normally, in order to access an online service, the user inserts her FINEID card into the card reader, opens the relevant web page, and enters her PIN in a dialogue window displayed by the card reader software. It is important to note here that the card does not authenticate the card reader software, but only checks the correctness of the PIN supplied to it. Therefore, malicious software that wangles the user’s PIN code once (e.g., by intercepting keyboard events) can use it later to impersonate the user to any online services as long as the card is in the reader. Having intercepted the signature PIN, malware can sign any documents on the user’s behalf. It should be noted that such signatures have the same validity as hand-written signatures. Arguably, the main reason why such attacks have not been mounted (or reported) so far is the relatively low penetration of eID cards, both in the number of users and in the number of available services.

SIM cards

The SIM is a smart card intended initially for mobile user (or rather user’s device) authentication by the MNO. This card, owned by the MNO, is one of the best known and widespread applications for smart cards. At the same time, it works as a good illustration of “mobile identity”. A mobile user’s subscriber ID can in some cases be used as the customer ID in other business scenarios. Relying on the authentication of the SIM card in the phone, MNOs can establish trust between the user and a third-party company. The most usual application here is roaming, where the third-party company is a mobile operator in a foreign country; other applications include access to wireless local area network (WLAN) networks [111], mobile payment systems, or services relying on positioning through mobile phone [31]. Some banks even use the mobile phone as an additional channel for requesting conﬁrmation codes for payments initiated through usual Internet banking [108]. This works as a trusted path between the bank and the user, preventing phishing or MITM attacks. In Global System for Mobile Communications (GSM) networks, user authentication is based on a secret key, commonly denoted as Ki, shared between the SIM card and the MNO. The 3GPP project has developed a framework called Generic Authentication Architecture (GAA)[39], which enables the bootstrapping of credentials from this cellular authentication key and their reuse for authorising access to other services. The system is easy to deploy, is based on open standards, and can be used in both online and proximity scenarios [70]. Nonetheless, the architecture is not open in the sense that service providers must sign agreements

25 Chapter 2. Literature review with the MNO in order to deploy GAA. In addition, the use of authentication based on the SIM card and associated PIN code is rather limited because it is not fully reliable. The PIN is requested only on power-on, and if the phone is stolen or lost, it is usually ready to be used by anyone. Therefore, for stronger authentication, SIM Application Toolkit (SAT)[1] applets with extra PIN codes are used. SAT applets can be employed in two-factor authentication based on something that the user has (the phone or, more exactly, the SIM card inside it), and something that the user knows (the service-speciﬁc PIN entered on the phone keyboard every time prior to use of the service). A good example of such use is the authorization of payments in mobile payment systems and mobile banking. The MNO can send data to a SAT applet in a standard Short Message Service (SMS) message. SMS messages marked as “SIM data download” in their protocol identiﬁer header are forwarded by the mobile equipment (ME) to the SIM card. Having received the message, the applet on the SIM card can process it and request additional information from the user, by driving the ME user interface. The applet can further create and send a message to the MNO. Both incoming and outgoing messages can be encrypted under a key known to the SIM and the SIM toolkit server [2]. PKI-SIM cards use SAT features for checking the user’s PIN prior to signing a challenge with the user’s private key stored on the card. This process is depicted in Fig.2 .

Service MNO's authentication User's mobile equipment provider service Phone SW SAT applet Generate SMS SMS Initiate Phone number message message challenge, Parse header, authentication Decrypt contents, create SMS forward to SIM read challenge message User interface Build user details Start PIN check interface PIN Verify PIN; Acquire PIN sign the challenge Authentication SMS SMS Create SMS Finish result Check message message Send SMS with response authentication response

Figure 2: Mobile user authentication using a SAT applet on the SIM.

The first mobile signature solutions were based partly on proprietary technologies. In 2003, European Telecommunications Standards Institute (ETSI) produced a set of Mobile commerce (M-COMM) standards [35–38], after which most solutions were updated to conform to them. The mobile signature is defined by ETSI as “A universal method for using a mobile device to confirm the intention of a citizen to proceed with a transaction”.

PKI-SIM with a national eID applet

The SIM card can work also as an ofﬁcially recognised ID. In at least Estonia, Finland, and Turkey a mobile subscription customer can request a national eID- compatible PKI-SIM card from their MNO. Such a card can be used for mobile user authentication, and for creating digital signatures legally equal to handwritten

26 2.1. Mobile identity ones. At the moment, two operators in Finland issue such PKI-SIM cards. The system works in the following way.

Card issuance A customer receives a PKI-SIM card containing two private keys (generated on the card) from her MNO. The keys are stored within a SAT applet used for customer authentication. At this point, no public-key certificates corresponding to these keys exist. The certificates are produced and officially registered in the FINEID directory in the second step, when the customer registers her SIM card at a police station. User authentication In order to authenticate a customer, the service provider sends an authentication request to the MNO’s authentication service. The operator sends a challenge to the customer’s phone in an SMS message, as described above. The SAT applet asks the user to enter her PIN code to access the private key, signs the challenge, and sends the response back to the MNO in an SMS message. The operator checks the response and informs the service provider about the result of the authentication. The advantages of the ETSI standards-based platform include its compatibility with almost any GSM mobile phone, and the availability of all the needed infrastructure. However, there are also certain drawbacks in the current approach. For example, authentication cannot be done without the participation of the MNO, and naturally operators charge both customers and service providers for authentication. Apparently, this is a major threshold for joining the system: in Finland, the system has been in place for already more than three years, yet only a few service providers and about 200 people use it. In addition, using MNO services for every transaction increases latency. Authentication and transaction handling can also be done without relying on MNO services [67, 77]. Indeed, the SIM card can be accessed straight from software residing on the mobile phone, without any external data connection. Combined with proximity technologies such as Bluetooth, NFC and IrDA, used for connecting to a service provider or a peer, such SIM card access enables architectures that do not require MNO services for every single transaction. Still, as the SIM card remains the property of the MNO, support for such architectures must be provided by the operator. Essentially this means that the MNO has to install a SAT applet on their SIM cards.

Online identities

For most online services, the prevalent authentication tool is currently the login and password pair. Although such authentication is easy to implement for service providers, and easy to understand for users, it has a number of widely acknowledged usability and security problems [6, Sect. 2.4]. People who use many online services have difﬁculties in remembering passwords for them, and therefore often pick passwords that are easy to remember [17]. For an attacker, such passwords may be easy to guess. Enforcing good passwords by measuring their quality helps only partially, because many people re-use their passwords in a number of different accounts [60]. An attacker who has access to the password data of one online service (e.g., a website administrator) can try the passwords at

27 Chapter 2. Literature review

other places. Furthermore, passwords are often stolen through social engineering attacks such as phishing. Phishing attacks have been extensively used against users of Internet banking services. This comes as no surprise, taking into account the extreme popularity of Internet banking, the lack of phishing detection mechanisms in earlier browser versions, and the fact that even experienced computer users have difficulties in telling fraudulent and genuine banking websites apart [30]. One-time passwords used by many banks in Finland and other countries can also be harvested. To overcome these problems, some banks supply their users with tamper- proof hardware authentication tokens that generate one-time passwords once in a minute or half a minute. Such passwords are essentially useless in passive phishing, because they expire quickly. Even better security can be achieved with two-factor authentication or three-factor authentication [43], by combining hardware tokens with PIN-entry pads and/or biometric authentication (see, e.g., [9]). However, such authentication can prove insufficient in the case of real-time MITM phishing. Having established a session between the user and the bank, and controlling it, the attacker can modify the contents of messages sent between the parties. This problem can be solved with the use of out-of-band channels. As was already mentioned on p. 25, prior to accepting a payment order the bank can send a confirmation code to the user in an SMS message. The message must also contain essential information about the payment, such as the beneficiary account number and the amount, because these might have been modified by the MITM.

2.1.4 Identity management It is not easy to handle large numbers of different user accounts in different services and the partial identities associated with them. It is even more difﬁcult to remember all the passwords and PINs for access to these services. Bad usability often leads to decreased security and privacy. Furthermore, users’ frustration can discourage them from continuing to use the service, which may have a clear economic impact on the service provider. The purpose of identity management solutions is to establish environments and rules for handling the partial identities of users [28]. This includes the speciﬁcation of procedures for identity life cycle management, and protocols for identity proofs and other information exchange between participating parties [64]. In a mobile business, identity management can be used for developing services that follow the user from device to device, location to location, and context to context [99].

Identity federations Recently, the usability of credentials handling in the online world has somewhat improved with the introduction of identity federations. These enable the reuse of credentials within security domains of different service providers. It is therefore enough for a user to authenticate with only one service provider to access the services of other providers belonging to the same federation. This mechanism

28 2.1. Mobile identity is called single sign-on (SSO). Speciﬁcations for the exchange of authentication and authorisation data can be based on a number of standards and architectures [75, 84, 91, 101]. All of them deﬁne distributed architectures with no central authority. There can be many identity providers in the system, handling user authentication and supplying assertions to service providers. Assertions can contain authentication statements, authorisation decision statements, or (identity) attribute statements. The identity provider can be located anywhere, as long as it can supply assertions to service providers. In particular, this means that the identity provider can also reside on a user’s personal authentication device, enabling user-centric identity management [3, 65].

Multi-application smart cards Multi-application smart cards can be thought of as an identity federation- enabling technology, with multiple identities stored on a single card. Multi- application smart card operating systems have been available since 2002 [98, Sect. 5.1]. Despite this, the number of cards in the wallet of an ordinary person has been growing. Although many cards are multifunctional (for example, Malaysian identity card includes 8 applications), downloading new applications in the post-issuance phase of the card life-cycle is generally not allowed. The reasons for this are many. The main technological issue has for a long time been the lack of on-card bytecode verification, a basic check that newly downloaded applications have to undergo to ensure the security of other applications on the same card. Currently, though, many cards feature on-board bytecode verification. Another technological problem has been the shortage of standard smart card terminals in many business places. The global introduction of chip-based payment cards has now fixed this issue. One more problem is the lack of trust between service providers, which are are often competitors of each other, and therefore do not allow the downloading of other applications on their cards. Furthermore, the card itself usually bears the issuer’s logo and hence works as a valuable marketing tool. In a study [96] performed at our department, the reasons for the slow adoption of multi-application smart cards in Finland were investigated through an online survey. Issuers of common Finnish loyalty cards were invited to fill in a form with questions about their awareness of the multi-application smart card technology, and the main reasons for not taking it into use. It turned out that the main problem was the lack of trust in cards distributed by competitors: 84.5% clearly objected to the installation of their applets on such cards. Nonetheless, many issuers would accept the downloading of their applets on cards issued by banks (73.7% of issuers) or a national identity system provider (78.9%). To summarise, user-centric identity management using multi-application smart cards is currently all but nonexistent, and there is no clear solution to the problem of trust between potential competitors.

Privacy-enhancing technologies

Privacy-enhancing technologies (PET) is an umbrella term for algorithms, protocols and systems that prevent the undesired dissemination and processing of

29 Chapter 2. Literature review personal information, thereby increasing privacy. The development of PET for information systems was started by Chaum, who published his seminal paper [23] on the topic in 1985. The cryptographic techniques used in PET include blind signatures (presented first in [22]) and zero-knowledge protocols (invented in [47]). For the latter, commitment schemes, introduced first in [15], are normally used. Users can utilise different pseudonyms for interacting with different organisations. This provides unlinkability of transactions. Furthermore, pseudonyms can be formed in a way that enables the building of anonymous credentials which prove to one organisation the user’s relationship with another organisation [76]. Such credentials can be for one-time use [14], or for unlimited use [19] (multiple-show credentials). Moreover, the lending of credentials to other users can be made unattractive. This is achieved by forcing all credentials to be released if the user lends only one credential [92]. In PET-based identity systems a person can make flexible proofs about the values of identity attributes. In particular, integer commitment schemes (e.g., [27]) enable the construction of protocols which allow a person’s age to be proved to be in a certain interval without revealing any more information about it [12, 20]. Similar properties can also be achieved for proofs regarding textual information [13]. Commitments to identity attribute values can be issued by trusted authorities, and placed in certificates, for example [74]. On the whole, the state of public research into the mechanisms for anonymity, unobservability, and unlinkability is considered by some to be very good [94]. The implementations [18] and practical use of such systems are, however, still scarce despite the existing recommendations for using the “design for privacy” principle in new systems [107]. The applicability of PET to ordinary identity documents is limited by the fact that most officially recognised identity proofs require biometric authentication (commonly, based on the photo). Clearly, if biometric patterns are read in electronic form, unlinkability stops here, because colluding service providers can exchange biometric patterns and easily combine all the information associated with them.

Mobile identity tools

A number of identity management systems have been developed for mobile devices. For example, a tool called iManager [116] enables the user to manage her partial identities on a personal digital assistant (PDA). It automatically offers the selection of a suitable identity for every use case and controls the dissemination of extra personal information to service providers. Most currently available tools (see a study in [82]) are designed only for online business scenarios. Further- more, most of the schemes concentrate on communication privacy, while no special attention is paid to the security of storage for identity profiles. There are three basic ways of storing identity profiles on mobile devices. The unprotected memory of the device is suitable as a data storage for non-critical applications. For example, mobile browsers can store passwords and data for filling forms on the Internet. Another, more secure way is to use secure mobile environments [5, 103], trusted platform modules [109] or embedded smart

30 2.2. Mobile payments

cards. Yet another option is to store identity-related information on the SIM card [67]. If identity profiles are stored on the SIM card, they can be easily moved from one device to another. However, this comes at a cost. Because the SIM is controlled by the MNO, other service providers can install their applications only if they sign agreements with the MNO. This may be a show-stopper for non-profit organisations which wish to develop their mobile services. In contrast, secure mobile environments enable the building of fully open mobile identity management schemes. Nokia’s OnBoard Credentials (ObC)[34] is an example of such a scheme. It provides mechanisms for the secure provisioning of credentials, based on a device-specific keypair created during the manufacturing process. In addition, ObC supports the secure provisioning of small programs written in a lightweight version of the Lua programming language [58]. Sensitive information is stored within the M-Shield secure environment [103], which is a proprietary solution. As at the time of writing M-Shield has not passed a Com- mon Criteria certification (while most SIM cards have passed it), this might be a problem for deploying bank-issued credentials. For most applications, however, the platform appears to be very useful and flexible. Currently, credentials cannot be easily moved from phone to phone, but there are no apparent obstacles for adding this feature in the future. If a mobile identity tool was to be widely deployed, the mobile phone would probably be the most suitable device for this [78]. Indeed, because most people already have mobile phones, no extra hardware is needed for the launch of the system. Mobile phones also feature security elements: SIM cards and embedded security environments (in many models). Furthermore, users are familiar with the interfaces of their devices. This can have a positive impact on the usability of new solutions. All the required software can be distributed over-the-air by the MNOs [102]. If the tool is made open for use by any identity or service provider, it would have the potential for wide acceptance.

2.2 Mobile payments

The huge popularity of mobile phones has stimulated ideas for using them as a payment instrument. A mobile payment is defined as “any payment where a mobile device is used in order to initiate, activate, and/or confirm this payment” [68]. For MNOs, the benefits of mobile payments include increased volumes of chargeable data communication and improved attractiveness of the subscription. In addition, they can provide value-added services by acting as payment mediators. For merchants, mobile payments can allow them to reduce the number of staff normally required for selling items or for taking care of vending machines. For users, mobile payments often improve the usability of services and save them the need to have money or credit cards always at hand. Indeed, as one user commented on the introduction of mobile ticketing for public transport in the Helsinki area, “this is the greatest invention since the microwave oven”. The development of mobile banking and mobile payments has been the most popular research topic of all m-commerce applications [86]. Dozens of systems

31 Chapter 2. Literature review

have been developed, and many of them are in active use. We provide a brief overview of their features here, concentrating mostly on security properties.

2.2.1 Security and privacy requirements Industrial consortia consider security to be the basic requirement if mobile payments are to be valid and adopted by all stakeholders. The security and privacy requirements of the participants in a mobile payment scheme are different, and therefore we must first define these participants. There are at least two parties in a mobile payment transaction: a customer (payer) and a merchant (payee). In addition, banks or other financial institutions can participate in the transaction to manage the money flow. Essentially, the mobile payment facilitates the logical money flow from an account at the customer’s bank (called issuer) to an account at the merchant’s bank (called acquirer). These parties are common to standard digital payments [8]. The mobile payment, however, often introduces yet another party, namely the MNO, who can partly control the money flow, acting as an issuer of the customer’s electronic account. Furthermore, many mobile payment systems use an additional mediator as a payment service provider. Mobile payments inherit many security and privacy requirements from usual electronic payment systems. One important requirement, namely non-repudiation, is shared by all of the parties. None of them should be able to deny the completion of a payment transaction if the transaction has, in fact, occurred [80]. Another common requirement is message integrity, which ensures that payment data are not altered. For the customer, both the technical and perceived level of security and privacy should be high. Most importantly, customers should not suffer financial losses due to impersonation or other attacks. For privacy protection, confidentiality of the information about transactions is needed. Sensitive information should be provided only on a need-to-know basis. In a “perfect” payment system, merchants do not learn the identities of their customers. Furthermore, issuers, acquirers and MNOs do not learn the identities of the customers and merchants for any given transaction, and do not receive any information about the names, prices and locations of the items purchased. Clearly, sensitive data must also be protected against eavesdropping or modification by third parties. Although technically possible, such “perfect” mobile payment systems are still an utopia in the current world. Normally, security is established through a number of authentication events and authorisation proofs dispatched by the parties. We list these requirements here, following [10]. The issuer normally requires a proof of transaction authorisation by the customer. The proof includes the customer’s and merchant’s identities, and the amount of money to be paid. In order to establish the authenticity of the proof, effective customer authentication is required. In many cases, the issuer or acquirer may require a proof of transaction authorisation by the merchant. Because merchants are often charged for the transaction, this proof is needed to show that they consent to the future payment. Conversely, the merchant might need a proof of transaction authorisation by the acquirer or issuer, to ensure that the money will eventually arrive at the

32 2.2. Mobile payments

merchant’s bank account. In some cases, to enable off-line transactions, a proof of transaction authorisation provided by the customer will suffice. The customer must be protected against paying to a rogue merchant, or to a party impersonating a valid merchant. Therefore, merchant authentication is important. Furthermore, certification of the merchant is needed in some cases. Just as in usual payments, the merchant has to issue a receipt for the money accepted, and provide the purchased items. In many systems some of these requirements are not implemented. This is due to various reasons, the most common of which is choosing usability instead of security or privacy. Indeed, ideal systems are hard to find in the real world, and the situation with mobile payments is no different. Trade-offs between usability and security are very common, and therefore there is no (and perhaps will never be) a system good for all scenarios.

2.2.2 Mobile payment schemes

Mobile payment systems can be categorised in several ways. Since extensive classification of systems is not a goal of this work, we refer the reader to com- prehensive summaries of mobile payment procedures [68, 69, 79] for details. Here we provide only an overview of possible classification criteria, to show the diversity of payment schemes. First, the systems may be classified by the sizes of supported payments into micro-, mini-, or macro-payments. There is no standard definition of limits, but the rule of thumb is that micro-payments are of less than $2, macro-payments are over $20, and mini-payments fit in between. Most simple mobile payment systems support micro- and mini-payments. If there is a payment mediator involved, macro-payments also can be supported. The second way of classification is by transaction type. Transactions can be categorised by their dependence on user location into remote and local/proximity. If no contact to an external entity (such as an issuer or mediator) is needed during transactions, they can be performed off-line, and otherwise only on-line. Transactions can also be divided into pre-paid, pay-now, and post-paid, depending on the time when the actual money transfer is done. Payment systems can support these transaction types in different combinations. Additional division of mobile payment systems into groups is done according to the platforms and technologies involved in their implementation, as illustrated in Fig.3 . In the next subsection we provide an overview of mobile payment solutions with regard to their security.

2.2.3 Security of payments

One can see from the requirements given in subsection 2.2.1 that for business priorities, effective customer authentication is the most important element. How well do currently prevalent mobile payment systems satisfy this requirement?

33 Chapter 2. Literature review

Figure 3: Mobile payments: a summary of enabling technologies.

The simplest mobile payment systems

The simplest and most common systems are based on calling or sending an SMS to a premium phone number. The payment amount is then added to the phone bill. Such systems are offered by virtually all MNOs in the world, and their popularity is explained by the ease of use. However, SMS or call based systems normally support only micro- and mini-payments, placing a limit on the maximum value. This is because such systems do not strongly authenticate the customer, and thus lack a non-repudiation mechanism. Indeed, the customer authentication is based on the PIN code, which is checked once on power-on of the mobile phone. Considering that most phones are always on, they can be used for payments if lost or stolen, or even left unattended for a few minutes. Protection against such misuse is only provided by the shift of liability: customers are ﬁnancially responsible for all payments, unless the SIM is blocked by contacting the MNO. However, the customers can still claim that payments were generated by a rogue insider, and the MNO might have a hard time proving otherwise.

Mediator-based mobile payment systems

Instead of relying exclusively on the mobile subscription, many mobile payment systems (e.g., Fundamo5, Macalla6, MoreMagic7) introduce an extra payment service provider, called a mediator. Users can choose to charge their payments to a separate pre-paid account managed by the mediator, and register their credit or debit cards for topping up this account for future payments. Moreover, mediators can facilitate cross-border and cross-operator payments when the customer is using network roaming. Many mediators provide additional security by introducing an extra PIN which is used for conﬁrming payments (e.g. Mobipay8, Telemoney9). Before a

5http://www.fundamo.com 6http://www.macalla.com 7http://www.moremagic.com 8http://www.mobipay.com 9http://telemoney.com.sg

34 2.2. Mobile payments transaction is made, its details (such as the price of the products, and name of the shop) are sent to the user. The user must supply the service-specific PIN to accept the payment. Although systems that use extra PINs provide additional authentication of the user, they do not solve all security problems. The non-repudiation of transactions is still insufficient. Indeed, users can still theoretically claim that they never entered the PIN, and it was the MNO who confirmed the transaction.

SAT-based security

SAT applets, the mechanism already described in section 2.1.3, is used by some mobile payment systems (e.g., Fundamo or Vodafone M-Platby) for performing customer authentication. However, most such systems are based on symmetric key cryptography rather than on public key infrastructure (PKI): the secret key is shared between the SIM card and the payment system provider. Again, the customer has to confirm payments by entering the payment service-specific PIN code. Then, the SAT applet creates a transaction certificate, which is encrypted using the shared key and submitted to the payment system provider. Such systems feature only slightly better non-repudiation than those described above. In fact, because the secret key is shared between the SIM and the payment service provider, it is still possible for the customer to claim that the transaction has not taken place.

PKI-based mobile payment systems

A few mobile payment systems (e.g., Telenor’s MobilHandel10) use mobile PKI for customer authentication, providing much better non-repudiation of transactions. These systems are similar to those described in the previous paragraph; however, the proof of transaction authorisation is signed with the customer’s private key instead of being encrypted with a shared key. It is important to note that the PKIs used in these systems are usually maintained by MNOs. Unless the MNO is an officially certified qualified certificate issuer, electronic signatures produced by SIM cards are not legally equal to hand-written signatures, and therefore do not provide an ultimate solution to the problem of non-repudiation. In addition, any merchant who wishes to support mobile payments has to sign agreements with all the MNOs providing such service. Al- ternatively, MNOs can sign a mobile signature roaming agreement, enabling the merchant to use services of only one MNO. Several systems use bank-issued customer credentials. Their use is restricted by the fact that credentials are stored on a separate card, and therefore a dual- card or dual-slot phone, or one with an external card reader interface is needed. The availability of such phones is rather limited.

Proximity payments

Short-range communication technologies (such as Bluetooth, NFC, or infrared communication) offer new possibilities for the development of mobile payment

10http://telenormobil.no/mobilhandel

35 Chapter 2. Literature review systems. Off-line payment systems can be easily designed, and transaction times significantly decreased. The first proximity payment systems used infrared connection, whereas new systems use RFID or NFC. For example, MasterCard PayPass and Visa Wave support payments using the mobile phone in the RFID card simulation mode. The security of these systems strongly depends on the resistance of RFID chips against cloning and tampering. The mechanisms for user authentication and transaction non-repudiation are weak, so for macro payments the use of PINs or digital signatures is demanded. Recently, ETSI accepted a set of standards [40, 41] defining an interface between the SIM and contactless front-ends (NFC). The standards describe procedures for contactless access to applications residing on the SIM, enabling the development of new types of proximity payment systems. From the user’s perspec- tive, this turns mobile phones into a new form of contactless multi-application smart card. It is interesting to compare new proximity mobile payment systems with standard credit card payments. In the last few years, the industry has largely switched to using chip cards. The impact of the switch on card fraud losses has been two-fold. In the UK, for example, fraud on lost or stolen cards and on face-to-face transactions has clearly decreased, while the use of counterfeit cards abroad has rocketed [7]. The connection is clear: being unable to clone the chips of new cards, fraudsters have continued cloning magnetic stripes, and switched to raising money abroad. This type of fraud may become more difficult with the global introduction of chip cards and terminals. However, new vectors for attacks have already been devised. They are based on the manipulation of payment terminals: namely, a fraudster can mount a MITM attack using a rogue terminal, lying about the amount and purpose of the payment [32]. The terminal displays the correct amount of money, and the customer enters her PIN without any suspicion. However, the actual payment data contain another amount and are relayed to a different merchant. Clearly, the problem here is the lack of a trustworthy user interface. Moreover, the manipulation of terminals can be used for collecting card details and PINs [33], for later use in other types of attacks. Since there are many models of PIN-entry devices with different user interfaces, a common user can hardly tell fraudulent and legitimate terminals apart. Attacks involving fraudulent terminals can be expected to work with current proximity mobile payment systems. However, in all the other systems described in this section (except the simplest ones), these attacks are more difficult. Indeed, to mount them, the attacker has to modify information about the transaction as displayed on the mobile phone screen. Unless this is achieved by penetrating the phone with a virus or trojan, or by attacking the MNO-phone link, the display provides trustworthy information about the payment. The customer can check all the details on the screen before accepting the transaction. It is therefore easy for the customer to notice any difference in the details displayed by a fraudulent terminal and the actual payment data.

36 3 Aims of the study

3.1 Motivation

The present study was undertaken to provide a number of improvements to the currently prevalent identity management and mobile payment procedures. Initially, the study started from the observation that the security of GSM networks is essentially focused on the segment between the mobile equipment and the base station. At the same time, the traffic in the operators’ networks is in plaintext, in principle allowing insiders in the MNO organisation to easily modify or eavesdrop on it. In turn, this means that the system does not provide sufficient non-repudiation of transactions handled through it, unless additional security is built on the higher levels. Although the confidentiality of message traffic can be rather easily achieved with encryption, key management becomes a problem. For sound non-repudiation, the use of digital signatures is required. At the time when our study was started, national mobile PKI had already been launched, and we began investigating whether it was possible to utilise it for providing message security. It turned out that the system was rather closed and centred around MNO services built using proprietary solutions. We considered this to be inappropriate, because in our view national systems should be open to use by any service providers and their customers. We also began examining the level of privacy protection provided by MNO- centred authentication systems, and comparing them with other electronic identity solutions. It turned out that despite the availability of privacy-enhancing technologies, none of them has been applied in the design of current electronic identity systems. Additional motivation was provided by the idea of combining several identity tokens into a single multifunctional identity tool. Identity federations, widely used on the Internet, have their counterpart in the “physical” world: multi- application smart cards have been available for almost a decade. However,

37 Chapter 3. Aims of the study

their actual use is rather limited. Post-issuance downloading of new applications, which could have been used for more advanced identity management, is disabled in most such cards. Having witnessed the exceptionally slow start of systems built around multi-application smart cards, we set out to design a tool similar to them but working on the mobile phone and open for use by anyone.

***

Although they have been available for 4–5 years, electronic identity documents and identity management solutions are still in their infancy. There have been some improvements since the release of the first versions but many electronic ID documents are still neither widely accepted by citizens nor extensively employed in new services. Most importantly, officially recognised electronic IDs do not provide sufficient protection of their holder’s privacy. Indeed, a considerable amount of information about a person’s identity is often revealed to people who only need a tiny part of it. Although privacy-enhancing technologies exist in the electronic world, they have not so far been used for facilitating officially recognised identity proofs. Several mobile identity tools have been developed, but most of them are targeted at helping users to manage their on-line identities. No special attention has been paid in creating such tools to the protection of the storage medium for identity-related information. The only prominent exception to this rule, Nokia’s OnBoard Credentials, is based on a proprietary solution that has not passed the certification required for its use in officially recognised identity proofs. The mobile payment is a good example of mobile identity applications. Despite the diversity of currently available mobile payment systems, only a few of them use advanced security technologies for efficient customer authentication and non-repudiation of transactions. In all of them authentication is carried out through services provided by the mobile network operator. This makes the systems difficult to join by merchants and financial service providers, increases the cost of payments, and decreases transaction speeds. They are being widely promoted as the “next big thing”, but the proximity payment systems currently on the market do not feature strong security mechanisms and are therefore used normally only for micro- and mini-payments.

3.2 Research hypotheses

The research is based on the following three hypotheses, each split into three claims.

Research hypothesis 1: Strong mobile user authentication

(a) Strong authentication of mobile users can be performed by employing a national electronic identity system and corresponding infrastructure.

(b) The authentication of mobile users can be done without using the authentication services of mobile network operators.

38 3.3. Research methods

(c) Systems that rely on such authentication can be fully open and easy to join by any customer, mobile network operator, service provider, and ﬁnancial institution.

Research hypothesis 2: Pseudonymous mobile identity (a) A national electronic identity system can be used for building a general user and citizen identification and authentication system for access control. (b) Such a mobile identity can be securely used in many applications instead of usual identification cards or passports. (c) Privacy in systems that use such a mobile identity can be higher than in systems that use usual identification cards and passports.

Research hypothesis 3: Open mobile identity

(a) A mobile phone with a security element such as the SIM card is a suitable device for becoming a ubiquitous mobile identity management tool.

(b) The tool can facilitate flexible identity proofs using chosen identity profiles. (c) Such tool can be open to use by any identity providers and identity verifiers.

3.3 Research methods

The first part of the study was exploratory, with the goal of defining concepts and analysing the state of the art. This part pointed out problems in and drawbacks of the currently available solutions. The second part was constructive, developing new architectures for solving the problems identified in the first part. The developed solutions were then evaluated using proof-of-concept implementations. The main part of the work was constructive.

4 Results

4.1 Mobile user authentication

In GSM networks, user authentication is based on a secret key (Ki) which is shared between the SIM card and the MNO. Theoretically, this is a two-factor authentication, based on something that the user has (the SIM) and something that the user knows (the corresponding PIN). In practise, however, PINs are normally entered only once on power-on. Therefore, authentication is not strong enough for some mobile services, as it does not provide a sufﬁcient level of non-repudiation of transactions. An easy way to overcome this problem is to use SAT applets (see Sect. 2.1.3). Such authentication is employed in ofﬁcially recognised solutions such as Mobiil- ID in Estonia and similar systems in Finland and Turkey. MNO services are used for sending the challenge to the user’s mobile device, receiving and interpreting the response, and reporting the result of authentication. While the scheme is indisputably practical for many use cases, in our view it is logically controversial. Indeed, as the mobile phone is a smart card terminal with a keyboard, why use MNO communication and authentication services for accessing the SIM?

4.1.1 Data ﬂow

The goal of study I was to provide conﬁdentiality and non-repudiation of SMS messages. We planned to use the FINEID PKI in order to avoid the key management problems common in systems that use symmetric encryption. By the time we started the work, PKI-SIM cards with FINEID functionality had become available. However, their functionality was based on the M-COMM standards (see Sect. 2.1.3). In order to provide a similar functionality without the use of the MNO’s authentication services, we developed the following model. As usual, the user’s private key is generated on the SIM and stored on it in a SAT applet; this

41 Chapter 4. Results operation is performed by the MNO. The CA (the Finnish PRC) issues a public key certificate to the corresponding public key. This certificate is stored in a public directory accessible through the Lightweight Directory Access Protocol (LDAP). In order to use operations performed on the SIM with the private key, the following structure for the data flow was developed (see Fig.4 ).

Mobile equipment

J2ME SATSA SIM

Identity 1. PIN Java Card proxy applet 2. Message

3. Signature User User's interface private key

4. Signed message Bluetooth/NFC/GSM/GPRS/...

Another Vending Payment Remote mobile machine terminal server phone Recipient

Figure 4: Mobile user authentication: technologies and data ﬂow.

A Java 2 Mobile Edition (J2ME) applet, which we call the identity proxy, provides a user interface for composing a text message, acquiring a signature for it from the SIM-based applet, and sending it to another party1. The user’s PIN is requested before a signature is calculated. The message is encrypted using the recipient’s public key. This provides strong two-factor authentication of the mobile user, and the non-repudiation, conﬁdentiality and integrity of the text message. To enable communication between the SIM and a J2ME applet, we use the security and trust services (SATSA) application programming interface (API) for Java, deﬁned in JSR-177 [62]. The API consists of four packages:

1. SATSA-APDU is an API that enables J2ME applets to communicate with smart cards connected to the device. In communication, the application protocol data unit (APDU) format of messages is used.

1In publication I, the order was the opposite, i.e. the message was ﬁrst ciphered and only then signed. We corrected this because it is good practice to sign the plaintext, as this proves that the sender has seen the plaintext.

42 4.1. Mobile user authentication

2. SATSA-JCRMI enables an application to communicate with a smart card using the Java Card Remote Method Invocation (JCRMI) protocol.

3. SATSA-PKI provides functions for the generation of digital signatures and for user credential management. Keys are normally stored on smart cards connected to the device.

4. SATSA-CRYPTO includes implementations of certain cryptographic primitives: message digests, ciphers, and digital signatures. The API is a subset of the Java 2 Standard Edition (J2SE) platform Java Cryptography Extension (JCE).

All these packages are optional; a device can implement any set of them. In our architecture, we use only the package SATSA-APDU, for sending commands to the applet running on the SIM, and receiving answers from it. The only operation performed by the SIM-based applet is the calculation of a digital signature for a given message. All other operations are performed in the identity proxy. The word proxy is used because the application works as a logical interface between the SIM-based applet and devices accessed through external communication technologies. Such devices could be other mobile phones, payment terminals, remote servers, or vending machines, for example.

4.1.2 Applications

Since the contents of SMS messages are available to MNOs in standard GSM networks, the standard SMS is not a suitable communication service for sending confidential information. The simplest application of the proposed scheme is true end-to-end encryption of SMS messages. Correspondents can retrieve each other’s public keys from the FINEID directory, which means that no exchange of keys is required prior to communication. With a key size of 1024 bits (128 bytes), a 128-byte message fits in one binary SMS block (the maximum length of which is 140 bytes). In addition, one SMS message is required for transmitting the signature of the message with a timestamp. The scheme can be also used for mobile payments; an outline for a vending machine payment protocol is provided in the paper. This idea was further developed and protocols for a mobile payment system were designed in study II. To summarise, any applications that require strong mobile customer authentication can benefit from the scheme. In addition to authentication, the scheme can also be used for acquiring the user’s signature for a short contract, or for a short digest of a contract of any size. Computationally this is possible: many SIM cards have cryptographic coprocessors which allow 1024-bit signatures to be calculated in less than 200 ms.

4.1.3 Evaluation

The functionality of the scheme is similar to that of M-COMM standards developed by ETSI, because both schemes provide services for two-factor authentication of the mobile user and mobile signatures. In addition, our scheme provides end-to- end encryption for SMS messages, the contents of which become unreadable by the MNO.

43 Chapter 4. Results

The most significant difference between the schemes is in their implementation. Our scheme does not use authentication services provided by the MNO: only standard (packet-based and SMS) communication goes through the mobile network. However, this comes at the cost of increased requirements on the user’s device. The identity proxy J2ME applet uses the SATSA API which is available only in newer mobile phone models. Furthermore, the usability of the scheme is somewhat degraded by the need to install the identity proxy on the mobile phone. Although the scheme is not fully flexible, it works as a starting point for the further research presented in this thesis. The architecture of the data flow is used in other papers, in which the idea of storing user’s credentials on the SIM is extended.

4.2 Mobile payment systems

Strong mobile user authentication and the related non-repudiation of transactions facilitate the development of mobile payment systems that support macro-payments and that can be used in both physical point of sale (POS) and virtual POS scenarios. If a national PKI is utilised in the system, the payment scheme can become open and easy to join by any ﬁnancial service providers, merchants, MNOs, and users. Publication II (preliminary results in [53]) presents an open mobile payment scheme that is based on the Finnish national PKI, with private keys stored on users’ SIM cards. The architecture for data ﬂow presented in the previous section is utilised.

4.2.1 Protocols and implementation

Our mobile payment system consists of two protocols, one of which is used for physical POS payments, and one for virtual POS payments. Details of the protocols are given in Sect. 4 of publication II; here we provide a brief overview. The following parties interact in these payment protocols. A customer is a user of a hand-held device who has received a PKI-SIM card with the functionality described in Sect. 4.1.1. A digital identifier of the customer is the Finnish electronic user identity (FINUID). A merchant is an owner of a POS terminal (or a vending machine) or a service provider that accepts mobile payments online. The merchant has a private key and a corresponding public key certificate registered in the FINEID system. A bank or other credit organisation such as Visa or MasterCard is a financial institution that processes payments. The customer has an account with the bank, or has been issued with a credit card operated by it. If the customer has multiple accounts with or credit cards issued by the bank, the bank is informed which one to use for mobile payments. The bank has the right to charge the customer’s account or credit card when presented with a payment order signed by the customer’s private key. The customer cannot repudiate transactions in this case, as his authorisation in the form of a PIN is required for unlocking the private key with which transaction details are signed.

44 4.2. Mobile payment systems

Virtual POS payment

The virtual POS payment model that we present facilitates online payments from a mobile phone. The user’s credentials stored on the SIM are used to conﬁrm the payments. A payment is initiated when the user browses a merchant’s website and chooses to make a purchase. The overall payment model is depicted in Fig.5 .

1. Service request

2. Service options $

3. User‘s selection 4. Payment details

6. Product delivery 5. Payment confirmation

Customer Merchant Bank

Figure 5: Virtual POS payment model.

1. Service request The customer initiates the protocol with the merchant by requesting product options. The request may contain information which limits possible options. 2. Service options The merchant sends a list of options to the mobile device. The list includes short descriptions of products and pricing information. The merchant also attaches its certificate to the list of options. 3. Product selection The customer is prompted by the mobile device to select a product from the list. While the customer is busy selecting a product, the merchant’s certificate is verified. In addition to the product details, the following information is included in the message sent to the merchant:

• Identifiers of the customer and the bank; • A timestamp and a nonce generated by the customer; • A signature confirming essential payment details: product description (masked by hashing it with the nonce), payment amount, and identifier of the merchant. The signature will be verified later by the bank.

To prevent the reuse of the signature by the merchant (the merchant could send it to a number of other banks, hoping that the customer has accounts there) to receive the payment several times, the signature must contain the bank’s 2 identiﬁer . IDBANK should therefore be part of the signature (see p. 220 of publication II):

SIG H TIME ID ID PRICE CUSTBANK = ( CUST MERCH BANK ) | | | | H(PRODUCT NONCECUST) SKEY . | CUST The product order is signed with the customer’s private key. The product description is included for enabling later adjudication in case of a dispute, and is masked to hide its contents from the bank. 2Tuomas Aura is gratefully acknowledged for the suggestion of this correction.

45 Chapter 4. Results

4. Payment request The merchant sends details of the payment to the bank. They include the identifiers of the merchant and the customer, payment amount, masked product description, and the payment order (a signed message received from the customer in the previous phase). The payment request is signed with the merchant’s private key. 5. Payment confirmation The bank performs all the necessary checks on the payment request and then transfers the indicated amount of money from the buyer’s account to the seller’s account. The bank sends a notification to the merchant, confirming that the payment was made with the agreed amount from the account of the customer to the account of the merchant. The confirmation is signed using the bank’s private key. 6. Product delivery The merchant forwards the payment confirmation to the customer and delivers the product.

Proximity (real) POS payment

Our protocol for proximity POS (vending machine) payments is somewhat more complicated. The reason for this is the assumption that the vending machine is not connected to a network, all communication being handled through the customer’s mobile phone. The customer acquires a proof of its certificate validity, and delivers the payment receipt from the bank to the vending machine. Certifi- cate validity proofs are provided in the form of digitally signed OCSP responses [83]. The vending machine must have a public key certificate of the OCSP server in order to check a response. Because the vending machine might not have a reliable source of time, it might be possible for the customer to replay an old OCSP token in a fresh message. To avoid this we use a challenge-response scheme, where the vending machine gives the customer a challenge for which the customer has to show a timestamped response. For simplicity we propose to have one signature which ties together the response, message, timestamp, and certificate validity statement. An overview of our mobile payment model for vending machines is presented in Fig.6 . The protocol involves nine steps (terms merchant and vending machine are used interchangeably in the description). 1. Initiation The customer chooses a product, and specifies that mobile payment is to be used. 2. Bluetooth pairing In our model, we use Bluetooth as a communication technology between the mobile phone and the vending machine. To enable the exchange of messages, Bluetooth pairing must first be performed. If several Bluetooth devices are in the range, the vending machine can generate a random PIN and show it on the display for pairing. The customer must enter this PIN in the mobile phone. 3. Product offer The vending machine sends a message with information about available (or selected) products and their prices. Otherwise, the list of products contains only the already selected item. In addition to this data, the vending machine sends its own certificate and a random nonce which is used for protection against replay attacks.

46 4.2. Mobile payment systems

1. Initiation

Vending 2. Bluetooth pairing machine 3. Product offer

4. Product selection

5. Payment request

8. Payment receipt

Bluetooth

9. Product delivery

6. 7.

Payment Payment order receipt

Certificate FINEID validity assurance (CRL/OSCP)

Key BANK Database

Figure 6: Real POS (vending machine) payment model.

The customer extracts the merchant’s certificate and checks its validity. The list of products is parsed and shown on the mobile phone display. 4. Product selection When the customer has selected a product, the information about the product selection is sent to the vending machine. In addition, the message contains a nonce generated by the mobile device, and the customer’s certificate. A hash of the product selection and two nonces (the one received from the vending machine, and the one generated by the mobile device) is signed with the customer’s private key. Using this signature, the vending machine can authenticate the customer. The mobile phone must store the price of the selected product, as it will be needed later for the payment. 5. Payment request The vending machine sends a payment request to the customer. The request is signed using the vending machine’s private key. The payment details include the account number, and an identifier of the vending machine. The price of the product is not sent with the payment details, since the customer already knows it. However, it is included in a hash in the second part of the message, which is intended for the bank and includes a signed hash of the customer’s certificate, the price of the product, and both transaction- related nonces. This part works as a proof of the transaction authorisation by the merchant, and prevents the customer from offering one certificate to the merchant and another to the bank. The signed hash can also be stored by the customer as a receipt from the vending machine. Combined with a receipt from

47 Chapter 4. Results the bank (sent in phase 7), it can be used later as a proof of the purchase if a dispute arises. After receiving the payment request, the customer verifies the merchant’s signature on it. 6. Payment order The customer sends a payment order to the bank. The payment order contains all the information received from the merchant in the previous step. In addition, an account number of the customer, identifiers of the merchant and the customer, a timestamp, and both transaction-related nonces are included in the order. The payment order is sent to the bank encrypted with the bank’s public key and signed with the customer’s private key. 7. Payment processing After receiving and decrypting the payment order, the bank verifies signatures made by the customer and the merchant. Their public keys are retrieved from the FINEID directory, using identifiers in the payment order as the search criteria. In addition, the bank checks that neither of the certificates is on the revocation list. If all necessary checks are passed, the bank makes the money transfer. If the merchant’s account is in another bank, the usual interbank procedures are used for crediting money to the merchant. When the transaction has been processed, the bank sends a confirmation message (receipt) to the customer. The receipt provides proof that the payment has been made. The receipt includes the bank account number of the merchant, the amount of money paid, and transaction-related nonces. The receipt is signed using the bank’s private key. 8. Proof of payment In phase 8, the mobile phone forwards the bank receipt to the vending machine. In order to specify which bank’s public key must be used for verification of the receipt, the bank’s identifier is included in the message. The vending machine checks the receipt and delivers the product to the customer. The vending machine must have a list of valid public keys of different banks. If the vending machine does not have a network connection, the protocol may be easily extended to include an OCSP proof of the bank certificate validity in the proof of payment. 9. Product delivery The vending machine delivers the product, and marks the transaction as processed.

Implementation As a proof of concept, we designed and implemented a system for purchasing train tickets using a mobile phone as described in the virtual POS payment model. Software run by the customer’s mobile phone was written using J2ME in Sun Wireless Toolkit (WTK) version 2.2 from Sun Microsystems. Routines that involve cryptographic processing (such as encryption or handling public key certiﬁcates) were implemented using Bouncy Castle API [106]. The SIM-based applet responsible for signing the product selection and the payment order was realised using JCOP tools running within the Eclipse IDE [57]. We used the usual bankcard-sized FINEID card in our tests, because the PKI-SIM cards currently deployed by Finnish MNOs are based on the M-COMM standards. To enable communication between the J2ME applet and the card, we developed a

48 4.2. Mobile payment systems

small mediator program which accepts commands arriving from the WTK, sends them to the card, and forwards the card’s responses back to the WTK. For the WTK this is completely transparent because the standard SATSA API is used. No mobile phones implementing SATSA-APDU were available when our work was done. Therefore, to test the application on a real mobile phone, we prepared a modified version of the program, in which no access to the SIM is used. Instead, the customer’s private key is stored, and operations on it performed in the J2ME applet running on the mobile phone itself. Transaction speed and user convenience was tested on a Nokia N91 phone. Retrieving train connections that matched the search criteria from the server using General Packet Radio Service (GPRS) communication took an average of 3.2 s. An average of 8.6 s was required to create and send the order message and to receive and verify the response message. Some of the response time was consumed by retrieving and verifying certificate information. After this communication was moved to an earlier stage (to be performed while the customer is choosing a suitable ticket), the response time decreased to an average of 7.5 s. An implementation which requests signatures from the SIM card could have a slightly different performance. Signatures can be produced by modern SIM cards in less than 200 ms; some additional time is required for the APDU exchange. The time and effort required for Bluetooth pairing could negatively impact the usability of the scheme. To avoid this, NFC could be used instead of Bluetooth or in addition to it. The benefit of NFC is its shorter working distance (about 2 cm in current mobile phone implementations). In places where POS terminals are placed close to each other, NFC provides an easier way to ensure that the proper terminal is contacted. NFC can also be used to initiate and configure the Bluetooth communication, using the recently introduced Connection Handover specification3. The drawback, however, is that NFC is still supported by only a few devices, whereas Bluetooth is already widespread.

4.2.2 Security, privacy and usability Our mobile payment scheme satisﬁes the following security and privacy requirements. In the description, we follow the requirements listed in Sect. 2.2.1 and in [10].

Bank requirements Proof of transaction authorisation by customer The customer signs (with the private key, access to which is authorised by the PIN) the payment order that includes an identiﬁer of the vendor, the amount of money to be paid, and a timestamp. The signature provides an undeniable proof that the customer has authorised the payment. Signatures are protected against replay attacks by timestamps. Due to their legal acceptance, signatures can be used to resolve disputes between the customer and the bank. Proof of transaction authorisation by merchant Payment requests are signed by the merchant using its private key. Payment requests cannot be replayed by

3http://www.nfc-forum.org/specs

49 Chapter 4. Results an external adversary or by the customer due to the use of timestamps (in the virtual POS payment) or nonces (in the real POS payment).

Merchant requirements

Proof of transaction authorisation by customer After choosing a product or service, the customer signs this selection using their private key. The signature is an unforgeable proof that the customer has authorised the transaction. Proof of transaction authorisation by bank If a transaction is successfully processed, the bank generates and signs a receipt which is delivered to the merchant. If the merchant does not receive the receipt, or if veriﬁcation of the signature fails, the product is not delivered to the customer. The merchant can store the receipt as a proof of transaction authorisation by the bank. Replaying of bank receipts is prevented by the use of timestamps and nonces.

Customer requirements

Unauthorised payment is impossible It is not possible to produce valid signatures unless one possesses a practically unforgeable token (FINEID card) of the customer and knows the PIN corresponding to it. The easiest way to obtain these is to learn the PIN code by shoulder-surfing and then steal the phone. The security level is thus comparable to that of automatic teller machine (ATM) cards. However, the odds are that the phone can be missed by the customer considerably sooner than an ATM card. Proof of transaction authorisation by bank In both protocols the customer receives a signed receipt from the bank. In case of a virtual POS payment, the receipt is forwarded by the merchant to the customer. In a real POS payment, the receipt is sent by the bank directly to the customer. Bank receipts are protected against replays by the inclusion of timestamps and nonces. Certification and authentication of merchant In our mobile payment scheme, the customer receives the merchant’s certificate directly from the merchant. The customer can check the certificate validity by submitting a query to the FINEID directory. Messages that contain product selections are encrypted under the merchant’s public key. Nonces are included in these messages, to enable challenge-response authentication of the merchant. Unless the merchant possesses the private key associated with the public key in the certificate, it cannot proceed with the payment protocol. Receipt from merchant In a virtual POS payment the merchant forwards a signed bank receipt to the customer. The receipt states that the bank has authorised the payment, which in turn means that the merchant had asked for a payment and thus agreed to deliver the product or service. It must be noted that the merchant can always refuse to forward the bank receipt to the customer. However, in this case the customer can use the next bank statement as a proof of purchase. In a real POS payment, the customer receives two receipts: one from the vending machine as an authorisation of the transaction, and one from the bank as a proof of the payment.

50 4.3. Open Mobile Identity

Privacy

In an ideal case, merchants should not learn the identities of their customers, and banks should not receive any information about the products that their customers purchase. Clearly, the conﬁdentiality of the order and payment details should be protected from eavesdropping. Our mobile payment scheme does partially satisfy these requirements. Product selection details are sent from the customer to the merchant in encrypted form, preventing eavesdropping. The bank does not receive any information about the purchase except its price, and the identities of the customer and the merchant. The merchant learns the identity of the customer, and in a real POS payment also the name of the bank used by the customer. These are the same details as in a normal credit card payment.

Usability

It is clear that there is no mobile payment system that is perfect for all purposes. We believe that our system is good mostly for macro-payments, whereas for mini- and midi-payments a simpler system (e.g. one based on sending an SMS or making a call to a premium number) would sufﬁce.

4.3 Open Mobile Identity

In everyday life, the identity profiles of a normal person range from a paper business card to the most sophisticated bank and national eID cards. As discussed in Sect. 2.1.3, the recent switch to e-IDs has mostly concentrated on the prevention of forgery, whereas privacy issues have not been addressed properly. The usability improvements have also been small, if any. At the same time, it is reasonable to expect that we should be able to conduct various “identity transactions” electronically with the same ease as we conduct them in various face-to-face situations, such as exchanging business cards at a conference, but with more convenience, better security and with a reasonable degree of privacy. In particular, we should be able to identify ourselves in trivial situations such as proving our right to a concession ticket on a bus, without revealing other personal and in these circumstances non-relevant information such as name or address. However, none of the currently available identity tokens can tackle this identity management problem appropriately. An ordinary electronic identity document, such as an eID card or a biometric passport, normally contains only a single identity profile. A significant amount of personal information is stored there in a machine-readable form, and thus can be accessed instantaneously and indiscriminatingly. Multifunctional identity tokens (such as the Malaysian eID card) are rare, and their potential has not been exploited fully, as discussed in Sect. 2.1.4. But it does not mean that there is no bright future for the idea. We argue that the emergence of mobile phones enriched with NFC technology is instrumental for the development of a multifunctional mobile identity management tool which can be used in proximity transactions. Moreover, the tool can be made ubiquitous,

51 Chapter 4. Results

covering more scenarios than usual eID tokens, and feature better usability. Thus, it has the potential to become a truly personalised identity assistant.

4.3.1 Mobile terminal as a personalised electronic identity tool In publication III we extend the idea of storing the user’s credentials on the security element (such as the SIM card) in the hand-held device. We propose using the combination of a SIM-based applet and the phone-based identity proxy for providing flexible proofs of the user’s identity. Publication V further develops this system, providing support for multiple identity profiles. An open mobile identity tool is presented, where the notion of openness means that any identity provider can load an identity profile to the user’s device. As a highly personal gadget, the mobile phone has psychologically already become a suitable device for facilitating identity proofs and mobile payments. Also technologically, it is a reasonable tool for securely storing its user’s identity profiles and communicating with identity verifiers and service providers. Indeed, any GSM mobile phone contains a tamper-resistant secure element, the SIM card. Many SIMs are certified according to the Common Criteria (ISO/IEC 15408) standard, to evaluation assurance level EAL4+, and therefore can be used for applications requiring a high level of security. Examples of such applications are officially recognised identity proofs and digital signatures (e.g., SIM cards with FINEID functionality). Existing mobile identity solutions, an overview of which is given in Sect. 2.1.3, show that storing officially recognised credentials on the SIM is accepted both by the authorities and users. In addition to the SIM, many hand-held devices include, or will include soon, secure execution environments and embedded smart cards, which can also be used for storing keys and identity-related information. One of the most important benefits of hand-held devices is that they incorpo- rate both the secure element and a terminal for accessing it. When it comes to transactions operating on identity or payment-related data, users are more likely to trust their own mobile phones rather than a PIN-entry device of an uncommon type in a new place. Indeed, newer attacks on chip-and-pin cards are essentially MITM attacks that are based on tampering with payment terminals (see p. 36). The same attacks are harder to mount with the user’s own terminal, because users receive trustworthy information about what exactly is happening in each transaction. Moreover, improved trust is also supported by better usability: when the user learns to operate only one interface on her own device, this suffices in every situation.

4.3.2 Architecture and infrastructure The architecture of our mobile identity tool (Fig.7 ) is based on the data flow model already described in Sect. 4.1.1. However, now the SIM-based applet contains not only a private key of the person, but also some identity-related information. The identity proxy provides an interface between the identity verifier’s terminal and the SIM of the prover’s mobile phone. The main tasks of the identity proxy is to check identity verification requests, provide a user interface, and construct identity proofs in cooperation with the SIM-based applet.

52 4.3. Open Mobile Identity

In particular, it checks the identity veriﬁer’s credentials, shows a description of requested data, and acquires the user’s consent prior to constructing an identity proof. Furthermore, because SIM cards do not have their own clock, the identity proxy is the source of timestamps for identity proofs.

Id entity verifier’s Mobile equipment terminal NFC J2ME SATSA SIM

1. Identity check request Identity 2. Request Java Card proxy applet 3. PIN

5. Identity proof 4. Proof User Identity interfa ce profile(s)

Figure 7: Identity proofs: technologies and data ﬂow.

To enable appropriate privacy protection, we demand the use of informed user’s consent: the person must be notified about what information will be sent and to whom it is communicated. No identity information is sent unless the user’s consent is acquired for this. The architecture that we have developed is specifically suited for proximity scenarios. Therefore, we have chosen NFC as the communication technology between the person’s hand-held device and the identity verifier terminal. Although currently the number of mobile phone models that support NFC is rather small, it has been predicted that by 2012 already 20% of mobile phones will be equipped with NFC [4]. Taking into account the recent acceptance of NFC-related standards by ETSI, and wide support provided by MNOs and financial service providers, such predictions seem to have a solid ground. For the development of applications that use NFC, a J2ME API exists [61]; we have used it in our proof-of-concept implementations.

4.3.3 Flexible identity proofs based on a single identity profile Publication III presents a pseudonymous mobile identity tool, the core of which is a long-lived public key certificate issued to a pseudonym in the form of a cryptographic hash of the user’s digital photo. This hash is written in the “subject name” field of the certificate; the actual name of the subject is not included in the certificate. Instead, the rest of the user’s identity information (including identity attributes and the user’s photo) is stored separately in the applet. All these data and the private key corresponding to the user’s certificate are stored on the SIM. Identity attributes are stored as pairs of the form field id, value , where field id is the attribute type (we use standard X.509〈 attribute codes [〉100] for coding). An identity verification request contains a list of triples

field id operator [value] +, 〈 | | 〉 53 Chapter 4. Results where the operator is one of =, <, >, =. The last element, namely a comparison value, is optional. It is skipped in many6 situations: for instance, a request for the subject’s name is formed as

surname identifier = , first name identifier = . 〈 | | 〉 〈 | | 〉 In the case where the operator is other than =, a value must be speciﬁed. Operators < and > are used for checking whether a particular attribute value belongs to a certain interval: for example, to check whether a person is over 20 years old, a triple

date of birth identifier < 4.12.1988 〈 | | 〉 must be sent, if the transaction takes place on 3.12.2008. Use cases for the operator = are harder to ﬁnd, but one possible scenario is proving that one is a resident alien6 in the country.

Figure 8: An identity proof: main idea.

Identity verification requests must be timestamped and signed with the verifier’s private key. The identity proxy verifies the signature and checks the freshness of requests before providing any answers to them. A request is submitted to the SIM-based applet tuple by tuple. The main body of an identity proof is again a list of triples

field id operator value +. 〈 | | 〉 The list is appended with a timestamp and signed with the user’s private key. In addition, the user’s certificate and photo are sent to the verifier. Having received the identity proof, the verifier will first validate the certificate and verify the signature of the proof. Then, he will calculate a hash of the photo, and check whether it matches the subject name in the certificate. The photo will be shown on the verifier’s screen. If the person looks the same as in the photo, and if values

54 4.3. Open Mobile Identity

Figure 9: A proof-of-concept implementation of an identity proof scenario. From left to right: request composed by the identity veriﬁer; request shown to the user; response received by the identity veriﬁer.

of the attributes indeed satisfy the requirements set in the request, the verifier and the prover will proceed with their business. This scenario is depicted in Fig.8 , and an example using our proof-of-concept tool is given in Fig.9 . The tool can provide flexible proofs of identity attributes. However, in other respects, the tool is not general and flexible enough. The biggest limitation is that only one identity profile is supported, and it cannot be updated after the SIM card containing it is issued to the user. This also can be bothersome from the point of view of unlinkability: the same pseudonym is used in all proofs, namely the hash of the user’s photo. In addition, it is unclear how to combine mobile payments with this model.

4.3.4 An open mobile identity tool

In study V, we show how to overcome the limitations of our pseudonymous mobile identity tool. A way to load multiple identity profiles into the open mobile identity tool is provided, and the set of its applications extended. In this new architecture, pseudonyms play a crucial role. Sometimes the same biometric (e.g., a photo) or a pseudonym of the person can be used in different contexts, and thus in different identity profiles. Therefore, identity profiles are issued to pseudonyms stored in an open pseudonym pool. The semantic meanings of pseudonyms in the pool could be “User’s photo” or “Customer ID of ShopChain Ltd.”, for example. Their content could thus be a biometric template, a number sequence (representing a customer number, for example), or a string (representing a customer name, for example). Similarly to the tool described in III, identity profiles are issued to cryptographic hashes of pseudonym values. This means that biometric templates are not by default communicated to identity verifiers. Naturally, the person uses different pseudonyms in different circumstances.

55 Chapter 4. Results

An identity profile is based on a private key generated on-card. The corresponding public key is signed by the identity issuer (who in this situation is playing the role of a CA), in a public key certificate issued to a pseudonym. Identity-related information, in the form of identity attributes, is stored separately from the certificate. Typical attributes in many “official” include Date of birth, Social security number or Type of residence permit, whereas in self-created profiles these may be PGP key, Personal web page address or Mobile phone number. Attribute certificates (AC, as per RFC 3281 [42]) associate attributes with the public key of the person. The values of attributes in the ACs are masked: certificates contain only hashes of the form H(A, M), where H( ) is a cryptographic hash function, A is an attribute value and M is its randomly· generated mask. ACs are signed by the identity issuer. Attribute values and masks are stored separately from the AC, in the same identity profile. An identity verifier can verify an attribute value only if it has received the value together with the corresponding mask (in addition to the AC). In addition to the private-public key pair, an identity profile can also contain secret keys for symmetric encryption. This facilitates using the mobile phone as a secure authentication token for online banking, and as an electronic turnkey. The mobile identity tool is issued to the person on a SIM card by her MNO. The identity applet on the card is initially empty: it contains no identity profiles except, maybe, a profile supplied by the MNO. However, the applet includes a private key and a corresponding public-key certificate called a profile-loading certificate. The subject name in this certificate is the same as the card number. The certificate is used later on for authenticating the card prior to loading any identity profiles to it. The user must also install the identity proxy application on the phone. Alter- natively, the application may be pushed over-the-air by the MNO.

Loading identity proﬁles

The identity tool can be updated with new identity profiles. The user can load new profiles at any identity issuer. Examples of potential identity issuers include shop chains (issuing loyalty profiles), banks (issuing profiles with credentials for payments), or authorities (who can issue official licenses or profiles that replace standard identity documents). The openness of the tool also enables the user himself to create and load new profiles, for example business cards. In order to load a profile into the identity tool, a protocol consisting of three phases is followed. First, the SIM-based applet and the identity proxy, acting together, create a certificate signing request (CSR). Second, the identity issuer constructs the profile. Finally, the new profile is loaded on the card. The process is started by the identity proxy that generates a fresh timestamp and submits it to the SIM-based applet. A new key pair is generated on card. The public key and the timestamp are concatenated, signed using the SIM card- specific profile-loading private key and sent to the identity proxy. If there is a suitable pseudonym in the pseudonym pool that can be re-used, the identity proxy retrieves it from the card. Otherwise, it either asks the user to enter a new pseudonym, or leaves the creation of it to the identity issuer. The pseudonym is placed in the subject name field of the CSR. The signature of the newly created

56 4.3. Open Mobile Identity public key is written in the set of attributes in the CSR [89]. The identity proxy constructs the CertificationRequestInfo block of the CSR and acquires a signature for it from the card (the newly created profile-specific private key is used for signing). Finally, the CSR is submitted to the identity vendor, together with the profile-loading certificate. Having received the CSR, the identity issuer verifies its signatures and checks the profile-loading certificate. Whenever needed, a normal user authentication procedure with regard to the presented pseudonym is performed. Namely, the user has to prove her connection to that pseudonym by either performing a biometric authentication or presenting a public key certificate issued to that pseudonym and proving the possession of the corresponding private key. Al- ternatively, the identity vendor can provide a new pseudonym or accept the one suggested by the user. The identity vendor finally creates a new public key certificate and submits it to the identity proxy along with information and certificates related to identity attributes. In addition, the identity vendor can supply a number of secret keys (for symmetric encryption/decryption) encrypted using the user’s public key. If a new pseudonym is created, its description is attached to it. The pseudonym will be stored in the pseudonym pool. The identity proxy loads the new profile on the card, which stores the certificates and identity attribute information without performing any checks on them. If a new pseudonym is supplied, it is stored in the pseudonym pool. Secret keys are also decrypted and stored in the profile.

Using identity proﬁles

An open mobile identity tool implemented on the mobile phone can be used in the following scenarios:

• Identity checks. The check is performed with regard to a certain identity profile and a certain pseudonym. The user is notified about what information is requested and by whom, and can either comply with or reject the identity check request. Only the minimally required set of identity attributes is opened to the verifier. Furthermore, certain profiles can be PIN-protected: the user has to enter her PIN code before the SIM card applet will provide an identity proof.

• Digital signatures. In addition to an identity check, the veriﬁer can request a digital signature from the person. The text of the signed document is shown on the mobile phone screen. For digital signatures, a longer (e.g., 6-digit) PIN code could be used, whereas for standard identity proofs a standard 4-digit PIN is sufﬁcient, if required at all.

• Challenge responses. A service provider can request encryption of a challenge with a secret key included in a proﬁle. With NFC communication, electronic keys and other access tokens are standard use cases for this scenario.

• One-time passwords. This scenario is similar to the previous one; the only difference is that the current time is used as a challenge. The mobile phone

57 Chapter 4. Results

can therefore be used as a secure authentication token which shows a new one-time password every minute or half a minute.

Biometric authentication of the user can be easily performed, following the same method as in our single-profile identity tool. If a biometric identifier is used as a pseudonym, the corresponding biometric pattern becomes available to the identity verifier, and can be used in normal biometric authentication. For example, if facial biometrics is used, the person’s photo can be shown on a screen to the identity verifier representative, who can then compare it with the person’s face.

4.3.5 Security evaluation

Security and privacy requirements for a mobile identity tool are listed in Sect. 2.1.2. Most importantly, it should be impossible for an attacker to impersonate the rightful owner of the mobile identity tool. Moreover, the rightful owner of the tool should not be able to change the identity information stored in the tool—unless a self-issued identity profile is in question. Reading user’s identity information should be prevented, unless the user’s consent for this is given. Although the systems presented in publications III and V use the same data flow model, their security models are somewhat different. In our single-profile system, the integrity and authenticity of attribute values are only protected by the tamper resistance of the SIM card. The SIM-based applet does not have a way of checking whether the attribute values have been tampered with. Identity verifiers, in turn, have to trust statements provided by the applet, and have no other way of ensuring the authenticity of attribute values. The main security assumption here is that the attacker cannot bypass the tamper resistance protection of the SIM card to change identity attribute values. We argue that the situation concerning tamper resistance is not different from that of normal electronic identity cards. Indeed, if an attacker finds a way to tamper with the card to make controlled changes in attribute values, she can use the same way to access and alter the private key. This is normally assumed to be unacceptable by the security model of the PKI systems. The level of protection provided by modern smart cards against such attacks is sufficient for identity documents: many countries issue smart card based e-IDs. Therefore, it is prudent to assume that this level of protection is sufficient for our case as well. It must be noted that the consequences of the private key leakage here are not the same as in the case of normal electronic identity cards. Indeed, if a private key is leaked from the SIM, the attacker can forge values of any identity attributes. A private key leaked from a normal electronic identity card, on the other hand, can only be used for impersonating its rightful user, or producing digital signatures on behalf of the user. The user of a mobile identity tool can therefore be expected to have an increased motivation to break the tamper resistance protection of the SIM card. In study V, however, we used more traditional security assumptions. The protection of identity attributes does not rely only on the tamper resistance of the SIM card: it is achieved by using attribute certificates digitally signed by the

58 4.3. Open Mobile Identity identity issuer. This ensures the integrity and authenticity of identity attributes. The security assumptions here are as follows: • The attacker cannot read or modify any cryptographic keys stored on the SIM card by bypassing its tamper resistance protection. • The attacker cannot forge the identity issuer’s digital signature for a modified attribute certificate. • The attacker cannot mount a second pre-image attack on the cryptographic hash function used for masking attribute values. The difference between this and the previously described model is that identity verifiers do not have to blindly trust statements about identity attributes issued by the SIM. A security assumption common to both models is that the attacker cannot install malware on the mobile phone that can exchange messages with the SIM card. Note that protection against such attacks is provided by the implementation of SATSA-APDU: in order to communicate with the SIM, a J2ME applet must be digitally signed with a private key corresponding to a public key, a hash of which is stored on the SIM. Breaking this security assumption does not enable impersonation attacks, but can enable reading the user’s identity information without her consent. Attention must be paid to the way of showing messages on the screen of the mobile phone, and the formatting of the messages. A message that is shown on the mobile phone screen might look different from its printed version or its representation on the screens of other devices. The differences might lead to the what you see is what you sign (WYSIWYS) problem [71], which must be properly addressed. An authentication token implemented using a mobile phone has certain benefits over usual security tokens. In particular, it is easier to provide time synchronisation with the service provider, because both the identity proxy and the service provider’s authentication server can easily synchronise their clocks with the MNO. In many subscriptions this feature is enabled by default. Using mobile phones removes the need for separate hardware tokens, reducing expenditures on devices and logistical costs. Minimisation of data collection is fully implemented, as well as other security and privacy-related features. Table2 provides a comparison of our mobile identity tool with common eID tokens. In our view, the most important features of our open mobile identity tool is its privacy by minimisation of data exposure and informed user consent. Clearly, anonymous credentials systems (such as [14] or [19]) can achieve better data minimisation. However, for most daily scenarios they tend to be an overkill. Indeed, most loyalty, payment, or license scenarios are pseudonymous rather than anonymous: the user is issued with a pseudonym for a given system, and this pseudonym is later used for associating the user with their account. Privacy issues can also be reasonably taken into account in the design of such systems [29]. Without any doubt, there are cases where anonymous credentials are the best alternative (e.g., [16]); however these are more common in wide area networking rather than in proximity scenarios.

59 Chapter 4. Results

Table 2: Security features of our mobile identity tool, compared with other e-IDs.

Security and privacy features eID cards Biometric M-COMM Our passports proposal Minimization of data collection – – – Yes User consent Yes1 – Yes1 Yes Authentication and integrity Yes – Yes Yes Conﬁdentiality Yes2 – Yes3 Yes Easiness of revocation Yes4 Yes4 Yes Yes 1 Only request for all identity information can be accepted or rejected. 2 Information can be read from stolen cards. 3 Mobile network operator can always read all information. 4 Not for ofﬂine transactions.

4.4 Combining biometric authentication and privacy-enhancing technologies

When identity documents are read by electronic means, a lot of information is not only revealed, but can be copied, stored and processed without our consent. With biometric patterns revealed to identity verifiers, this becomes a serious privacy problem. Usual paper- or plastic-based documents do not have this problem: the photo of the document holder is simply shown to the verifier, and is not stored anywhere electronically. We argue that similar privacy-preserving biometric authentication (where a facial photo is used as the least intrusive and the most common and widely accepted biometrics) can be performed with the mobile phone used as an eID token. Indeed, as mobile phones have screens with resolution sufficient for showing a face photograph, the only problem is ensuring the trusted path between the store place of the certified photo and the screen. Publication IV describes how this can be achieved.

4.4.1 Biometric authentication and unlinkability The problem of combining privacy-enhancing technologies with biometric authentication is essentially in the provision of unlinkability. Indeed, if a biometric pattern of a person becomes available to identity verifiers, they can easily collude and trace this person by linking transactions with the same pattern. Clearly, this is not the only problem that arises due to such wide electronic “broadcasting” of biometrics. The patterns can be stored in various systems, and this can lead to invasive secondary market effects, function creep, the loss of autonomy, and other “Big Brother”-like scenarios (see [117, Chapter 12] for a discussion of how biometrics impacts privacy). The question is, however, whether it is really necessary to give biometric patterns into the possession of identity verifiers. If the user’s device is trusted, it can perform biometric authentication on its own, and inform the identity verifier only about the result of authentication. For example, the AXS-authentication system [9] does just that: a trusted device checks the user’s fingerprint, and

60 4.4. Combining biometric authentication and privacy-enhancing technologies

calculates a challenge response (to be used for online authentication) if the match is successful. As is shown in publication IV, similar privacy-preserving biometric authentication is possible also in face-to-face identity checks with mobile phones. If biometric patterns are not released to verifiers, unlinkability of transactions can be easier to achieve, and patterns cannot be reused by verifiers later on. In fact, only a small modification in our open mobile identity scheme is needed. As described in Sect. 4.3.4, the person’s photo is just another pseudonym stored in the pseudonym pool. Remember also that identity profiles are issued to cryptographic hashes of biometric patterns. From the identity proof, the identity verifier can check the integrity and authenticity of the hash of the photo, but does not receive the photo itself in a digital form. Now assume that both the identity verifier and the identity proxy compute a cryptographic hash of all messages exchanged between them during the identity proof protocol. We call this hash (perhaps trimmed to only a few hexadecimal digits) an identity proof fingerprint. The identity proxy can then superimpose the fingerprint on the user’s photo and show the result on the screen of the mobile phone. The identity verifier can compare the fingerprints and check whether the photo matches the user standing in front of him. In this way we can ensure that the photo comes from the identity proxy, and not from a malicious program running on the same mobile phone. This scenario is depicted in Fig. 10. Our scheme solves one particular problem: biometric patterns are no longer communicated to identity verifiers. However, other problems remain unsolved: it is still possible to link transactions using the hash of the photo. Although it would be possible to use other PETs to provide unlinkability on the protocol level (for example, using the scheme presented by Camenisch and Lysyanskaya [19]), it is hard to provide unlinkability on the transport level. Although in many wireless networks link-layer and network-layer identifiers can be randomized [11, 48, 63, 85], for NFC the situation is different. The reason is that NFC phones can be used in the NFC token emulation mode, where tokens have unique identifiers (serial numbers). Should it be possible to disable the broadcasting of this identifier, our scheme could be updated by building in a privacy-enhancing technology which provides unlinkability.

4.4.2 Trusted user interface In our scenario the screen of a hand-held device is trusted by the identity verifier to show the right photo. But is it trustworthy? Since mobile phones are built on relatively open platforms, we must also consider potential attacks on this scheme. If the attacker quickly switches from the identity proxy to another application to show the attacker’s photo instead of the proper one, he can potentially impersonate the user. This attack is prevented by the identity proof fingerprint: the attacker also has to show the correct fingerprint on the forged photo. The security architecture of J2ME uses the sandbox model, preventing applications from accessing the memory space of other applications; therefore, the attacker’s program cannot intercept data sent by the identity proxy. The fingerprint calculation includes two digital signatures made with the private keys unknown to

61 Chapter 4. Results

Figure 10: An identity proof with biometric authentication. the attacker; this essentially cuts the chances of guessing the fingerprint to 1 in 1048576, if five hexadecimal digits are used in the fingerprint. Malware with screen capture capabilities could potentially be used to make a screenshot of the identity proxy terminal at the time when it displays the user’s photo, extract the identity proof fingerprint and place it on another photo, to impersonate the legitimate user. A “fraudulent” user may wait for a second or two before showing the phone to a verifier without the latter becoming suspicious. To prevent these “screenshot attacks”, the following techniques can be used:

• Visual distortion of the identity proof ﬁngerprint (using CAPTCHA-like techniques [112], for example).

• Placing the ﬁngerprint in several random locations.

• Slight randomised distortion of the user’s photo (using Stirmark [93], for example). This is useful for preventing the attacker from analysing a captured watermarked image against a non-watermarked one, for ex-

62 4.4. Combining biometric authentication and privacy-enhancing technologies

tracting the identity proof fingerprint. The non-watermarked image could be obtained by the attacker by using collusion attacks on a number of watermarked images. With the development of mobile trusted modules it might become easier to build a trustworthy user interface on mobile phones. For example, it might become possible for an application to get an exclusive access to the screen for a fixed period of time. Using such functionality, the identity proxy can request such exclusive access for a few seconds, preventing malicious users and malicious applications from meddling with the screen. The openness of the mobile phone platform opens a way for yet another attack (Tuomas Aura is acknowledged for the idea). This is a relay attack, in which the attacker gives the real phone and the SIM to a friend and uses a modified phone himself. The modified phone has a software that emulates the identity proxy to the identity verifier’s terminal. The authentication messages are relayed using this software from the modified phone to the real phone. Any wireless connection (except NFC) can be used for this. Eventually, the real phone shows the authentic photo and the 5-digit code on its screen. The attacker’s friend reads the code and types it into another computer that relays it to the modified phone. The modified phone presents a wrong photo and the correct 5-digit code. In an optimized version, the friend could be replaced with a digital camera and optical character recognition (OCR) software that read the code from the screen of the real phone. The attack can be used for impersonating the owners of lost phones, or by users who wish to “lend” their identity for any reasons. Because the data exchange between the real and the modified phone introduces delays, the attack can be detected with distance-bounding mechanisms. However, to fully prevent the attack, the presence of the original SIM card at the scene must be ensured. This would require direct message exchange between the terminal and the SIM prior and after the biometric authentication. Although this is technically possible [40, 41], the usability of the scheme will decrease. We leave the development of countermeasures against this relay attack for future work. System software vulnerabilities also pose a threat to our scheme. For example, if the standard SATSA-APDU protection is overridden, malware can be used for accessing the SIM card and showing any photo together with the correct identity proof fingerprint. The security of the model can be improved if the identity proxy is run within a secure execution environment, and if its integrity can be measured by the identity verifier prior to performing an identity proof. Such functionality can later appear with the further development of mobile trusted modules. It would also solve the relay attack problem.

5 Conclusions

5.1 Contributions of the thesis

The main contribution of this thesis is the technology for transforming a mobile phone with a trusted tamper-resistant security element in a form of a PKI-SIM card into a flexible mobile identity management tool. The tool supports multiple identity profiles that can be used for strong mobile user authentication both in remote and face-to-face scenarios. As a result, the scheme combines ubiquitousness with user convenience and acceptance. The distinctive features of our scheme are non-repudiation and full confidentiality of transaction-related information, which allows it to be used for macro payments and for mobile banking. As a demonstration of a use case, it was shown how such authentication with a mobile phone can be used in mobile payment systems. Privacy issues are of the utmost importance in our solution, where we use the principles of informed user consent and data minimisation. Furthermore, privacy-aware biometric authentication of persons is supported. The relationship between the research hypotheses (see Sect. 3.2) and publications constituting this thesis are given in Table3 . We consider that published results provide enough evidence to the truthfulness of the hypotheses. Additional testing must be performed in field studies, which is acknowledged in Sect. 5.2. In study I, a technology for strong authentication of mobile users was designed. The technology employs the Finnish national electronic identity system. The user’s public key is stored on the SIM and is accessed by a J2ME applet called an identity proxy through the SATSA API. This data flow model is used later in publications II–IV. Furthermore, the study presents a sketch of a mobile payment system for vending machines. Publication II presents a mobile payment system in which users are authenticated by the technology developed in study I. Two payment protocols

65 Chapter 5. Conclusions

Table 3: Relationship between research hypotheses and publications.

Research hypothesis and claim Publications 1 (a) Strong authentication of mobile users can be performed by I employing a national electronic identity system and corresponding infrastructure. (b) The authentication of mobile users can be done without using I the authentication services of mobile network operators. (c) Systems that rely on such authentication can be fully open I, II, V and easy to join by any customer, mobile network operator, service provider, and financial institution. 2 (a) A national electronic identity system can be used for building III a general user and citizen identification and authentication system for access control. (b) Such a mobile identity can be securely used in many applica- III, IV tions instead of usual identification cards or passports. (c) Privacy in systems that use such a mobile identity can be III, IV higher than in systems that use usual identification cards and passports.

3 (a) A mobile phone with a security element such as the SIM card V is a suitable device for becoming a ubiquitous mobile identity management tool. (b) The tool can facilitate flexible identity proofs using chosen V identity profiles. (c) Such tool can be open to use by any identity providers and V identity verifiers.

are constructed: one for virtual POS payments, and one for real POS payments. A proof-of-concept implementation of a system for purchasing train tickets is presented, with a detailed description of the technologies involved in the implementation. In addition, the security of the mobile payment system is analysed in the scope of existing solutions. In publication III, problems of currently prevalent electronic IDs are reviewed, and a pseudonymous mobile identity tool is designed. The goal was to fix problems with privacy, using the principles of data minimisation and informed user consent. The tool runs on a mobile phone and can be used in many scenarios instead of biometric passports or electronic identity cards. Biometric authentication based on the person’s photo as the least intrusive biometric is supported. User’s identity information is securely stored on the SIM by the identity issuer, and is accessed through the identity proxy applet. An implementation of the model was prepared. When biometric authentication is done, biometric patterns are often revealed to identity verifiers. This raises a number of privacy concerns. In paper IV, a privacy-aware way of performing biometric authentication using hand-held devices is presented. The person’s photo is shown to the identity verifier on the screen of the hand-held device, while the actual identity proof is delivered

66 5.2. Limitations of the study

using NFC or other short-range communication technology. The authenticity of the photo is protected using a proof fingerprint calculated by applying a cryptographic hash function to the data exchanged by the parties. Paper V extends the mobile identity tool by adding support for multiple identity profiles. The profiles can be added in the post-issuance phase of the tool life cycle. Openness was the main principle applied in this work: identity profiles can be loaded or checked by any identity issuers or verifiers, if the user’s consent is granted for this. The proposed schemes rely on current handset technology and off-the-shelf development tools. Proof-of-concept implementations have been prepared to demonstrate this.

5.2 Limitations of the study

The studies presented in this thesis are not free from limitations. The potentiality of implementing the described solutions into use is limited by several factors. Although we have used existing hand-held device technology in all experiments, some of this technology, especially SATSA and NFC, are still only emerging. Never- theless, given the speed of mobile technology progress, the situation may change rapidly. Another limitation is the lack of infrastructure (mainly terminals) required for implementing our solutions into use. On the other hand, several big corporations have shown clear interest in the development of a short-range communication technology and applications that use it. With the further development of contactless payments using credit cards and similar tokens, the number of terminals can be expected to grow quickly. A similar change was seen recently with the introduction of chip-and-pin payments. Terminals for contactless payments are likely to be introduced in due time. They can be also used for identity proofs and, perhaps, other applications. Given the limitations described above, we were not able to run any in-ﬁeld experiments. We also have not yet considered standardisation of the presented solutions. This has to be done in cooperation with MNOs, governmental authorities and banks.

5.3 Future work

Future work on this research topic may concentrate on the following directions. Combining national PKI with mobile technology enables macro payments and mobile ﬁnancial services such as mobile banking. However, close cooperation with governmental bodies, banks, and MNOs has to be established for continuing this work. Pilot projects must be run, and standardisation issues elaborated. Identity federations-related standards could work as a starting point in this research. The new “connected” version of Java Card 3.0 could provide further possibilities for the development of user-centric identity management on hand- held devices with security elements.

67 Chapter 5. Conclusions

The mobile identity tool could be made even more flexible by combining it with solutions that store and process credentials in secure execution environments of hand-held devices (e.g., Nokia’s ObC). Trusted mobile platforms have to be further developed to provide reliable and trustworthy user interfaces. In particular, trusted applications must be able to get exclusive access to the user interface of the device for a period of time. Our privacy-aware biometric authentication idea has raised interesting requirements concerning watermarking technologies. This suggests a new potential research avenue: the development of “CAPTCHA-watermarks” for images. While most research in watermarking has focused on invisible watermarks, this water- mark should be visible. In addition, it does not need to be fragile or robust, and it may be easily removable, but the analysis of its contents should be difficult for computers. At the same time, verification of “CAPTCHA-watermarks” by humans has to be easy. The requirements substantially differ from those in normal watermarking applications, which calls for more research in watermarking. Yet another research direction is a critical examination of the susceptibility of currently available electronic identity cards to viral attacks. As was mentioned on p. 25, malicious software could potentially gain access to such cards and use them without the user’s consent. However, such possibilities have not been analysed closely enough, so further research on the topic is needed.

68 Bibliography

[1] 3rd Generation Partnership Project (3GPP). TS 11.14: Speciﬁcation of the SIM Application Toolkit (SAT) for the Subscriber Identity Module – Mobile Equipment (SIM-ME) interface, V8.17.0. Sophia Antipolis, Valbonne, France (September 2004). http://www.3gpp.org/ftp/Specs/html-info/ 1114.htm.

[2] 3rd Generation Partnership Project (3GPP). TS 03.48: Security mechanisms for SIM application toolkit; Stage 2, V8.9.0. Sophia Antipolis, Val- bonne, France (June 2005). http://www.3gpp.org/ftp/Specs/html-info/ 0348.htm

[3] Tsuyoshi Abe, Hiroki Itoh, and Kenji Takahashi. Implementing identity provider on mobile phone. In DIM ’07: Proceedings of the 2007 ACM workshop on digital identity management, New York, NY, USA. ACM (2007) 46–52. doi: 10.1145/1314403.1314412

[4] ABI Research. Twenty percent of mobile handsets will include near ﬁeld communication by 2012. London, UK (April 2007). http://www. abiresearch.com/abiprdisplay.jsp?pressid=838

[5] Tiago Alves and Don Felton. TrustZone: Integrated hardware and software security. Information Quarterly 3(4):18–24 (2004)

[6] Ross J. Anderson. Security Engineering : A Guide to Building Dependable Distributed Systems. 2 edn. Wiley Publishing, Inc. (2008)

[7] APACS, the UK payments association. Fraud abroad pushes up losses on UK cards following two-year fall. Press release (March 2008). http: //www.apacs.org.uk/2007Fraudﬁguresrelease.html

[8] N. Asokan, Phillipe A. Janson, Michael Steiner, and Michael Waidner. The state of the art in electronic payment systems. Computer 30(9):28–35 (1997). doi: 10.1109/2.612244

[9] AXSionics AG. AXS-authentication system. http://www.axsionics.com

[10] Mihir Bellare, Juan A. Garay, Ralf Hauser, Amir Herzberg, Hugo Krawczyk, Michael Steiner, Gene Tsudik, and Michael Waidner. iKP: a family of secure electronic payment protocols. In WOEC’95: Proceedings of the 1st conference on USENIX Workshop on Electronic Commerce, Berkeley, CA, USA. USENIX Association (July 1995) 7–7

[11] Alastair R. Beresford and Frank Stajano. Location privacy in pervasive computing. Pervasive Computing 2(1):46–55 (Jan-Mar 2003). doi: 10. 1109/MPRV.2003.1186725

∗ All URLs were checked on 8.2.2009. ® ∗∗ Digital Object Identiﬁer (DOI ) names can be resolved at http://www.doi.org.

69 Bibliography

[12] Fabrice Boudot. Efficient proofs that a committed number lies in an interval. In Bart Preneel, ed., Advances in Cryptology - EUROCRYPT 2000: International Conference on the Theory and Application of Cryptographic Techniques. Vol. 1807 of Lecture Notes in Computer Science. Springer-Verlag Berlin Heidelberg (2000) 431–444. doi: 10.1007/3-540-45539-6_31 [13] Fabrice Boudot. Partial revelation of certified identity. In Josep Domingo- Ferrer, David Chan, and Anthony Watson, eds., CARDIS. Vol. 180 of IFIP Conference Proceedings. Kluwer (2000) 257–272 [14] Stefan A. Brands. Rethinking Public Key Infrastructures and Digital Certifi- cates : Building in Privacy. The MIT Press, Cambridge (MA) (2000) [15] Gilles Brassard, David Chaum, and Claude Crépeau. Minimum disclosure proofs of knowledge. J. Comput. Syst. Sci. 37(2):156–189 (1988). doi: 10.1016/0022-0000(88)90005-0 [16] Ernie Brickell, Jan Camenisch, and Liqun Chen. Direct anonymous attes- tation. In CCS ’04: Proceedings of the 11th ACM conference on Computer and communications security, New York, NY, USA. ACM (2004) 132–145. doi: 10.1145/1030083.1030103 [17] Alan S. Brown, Elisabeth Bracken, Sandy Zoccoli, and King Douglas. Generating and remembering passwords. Applied Cognitive Psychology 18 (6):641–651 (2004). doi: 10.1002/acp.1014 [18] Jan Camenisch and Els Van Herreweghen. Design and implementation of the idemix anonymous credential system. In CCS ’02: Proceedings of the 9th ACM conference on computer and communications security, New York, NY, USA. ACM (2002) 21–30. doi: 10.1145/586110.586114 [19] Jan Camenisch and Anna Lysyanskaya. An efficient system for non- transferable anonymous credentials with optional anonymity revocation. In Birgit Pfitzmann, ed., Advances in Cryptology – EUROCRYPT 2001. Vol. 2045 of Lecture Notes in Computer Science. Springer (2001) 93–118. doi: 10.1007/3-540-44987-6 [20] Zhengjun Cao and Lihua Liu. Boudot’s range-bounded commitment scheme revisited. In Sihan Qing, Hideki Imai, and Guilin Wang, eds., Information and Communications Security. Vol. 4861 of Lecture Notes in Computer Science. Springer-Verlag (2008) 230–238. doi: 10.1007/ 978-3-540-77048-0_18 [21] CEN/ISSS Workshop eAuthentication. Towards an electronic ID for the European Citizen, a strategic vision. Brussels (October 2004). http: //europa.eu.int/idabc/servlets/Doc?id=19132 [22] David Chaum. Blind signatures for untraceable payments. In Advances in Cryptology - Crypto ’82. (1983) 199–203 [23] David Chaum. Security without identification: transaction systems to make big brother obsolete. Commun. ACM 28(10):1030–1044 (1985). doi: 10.1145/4372.4373

70 Bibliography

[24] Zhiqun Chen. Java Card technology for smart cards : architecture and programmer’s guide. Addison-Wesley, Boston (MA) (2000)

[25] Sebastian Clauß and Marit Kohntopp. Identity management and its support of multilateral security. Computer Networks 37(2):205–219 (October 2001). doi: 10.1016/S1389-1286(01)00217-1

[26] Commission of the European communities. Progress report on the single European electronic communications market 2007 (13th report). Commu- nication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions. Brussels, Belgium (19 March 2008). COM(2008) 153

[27] Ivan Damgård and Eiichiro Fujisaki. A statistically-hiding integer commitment scheme based on groups with hidden order. In Yuliang Zheng, ed., Advances in Cryptology - ASIACRYPT 2002: 8th International Conference on the Theory and Application of Cryptology and Information Security. Vol. 2501 of Lecture Notes in Computer Science. Springer Berlin/Heidelberg (2002) 77–85. doi: 10.1007/3-540-36178-2

[28] Ernesto Damiani, Sabrina De Capitani di Vimercati, and Pierangela Sama- rati. Managing multiple and dependable identities. IEEE Internet Comput- ing 7(6):29–37 (2003). doi: 10.1109/MIC.2003.1250581

[29] Yvo Desmedt. Position statement in RFID S&P panel: From relative security to perceived secure. In Sven Dietrich and Rachna Dhamija, eds., Financial Cryptography and Data Security, 11th International Conference, FC 2007. Vol. 4886 of Lecture Notes in Computer Science. Springer (2008) 53–56. doi: 10.1007/978-3-540-77366-5_8

[30] Rachna Dhamija, J. D. Tygar, and Marti Hearst. Why phishing works. In CHI ’06: Proceedings of the SIGCHI conference on Human Factors in computing systems, New York, NY, USA. ACM (2006) 581–590. doi: 10.1145/1124772.1124861

[31] C. Drane, M. Macnaughtan, and C. Scott. Positioning GSM telephones. IEEE Communications Magazine 36(4):46–54, 59 (1998)

[32] Saar Drimer and Steven J. Murdoch. Keep your enemies close: Distance bounding against smartcard relay attacks. In 16th USENIX Security Sym- posium. (2007) 87–102

[33] Saar Drimer, Steven J. Murdoch, and Ross Anderson. Thinking inside the box: System-level failures of tamper prooﬁng. In 2008 IEEE Symposium on Security and Privacy, Los Alamitos, CA, USA. IEEE Computer Society (2008) 281–295. doi: 10.1109/SP.2008.16

[34] Jan-Erik Ekberg, N. Asokan, Kari Kostiainen, Pasi Eronen, Aarne Rantala, and Aishvarya Sharma. OnBoard Credentials platform design and implementation. Technical report NRC-TR-2008-001, Nokia Research Center (January 2008). http://research.nokia.com/ﬁles/NRCTR2008001.pdf

71 Bibliography

[35] European Telecommunications Standards Institute (ETSI). TS 102 203 V1.1.1. Mobile commerce (M-COMM); mobile signatures; business and functional requirements. Technical speciﬁcation (May 2003). http:// portal.etsi.org/docbox/EC_Files/EC_Files/ts_102204v010104p.pdf

[36] European Telecommunications Standards Institute (ETSI). TS 102 204 V1.1.4. Mobile commerce (M-COMM); mobile signature service; web service interface. Technical speciﬁcation (August 2003). http://portal. etsi.org/docbox/EC_Files/EC_Files/ts_102204v010104p.pdf

[37] European Telecommunications Standards Institute (ETSI). TS 102 206 V1.1.3. Mobile commerce (M-COMM); mobile signature service; security framework. Technical speciﬁcation (August 2003). http://portal.etsi.org/ docbox/EC_Files/EC_Files/tr_102206v010103p.pdf

[38] European Telecommunications Standards Institute (ETSI). TS 102 207 V1.1.3. Mobile commerce (M-COMM); mobile signature service; speci- ﬁcations for roaming in mobile signature services. Technical speciﬁca- tion (August 2003). http://portal.etsi.org/docbox/EC_Files/EC_Files/ts_ 102207v010103p.pdf

[39] European Telecommunications Standards Institute (ETSI). TS 133 221 V7.1.0. Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Generic Authentication Architecture (GAA); Support for subscriber certiﬁcates (3GPP TS 33.221 version 7.1.0 Release 7). Technical speciﬁcation (January 2008). http: //www.3gpp.org/ftp/Specs/html-info/33221.htm

[40] European Telecommunications Standards Institute (ETSI). TS 102 622 V7.0.0. Smart Cards; UICC - Contactless Front-end (CLF) interface; Host Controller Interface (HCI) (Release 7). Technical speciﬁcation (February 2008). http://webapp.etsi.org/action%5CPU/20080304/ts_ 102622v070000p.pdf

[41] European Telecommunications Standards Institute (ETSI). TS 102 613 V7.1.0. Smart Cards; UICC - Contactless Front-end (CLF) interface; Part 1: Physical and data link layer characteristics (Release 7). Technical speciﬁcation (February 2008)

[42] S. Farrell and R. Housley. An Internet attribute certiﬁcate proﬁle for authorization. Network Working Group, Request for Comments 3281 (April 2002). http://www.ietf.org/rfc/rfc3281.txt

[43] Federal Financial Institutions Examination Council. Authentication in an Internet banking environment (October 2005). http://www.fﬁec.gov/ pdf/authentication_guidance.pdf

[44] FIDIS - “Future of Identity in the Information Society”. Budapest declaration on machine readable travel documents (MRTDs) (September 2006). http://www.fidis.net/fileadmin/fidis/press/budapest_declaration_ on_MRTD.en.20061106.pdf

72 Bibliography

[45] Bundesamt für Sicherheit in der Informationstechnik. Advanced security mechanisms for machine readable travel documents – Extended Access Control (EAC), Password Authenticated Connection Establishment (PACE), and Restricted Identiﬁcation (RI). Technical report BSI-TR 03110 (October 2008)

[46] Gartner Inc. Gartner says number of identity theft victims has increased more than 50 percent since 2003. Stamford, Conn. (March 2007). http: //www.gartner.com/it/page.jsp?id=501912

[47] Shaﬁ Goldwasser, Silvio Micali, and Charles Rackoff. The knowledge complexity of interactive proof-systems. In STOC ’85: Proceedings of the seventeenth annual ACM symposium on Theory of computing, New York, NY, USA. ACM (1985) 291–304. doi: 10.1145/22145.22178

[48] Marco Gruteser and Dirk Grunwald. Enhancing location privacy in wireless LAN through disposable interface identiﬁers: A quantitative analysis. Mobile Networks and Applications 10(3):315–325 (June 2005). doi: 10.1007/s11036-005-6425-1

[49] GSM Association. http://www.gsmworld.com/

[50] Gerhard P. Hancke. A practical relay attack on ISO 14443 proximity cards. Manuscript (February 2005). http://www.rﬁdblog.org.uk/ hancke-rﬁdrelay.pdf

[51] Gerhard P. Hancke. Practical attacks on proximity identiﬁcation systems (short paper). In 2006 IEEE Symposium on Security and Privacy. IEEE Computer Society (2006) 328–333. doi: 10.1109/SP.2006.30

[52] Gerhard P. Hancke and Markus G. Kuhn. An RFID distance bounding protocol. In SecureComm 2005. First International Conference on Security and Privacy for Emerging Areas in Communications Networks, Athens, Greece. IEEE Computer Society (5–9 September 2005) 67–73. doi: 10. 1109/SECURECOMM.2005.56

[53] Marko Hassinen, Konstantin Hyppönen, and Keijo Haataja. An open, PKI-based mobile payment system. In Günter Müller, ed., Emerging Trends in Information and Communication Security, ETRICS 2006. Vol. 3995 of Lecture Notes in Computer Science. Springer-Verlag Berlin Heidelberg (2006) 86–100

[54] Amir Herzberg. Payments and banking with mobile personal devices. Commun. ACM 46(5):53–58 (2003). doi: 10.1145/769800.769801

[55] Martin Hlaváˇc and Tomáš Rosa. A note on the relay attacks on e- passports: The case of Czech e-passports. Cryptology ePrint Archive, Report 2007/244 (2007). http://eprint.iacr.org/2007/244.pdf

[56] Jaap-Henk Hoepman, Engelbert Hubbers, Bart Jacobs, Martijn Oostdijk, and Ronny Schreur. Crossing borders: Security and privacy issues of the

73 Bibliography

European e-passport. In Hiroshi Yoshiura, Kouichi Sakurai, Kai Rannen- berg, Yuko Murayama, and Shinichi Kawamura, eds., Advances in Infor- mation and Computer Security. First International Workshop on Security, IWSEC 2006. Vol. 4266 of Lecture Notes in Computer Science. Springer- Verlag Berlin Heidelberg (2006) 152–167. doi: 10.1007/11908739_11 [57] IBM Zurich Research Laboratory. JCOP Tools 3.0 (Eclipse plugin). Techni- cal brief, revision 1.0. ftp://ftp.software.ibm.com/software/pervasive/ info/JCOPTools3Brief.pdf [58] Roberto Ierusalimschy. Programming in Lua. 2 edn. Lua.Org, Rio de Janeiro (2006) [59] International Civil Aviation Organization (ICAO). Doc 9303. Part 1 – Machine Readable Passport. Sixth edition (2006) [60] Blake Ives, Kenneth R. Walsh, and Helmut Schneider. The domino effect of password reuse. Commun. ACM 47(4):75–78 (2004). doi: 10.1145/ 975817.975820 [61] Java Community Process. Contactless Communication API, JSR 257, v. 1.0. Nokia Corporation, Espoo, Finland (2 October 2006). http://www.jcp. org/en/jsr/detail?id=257 [62] Java Community Process. Security and Trust Services API (SATSA) for Java™ 2 Platform, Micro Edition, v. 1.0. Sun Microsystems, Inc., Santa Clara, CA, USA (17 July 2004). http://www.jcp.org/en/jsr/detail?id=177 [63] Tao Jiang, Helen J. Wang, and Yih-Chun Hu. Preserving location privacy in wireless LANs. In MobiSys ’07: Proceedings of the 5th international conference on Mobile systems, applications and services, New York, NY, USA. ACM (2007) 246–257. doi: 10.1145/1247660.1247689 [64] Audun Jøsang, John Fabre, Brian Hay, James Dalziel, and Simon Pope. Trust requirements in identity management. In ACSW Frontiers ’05: Proceedings of the 2005 Australasian workshop on grid computing and e- research, Darlinghurst, Australia. Australian Computer Society, Inc. (2005) 99–108 [65] Audun Jøsang, Muhammed Al Zomai, and Suriadi Suriadi. Usability and privacy in identity management architectures. In ACSW ’07: Proceed- ings of the ﬁfth Australasian symposium on ACSW frontiers, Darlinghurst, Australia. Australian Computer Society, Inc. (2007) 143–152 [66] A. Juels, D. Molnar, and D. Wagner. Security and privacy issues in e- passports. In SecureComm 2005. First International Conference on Security and Privacy for Emerging Areas in Communications Networks, Athens, Greece. IEEE Computer Society (5–9 September 2005) 74–88 [67] Gyorgy Kalman and Josef Noll. SIM as secure key storage in communication networks. In Cosmin Dini, Mischa Dohler, Mohamed Eltoweissy, Teng Rui, and Knud Erik Skouby, eds., Third International Conference on Wireless

74 Bibliography

and Mobile Communications (ICWMC ’07), Gosier, Guadeloupe. IEEE Com- puter Society Press (March 2007) 55–55. doi: 10.1109/ICWMC.2007.82 [68] Stamatis Karnouskos. Mobile payment: A journey through existing procedures and standardization initiatives. IEEE Communication Surveys 6(4): 44–66 (2004). http://www.comsoc.org/livepubs/surveys/public/2004/ oct/pdf/KARNOUSKOS.pdf [69] Nina Kreyer, Key Pousttchi, and Klaus Turowski. Characteristics of mobile payment procedures. In Zakaria Maamar, Wathiq Mansoor, and Willem-Jan van den Heuvel, eds., First International Workshop on M- Services - Concepts, Approaches, and Tools. Vol. 61 of CEUR Workshop Proceedings, Lyon, France. Sun SITE Central Europe (CEUR) (June 26 2002). http://SunSITE.Informatik.RWTH-Aachen.DE/Publications/ CEUR-WS/Vol-61/paper1.pdf [70] P. Laitinen, P. Ginzboorg, N. Asokan, S. Holtmanns, and V. Niemi. Ex- tending cellular authentication as a service. In The First IEE International Conference on Commercialising Technology and Innovation, London, UK. IEEE (14-15 September 2005) 0_90–D2/4. doi: 10.1049/ic:20050605 [71] Peter Landrock and Torben Pedersen. WYSIWYS? – what you see is what you sign? Information Security Technical Report 3(2):55–61 (1998). doi: 10.1016/S0167-4048(98)80005-8 [72] Mikko Lehtonen, Florian Michahelles, Thorsten Staake, and Elgar Fleisch. Strengthening the security of machine readable documents by combining RFID and optical memory devices. In Antonio Maña and Volkmar Lotz, eds., Developing Ambient Intelligence. Springer Paris (2006) 77–92. doi: 10.1007/978-2-287-47610-5_6 [73] Xavier Leroy. Java bytecode verification: Algorithms and formalizations. Journal of Automated Reasoning 30(3):235–269 (May 2003). doi: 10. 1023/A:1025055424017 [74] Jiangtao Li and Ninghui Li. A construction for general and efficient oblivious commitment based envelope protocols. In Peng Ning, Sihan Qing, and Ninghui Li, eds., Information and Communications Security. Vol. 4307 of Lecture Notes in Computer Science. Springer-Verlag Berlin Heidelberg (2006) 122–138. doi: 10.1007/11935308_10 [75] Liberty Alliance Project. Liberty Alliance ID-FF 1.2 specifications (Decem- ber 2007). http://www.projectliberty.org/liberty/specifications__1 [76] Anna Lysyanskaya, Ronald Rivest, Amit Sahai, and Stefan Wolf. Pseudonym systems. In Howard Heys and Carlisle Adams, eds., Selected Areas in Cryptography. Vol. 1758 of Lecture Notes in Computer Science. Springer (2000) 184–199. doi: 10.1007/3-540-46513-8_14 [77] Gerald Madlmayr, Oliver Dillinger, Josef Langer, Christoph Schaffer, Chris- tian Kantner, and Josef Scharinger. The benefit of using SIM application toolkit in the context of near field communication applications. In Sixth

75 Bibliography

International Conference on the Management of Mobile Business (ICMB 2007), Los Alamitos, CA, USA. IEEE Computer Society (2007) 5. doi: 10.1109/ICMB.2007.62 [78] Neil A. McEvoy. e-ID as a public utility. Consult Hyperion, Guilford, UK (May 2007). http://www.chyp.com/PubWebFiles/opinion/eid_as_public_ utility.pdf [79] David McKitterick and Jim Dowling. State of the art review of mobile payment technology. Technical Report TCD-CS-2003-24, Dept. of Computer Science, Trinity College, Dublin (2003) [80] Santosh K. Misra and Nilmini Wickamasinghe. Security of a mobile transaction: A trust model. Electronic Commerce Research 4(4):359–372 (October 2004). doi: 10.1023/B:ELEC.0000037082.39182.3a [81] Jean Monnerat, Serge Vaudenay, and Martin Vuagnoux. About machine- readable travel documents – privacy enhancement using (weakly) non- transferable data authentication. In Proc. of the RFID Security Workshop. (2007). http://www.rfidsec07.etsit.uma.es/slides/papers/paper-11.pdf [82] Günter Müller and Sven Wohlgemuth. Study on mobile identity management. FIDIS - Future of Identity in the Information Society, deliver- able 3.3 (May 2005). http://www.fidis.net/fileadmin/fidis/deliverables/ fidis-wp3-del3.3.study_on_mobile_identity_management.pdf [83] M Myers, A Malpani, S Galperin, and C Adams. X.509 Internet public key infrastructure online certificate status protocol – OCSP. Network Working Group, Request for Comments 2560 (June 1999). http://tools.ietf.org/ html/rfc2560 [84] Arun Nanda. Identity selector interoperability profile v1.0. Mi- crosoft Corporation (April 2007). http://download.microsoft. com/download/1/1/a/11ac6505-e4c0-4e05-987c-6f1d31855cd2/ Identity-Selector-Interop-Profile-v1.pdf [85] Thomas Narten, Richard Draves, and Suresh Krishnan. Privacy extensions for stateless address autoconfiguration in IPv6. Network Working Group, Request for Comments 4941 (September 2007). http://tools.ietf.org/ html/rfc4941 [86] E.W.T. Ngai and A. Gunasekaran. A review for mobile commerce research and applications. Decision Support Systems 43(1):3–15 (February 2007). doi: 10.1016/j.dss.2005.05.003 [87] Josef Noll, Juan Carlos Lopez Calvet, and Kjell Myksvoll. Admittance services through mobile phone short messages. In International Conference on Wireless and Mobile Communications (ICWMC) 2006. IEEE (July 29-31 2006) 77–77. doi: 10.1109/ICWMC.2006.17 [88] NTT DoCoMo. What’s “Osaifu-Keitai”? http://www.nttdocomo.co.jp/ english/service/osaifu/

76 Bibliography

[89] Magnus Nystrom and Burt Kaliski. PKCS #10: Certification request syntax specification, version 1.7. Network Working Group, Request for Comments 2986 (November 2000). http://tools.ietf.org/html/rfc2986 [90] Jan Ondrus and Yves Pigneur. An assessment of NFC for future mobile payment systems. In Sixth International Conference on the Management of Mobile Business (ICMB 2007), Los Alamitos, CA, USA. IEEE Computer Society (2007) 43–49. doi: 10.1109/ICMB.2007.9 [91] OpenID Foundation. OpenID authentication 2.0 - final (December 5 2007). http://openid.net/specs/openid-authentication-2_0.html [92] Giuseppe Persiano and Ivan Visconti. An efficient and usable multi- show non-transferable anonymous credential system. In A Juels, ed., Financial Cryptography. Vol. 3110. IFCA/Springer (2004) 196–211. doi: 10.1007/b98935 [93] Fabien A. P. Petitcolas, Martin Steinebach, Frederic Raynal, Jana Dittmann, Caroline Fontaine, and Nazim Fates. Public automated web-based evaluation service for watermarking schemes: StirMark benchmark. In Ping W. Wong and Edward J. Delp III, eds., Security and watermarking of multime- dia contents III. Vol. 4314(1) of SPIE proc. ser., San Jose, CA, USA. SPIE (2001) 575–584. doi: 10.1117/12.435442 [94] Andreas Pfitzmann. Multilateral security: Enabling technologies and their evaluation. In Günter Müller, ed., Emerging Trends in Information and Communication Security, ETRICS 2006. Vol. 3995 of Lecture Notes in Computer Science. Springer-Verlag Berlin Heidelberg (June 2006) 1–13 [95] Andreas Pfitzmann and Marit Hansen. Anonymity, unlinkability, unde- tectability, unobservability, pseudonymity, and identity management – a consolidated proposal for terminology. version v0.31 (February 15 2008). http://dud.inf.tu-dresden.de/Anon_Terminology.shtml [96] Mikko Pirinen. Adopting multi-application smart cards: required changes in technology and infrastructure. Master’s Thesis, Department of Com- puter Science, University of Kuopio (March 2007). (in Finnish) [97] Population Register Centre of Finland. What is the citizen certificate? Helsinki, Finland (5 August 2005). http://www.fineid.fi/vrk/fineid/home. nsf/en/products [98] Wolfgang Rankl and Wolfgang Effing. Smart Card Handbook. 3 edn. John Wiley & Sons (2003) [99] George Roussos, Don Peterson, and Uma Patel. Mobile identity management: An enacted view. Int. J. Electron. Commerce 8(1):81–100 (2003) [100] Stefan Santesson, Tim Polk, Petra Barzin, and Magnus Nystrom. Internet X.509 public key infrastructure qualified certificates profile. Network Working Group, Request for Comments 3039 (January 2001). http: //tools.ietf.org/html/rfc3039

77 Bibliography

[101] Tom Scavo and Scott Cantor. Shibboleth architecture : Technical overview, working draft 02 (June 2005). http://shibboleth.internet2.edu/docs/ draft-internet2-shibboleth-arch-latest.pdf [102] William Sirett, John MacDonald, Keith Mayes, and Konstantinos Markan- tonakis. Design, installation and execution of a security agent for mobile stations. In Daniel Díaz Sánchez, ed., Smart Card Research and Advanced Applications. Vol. 3928 of Lecture Notes in Computer Science. Springer- Verlag Berlin Heidelberg (2006) 1–15. doi: 10.1007/11733447_1 [103] Jay Srage and Jérôme Azema. M-shield™ mobile security technology— making wireless secure. Texas Instruments white paper (2005). http: //focus.ti.com/pdfs/wtbu/ti_mshield_whitepaper.pdf [104] L Srivastava. Mobile phones and the evolution of social behaviour. Be- haviour and Information Technology 24(2):111–129 (March-April 2005). doi: 10.1080/01449290512331321910 [105] The European Parliament and the Council of the European Union. Directive 1999/93/EC of the European Parliament and of the Coun- cil of 13 December 1999 on a Community framework for electronic signatures. Ofﬁcial Journal L 013, pp. 0012–0020 (January 2000). http://europa.eu/scadplus/leg/en/lvb/l24118.htm [106] The Legion of the Bouncy Castle. Java cryptography APIs. http://www. bouncycastle.org/java.html [107] The Royal Academy of Engineering. Dilemmas of privacy and surveillance : Challenges of technological change. Published by The Royal Academy of Engineering, London, UK (March 2007). http://www.raeng.org.uk/ policy/reports/pdf/dilemmas_of_privacy_and_surveillance_report.pdf [108] Kerry Thompson. A security review of the ASB bank NetCode authentication system (2005). http://www.crypt.gen.nz/papers/asb_netcode.html [109] Trusted Computing Group. TCG mobile trusted module spec- iﬁcation, version 1.0, revision 1. TCG published (12 June 2007). https://www.trustedcomputinggroup.org/specs/mobilephone/ tcg-mobile-trusted-module-1.0.pdf [110] Aphrodite Tsalgatidou and Evaggelia Pitoura. Business models and transactions in mobile electronic commerce: requirements and properties. Computer Networks 37(2):221–236 (October 2001). doi: 10.1016/ S1389-1286(01)00216-X [111] Y.-M. Tseng. GPRS/UMTS-aided authentication protocol for wireless LANs. IEE Proceedings - Communications 153(6):810–817 (December 2006). doi: 10.1049/ip-com:20050366 [112] Luis von Ahn, Manuel Blum, Nicholas J. Hopper, and John Langford. CAPTCHA: Using hard AI problems for security. In Eli Biham, ed., Advances in Cryptology — EUROCRYPT 2003. Vol. 2656 of Lecture Notes in Computer

78 Bibliography

Science. Springer-Verlag (2003) 294–311. doi: 10.1007/3-540-39200-9_ 18

[113] S Warren and L Brandeis. The right to privacy. Harvard Law Rev. 4(5): 193–200 (1890) [114] Alan F. Westin. Privacy and Freedom. Atheneum, New York, NY (1967) [115] Marc Witteman. Attacks on digital passports. Talk at the What The Hack conference (July 2005). http://wiki.whatthehack.org/images/2/ 28/WTH-slides-Attacks-on-Digital-Passports-Marc-Witteman.pdf [116] S. Wohlgemuth, U. Jendricke, D. Gerd tom Markotten, F. Dorner, and G. Müller. Sicherheit und benutzbarkeit durch identitätsmanagement. In D. Spath and K. Haasis, eds., Aktuelle Trends in der Softwareforschung - Tagungsband zum doIT-Forschungstag, Stuttgart. IRB Verlag (2003) 241– 260 (in German) [117] John D. Woodward, Jr., Nicholas M. Orlans, and Peter T. Higgins. Biomet- rics. McGraw-Hill/Osborne, New York (2003)

79 Kuopio University Publications H. Business and Information technology

H 1. Pasanen, Mika. In Search of Factors Affecting SME Performance: The Case of Eastern Finland. 2003. 338 p. Acad. Diss.

H 2. Leinonen, Paula. Automation of document structure transformations. 2004. 68 p. Acad. Diss.

H 3. Kaikkonen, Virpi. Essays on the entrepreneurial process in rural micro firms. 2005. 130 p. Acad. Diss.

H 4. Honkanen, Risto. Towards Optical Communication in Parallel Computing. 2006. 80 p. Acad. Diss.

H 5. Laukkanen, Tommi. Consumer Value Drivers in Electronic Banking. 2006. 115 p. Acad. Diss.

H 6. Mykkänen, Juha. Specification of reusable integration solutions in health information systems. 2006. 88 p. Acad. Diss.

H 7. Huovinen, Jari. Tapayrittäjyys – tilannetekijät toiminnan taustalla ja yrittäjäkokemuksen merkitys yritystoiminnassa. 2007. 277 p. Acad. Diss.

H 8. Päivinen, Niina. Scale-free Clustering: A Quest for the Hidden Knowledge. 2007. 57 p. Acad. Diss.

H 9. Koponen, Timo. Evaluation of maintenance processes in open source software projects through defect and version management systems. 2007. 92 p. Acad. Diss.

H 10. Hassinen, Marko. Studies in mobile security. 2007. 58 p. Acad. Diss.

H 11. Jäntti, Marko. Difficulties in managing software problems and defects. 2008. 61 p. Acad. Diss.

H 12. Tihula, Sanna. Management teams in managing succession: learning in the context of family-owned SMEs. 2008. 237 p. Acad. Diss.