WPAC_dissertation

INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA

Departamento de Engenharia de Electrónica e Telecomunicações e de Computadores

Dispositivos Móveis no Pagamento de Serviços e

Pedro Miguel Alves Henriques

Dissertação de natureza científica realizada para obtenção do grau deMestre em Engenharia Informática e

Orientadores: Professor-

Júri: Presidente: Coordenador do Mestrado, ISELVogais:

Professor-adjunto Mestre Jorge Sal

INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA

Departamento de Engenharia de Electrónica e Telecomunicações e de


Controlo de Acessos

Pedro Miguel Alves Henriques

(Bacharel)

Dissertação de natureza científica realizada para obtenção do grau deMestre em Engenharia Informática e de Computadores

(Documento Provisório)

-coordenador António Luís Freixo Guedes Osório, ISEL

Coordenador do Mestrado, ISEL

adjunto Doutor Ricardo André Fernandes Costa, ESTGMestre Jorge Sales Gomes, Brisa

Novembro de 2009

Departamento de Engenharia de Electrónica e Telecomunicações e de


Dissertação de natureza científica realizada para obtenção do grau de de Computadores

Osório, ISEL

Ricardo André Fernandes Costa, ESTGF

2 Table of Contents

This page is intentionally left blank

3 Table of Contents

Table of Contents

Abstract ............................................................................................................................................................................ 9

Resumo ........................................................................................................................................................................... 10

Introduction .................................................................................................................................................................... 13

Roadmap .................................................................................................................................................................... 15

State of Art ..................................................................................................................................................................... 16

Mobile Payment and Access Control ......................................................................................................................... 16

Payment Solutions ................................................................................................................................................. 16

Access Control Solutions ........................................................................................................................................ 19

Summary ................................................................................................................................................................ 19

Mobile Devices ........................................................................................................................................................... 20

Types and availability ............................................................................................................................................. 20

Mobile phones ....................................................................................................................................................... 20

Operating Systems ................................................................................................................................................. 22

Health issues .......................................................................................................................................................... 23

Wireless Communication ........................................................................................................................................... 23

Mobile Network Telecommunication .................................................................................................................... 23

Short-Range Wireless Communication Technologies ............................................................................................ 24

Security....................................................................................................................................................................... 27

Security Threats and Risks ..................................................................................................................................... 28

Security Properties ................................................................................................................................................. 31

Cryptography ..................................................................................................................................................... 32

Security Solutions .................................................................................................................................................. 36

WPAC Architecture ......................................................................................................................................................... 38

Challenges .................................................................................................................................................................. 38

Usage scenarios .......................................................................................................................................................... 38

Merchant attendance ............................................................................................................................................ 41

Payment amount ................................................................................................................................................... 41

Architecture ............................................................................................................................................................... 41

4 Table of Contents

Roles....................................................................................................................................................................... 41

Relationships .......................................................................................................................................................... 43

Purchase Protocol .................................................................................................................................................. 44

Clearing Protocol.................................................................................................................................................... 46

Lifecycle ...................................................................................................................................................................... 46

Software agent lifecycle ......................................................................................................................................... 47

Payment phases ..................................................................................................................................................... 47

Technology Stack ........................................................................................................................................................ 48

Communication layer ............................................................................................................................................. 48

Contract layer ........................................................................................................................................................ 48

Session layer .......................................................................................................................................................... 49

Application layer .................................................................................................................................................... 49

Dependability ............................................................................................................................................................. 49

WPAC Dynamic risk assessment ..................................................................................................................................... 52

Risk categories............................................................................................................................................................ 53

Low Risk ................................................................................................................................................................. 53

Normal Risk ............................................................................................................................................................ 54

Increased Risk ........................................................................................................................................................ 54

High Risk................................................................................................................................................................. 54

Very High Risk ........................................................................................................................................................ 54

Prohibitive Risk ...................................................................................................................................................... 54

Security credentials .................................................................................................................................................... 54

PIN .......................................................................................................................................................................... 55

Password ................................................................................................................................................................ 55

Voice analysis ......................................................................................................................................................... 56

Iris/face recognition ............................................................................................................................................... 56

Risk factors ................................................................................................................................................................. 56

Payment amount ................................................................................................................................................... 57

Payment repetition ................................................................................................................................................ 58

Time and Place ....................................................................................................................................................... 58

5 Table of Contents

WPAC Security ................................................................................................................................................................ 65

Cryptographic algorithms ........................................................................................................................................... 65

Public-Key Infrastructure ........................................................................................................................................... 65

Secure communication channel ................................................................................................................................. 67

Security properties................................................................................................................................................. 67

Protocol overview .................................................................................................................................................. 68

Messages ............................................................................................................................................................... 69

Secure software agent ............................................................................................................................................... 73

Denial-of-Service ........................................................................................................................................................ 74

WPAC Implementation ................................................................................................................................................... 75

Software packages ..................................................................................................................................................... 75

Libraries ................................................................................................................................................................. 75

Runtime environment ............................................................................................................................................ 76

Purchase Web Service ................................................................................................................................................ 76

Data Model ............................................................................................................................................................ 77

SOAP Messages ...................................................................................................................................................... 77

Bluetooth Binding .................................................................................................................................................. 78

Security Tokens ...................................................................................................................................................... 78

Bluetooth Discovery ................................................................................................................................................... 78

Inquiry time and device discovery ......................................................................................................................... 78

Service search ........................................................................................................................................................ 80

Friendly name search ............................................................................................................................................. 81

Same Bluetooth address ........................................................................................................................................ 82

Connection caching ................................................................................................................................................ 82

Conclusion .............................................................................................................................................................. 83

Cryptographic operations benchmark ....................................................................................................................... 83

Symmetric-key operations ..................................................................................................................................... 83

Asymmetric-key operations ................................................................................................................................... 84

Digital Signatures ................................................................................................................................................... 85

Conclusions ..................................................................................................................................................................... 87

6 Table of Contents

Strengths .................................................................................................................................................................... 87

Weaknesses ................................................................................................................................................................ 87

Opportunities ............................................................................................................................................................. 88

Threats ....................................................................................................................................................................... 88

Future Work ............................................................................................................................................................... 88

Acronyms and abbreviations .......................................................................................................................................... 89

References ...................................................................................................................................................................... 90

Appendix ......................................................................................................................................................................... 95

Purchase Protocol WSDL ............................................................................................................................................ 95

Table of Figures

Figure 1 – Electronic payment scenario overview .......................................................................................................... 14

Figure 2 – Access control scenario overview .................................................................................................................. 15

Figure 3 – Ways to use PayPal Mobile ............................................................................................................................ 16

Figure 4 – P2P-Paid usage scenario ................................................................................................................................ 17

Figure 5 – SET actors ....................................................................................................................................................... 18

Figure 6 – M-Ticket detail ............................................................................................................................................... 19

Figure 7 – Devices mobility and availability .................................................................................................................... 20

Figure 8 – Mobile phone penetration rate in Portugal ................................................................................................... 21

Figure 9 – Mobile phones manufacturers’ Portuguese market share in February 2009 ................................................ 21

Figure 10 – Bluetooth stack protocol ............................................................................................................................. 25

Figure 11 – Mobile Communication Technologies availability on Nokia phones ........................................................... 27

Figure 12 – Security risk assessment and management matrix ..................................................................................... 28

Figure 13 – Digital Signature algorithm .......................................................................................................................... 34

Figure 14 – Public key infrastructure .............................................................................................................................. 35

Figure 15 – Supermarket payment scenario................................................................................................................... 39

Figure 16 – Vending machine payment scenario ........................................................................................................... 39

Figure 17 – Car parking payment scenario ..................................................................................................................... 40

Figure 18 – Street vendor payment scenario ................................................................................................................. 40

Figure 19 – Gas station payment scenario ..................................................................................................................... 40

Figure 20 – WPAC Roles .................................................................................................................................................. 42

Figure 21 – WPAC Relationships ..................................................................................................................................... 43

Figure 22 – Client-Merchant Purchase Protocol ............................................................................................................. 44

7 Table of Contents

Figure 23 – Client-POS Purchase Protocol ...................................................................................................................... 45

Figure 24 – Clearing Protocol ......................................................................................................................................... 46

Figure 25 – M-payment solution lifecycle ...................................................................................................................... 47

Figure 26 – Technology Stack ......................................................................................................................................... 48

Figure 27 – Client-Merchant Purchase Alternative Protocol .......................................................................................... 50

Figure 28 – Risk Levels .................................................................................................................................................... 53

Figure 29 – Security credentials and risk levels .............................................................................................................. 55

Figure 30 – Risk value calculation ................................................................................................................................... 57

Figure 31 – Payment amount division ............................................................................................................................ 57

Figure 32 – Risk table structure ...................................................................................................................................... 64

Figure 33 – WPAC PKI ..................................................................................................................................................... 65

Figure 34 – WPAC registration authority ........................................................................................................................ 66

Figure 35 – Secure communication protocol overview .................................................................................................. 68

Figure 36 – Security tokens exchange ............................................................................................................................ 69

Figure 37 – Client Hello message .................................................................................................................................... 70

Figure 38 – Send Merchant Hello message .................................................................................................................... 70

Figure 39 – Receive Merchant Hello message ................................................................................................................ 71

Figure 40 – Send message .............................................................................................................................................. 72

Figure 41 – Receive message .......................................................................................................................................... 72

Figure 42 – WPAC software packages ............................................................................................................................ 76

Figure 43 – Purchase Protocol data model ..................................................................................................................... 77

Figure 44 – Purchase Protocol WSDL .............................................................................................................................. 78

Figure 45 – Bluetooth inquiry time ................................................................................................................................. 79

Figure 46 – Bluetooth single device discovery time ....................................................................................................... 79

Figure 47 – Bluetooth several devices discovery time ................................................................................................... 79

Figure 48 – Normal Bluetooth Discovery ........................................................................................................................ 80

Figure 49 – Bluetooth Discovery by Friendly Name ....................................................................................................... 81

Figure 50 – Bluetooth device name discovery time ....................................................................................................... 82

Figure 51 – Mean Symmetric cipher engines encryption time ....................................................................................... 84

Figure 52 – Mean symmetric key size encryption time .................................................................................................. 84

Figure 53 – Mean symmetric cipher data size encryption time ..................................................................................... 84

Figure 54 – Mean RSA Encryption time .......................................................................................................................... 85

Figure 55 – Mean RSA Decryption time .......................................................................................................................... 85

Figure 56 – Mean RSA Signature time ............................................................................................................................ 86

Figure 57 – Mean Digital Signature engines sign time ................................................................................................... 86

8 Table of Contents

Table of Tables

Table 1 – Short-range wireless communication standards ............................................................................................ 26

Table 2 – Cryptographic algorithms and security properties ......................................................................................... 35

Table 3 – Encryption algorithms application .................................................................................................................. 35

Table 4 – Risk levels values interval ................................................................................................................................ 53

Table 5 – Payment types and risk points ........................................................................................................................ 58

Table 6 – Daily threshold and risk points ........................................................................................................................ 58

Table 7 – Time periods resolution and combinations number ....................................................................................... 59

Table 8 – Countries postal codes format ........................................................................................................................ 60

Table 9 – Postal codes combinations number ................................................................................................................ 61

Table 10 – Portugal postal regions and number of assigned codes ............................................................................... 62

Table 11 – Area code and time period combinations ..................................................................................................... 62

Table 12 – Risk table sizes and download time .............................................................................................................. 62

Table 13 – Risk table example ........................................................................................................................................ 64

Table of Equations

Equation 1 – Risk assessment formula ........................................................................................................................... 64

9 Abstract

Abstract

The swift evolution of mobile devices and wireless communications has transformed the ordinary mobile phone into

a powerful computing device. The need to be permanently connected has increased the dependence of this device,

which is seen as a commodity and carried by the majority of people in urban environment. The ubiquity and

computing capacity of mobile phones increase the interest in the development of wireless services. Mobile phones

may soon become an active element in daily tasks, serving as a payment and access control tool, thus providing new

interfaces for existing services.

The interest shown by stakeholders led to the appearance of several mobile services solutions, which answer to

specific situations and are typically based on closed specifications. The definition of a generic, open and

interoperable architecture is necessary for mobile services widespread adoption. Most wireless payment solutions

rely on mobile network communications, which implies communication costs in all payment transactions and

therefore may have a limited acceptance by clients.

This dissertation proposes and validates an open architecture for payment and access control based on mobile

devices known as WPAC (Wireless Payment and Access Control). This specification uses industrial patterns and

orchestrates security and communication protocols under a web service contract, thus following the Service

Oriented Architecture paradigm. The proof of concept is achieved with the construction of a prototype and tests

realization.

The WPAC architecture enables payments with low operational cost and dynamic risk assessment, requesting the

appropriate set of credentials to the assessed risk. The prototype consists in mobile agent software that implements

the protocol between the client and merchant over a Bluetooth connection.

This open and royalty-free specification together with the strong interest shown by the players provide a good

perspective in terms of solution adoption, which will push forward technology and may simplify people every day

routine.

Keywords: wireless payment, access control, electronic commerce, mobile services, nomadic devices, secure

payment transaction, dynamic risk assessment.

10 Resumo

Resumo

A rápida evolução dos dispositivos móveis e das tecnologias de comunicação sem fios transformou o telemóvel num

poderoso dispositivo de computação móvel. A necessidade de estar permanentemente contactável, comum à

civilização moderna, tem aumentado a dependência deste dispositivo, sendo transportado pela maioria das pessoas

num ambiente urbano e assumindo um papel talvez mais importante que a própria carteira. A ubiquidade e

capacidade de computação dos telemóveis aumentam o interesse no desenvolvimento de serviços móveis, além de

tradicionais serviços de voz. Um telemóvel pode em breve tornar-se um elemento activo nas nossas tarefas diárias,

servindo como um instrumento de pagamento e controlo de acessos, proporcionando assim novas interfaces para

serviços existentes. A unificação de vários serviços num único dispositivo é um desafio que pode simplificar a nossa

rotina diária e aumentar o conforto, no limite deixaremos de necessitar de dinheiro físico, cartões de crédito ou

débito, chaves de residência e de veículos automóveis, ou inclusive documentos de identificação como bilhetes de

identidade ou passaportes.

O interesse demonstrado pelos intervenientes, desde os fabricantes de telemóveis e operadores de rede móvel até

às instituições financeiras, levaram ao aparecimento de múltiplas soluções de serviços móveis. Porém estas soluções

respondem geralmente a problemas específicos, apenas contemplando um fornecedor de serviços ou uma

determinada operação de pagamento, como seja a compra de bilhetes ou pagamento de estacionamento. Estas

soluções emergentes consistem também tipicamente em especificações fechadas e protocolos proprietários. A

definição de uma arquitectura genérica, aberta, interoperável e extensível é necessária para que os serviços móveis

possam ser adoptados de uma forma generalizada por diferentes fornecedores de serviços e para diversos tipos de

pagamento. A maior parte das soluções actuais de pagamento móvel depende de comunicações através da rede

móvel, algumas utilizam o telemóvel apenas como uma interface de acesso à internet enquanto outras possibilitam

o envio de uma SMS (Short Message Service) para autorizar uma transacção, o que implica custos de comunicação

em todas as operações de pagamento. Este custo de operação torna essas soluções inadequadas para a realização

de micropagamentos e podem por isso ter uma aceitação limitada por parte dos clientes. As soluções existentes

focam-se maioritariamente em pagamentos à distância, não tirando partido das características do pagamento

presencial e não oferecendo por isso uma verdadeira alternativa ao modelo actual de pagamento com cartões de

crédito/débito. As capacidades computacionais dos telemóveis e suporte de diversos protocolos de comunicação

sem fio local não têm sido aproveitadas, vendo o telemóvel apenas como um terminal GSM (Global System for

Mobile Communications) e não oferecendo serviços adicionais como seja a avaliação dinâmica de risco ou controlo

de despesas.

Esta dissertação propõe e valida, através de um demonstrador, uma arquitectura aberta para o pagamento e

controlo de acesso baseado em dispositivos móveis, intitulada WPAC (Wireless Payment and Access Control). Para

chegar à solução apresentada foram estudadas outras soluções de pagamento, desde o aparecimento dos cartões de

débito até a era de pagamentos electrónicos móveis, passando pelas soluções de pagamento através da internet. As

capacidades dos dispositivos móveis, designadamente os telemóveis, e tecnologias de comunicação sem fios foram

também analisadas a fim de determinar o estado tecnológico actual. A arquitectura WPAC utiliza padrões de

desenho utilizados pela indústria em soluções de sucesso, a utilização de padrões testados e a reutilização de

11 Resumo

soluções com provas dadas permite aumentar a confiança nesta solução, um desses exemplos é a utilização de uma

infra-estrutura de chave pública para o estabelecimento de um canal de comunicação seguro. Esta especificação é

uma arquitectura orientada aos serviços que utiliza os Web Services para a definição do contracto do serviço de

pagamento. A viabilidade da solução na orquestração de um conjunto de tecnologias e a prova de conceito de novas

abordagens é alcançada com a construção de um protótipo e a realização de testes.

A arquitectura WPAC possibilita a realização de pagamentos móveis presenciais, isto é, junto do fornecedor de bens

ou serviços, seguindo o modelo de pagamento com cartões de crédito/débito no que diz respeito aos intervenientes

e relações entre eles. Esta especificação inclui como aspecto inovador a avaliação dinâmica de risco, que utiliza o

valor do pagamento, a existência de pagamentos frequentes num período curto de tempo, e a data, hora e local do

pagamento como factores de risco; solicitando ao cliente o conjunto de credenciais adequado ao risco avaliado,

desde códigos pessoais a dados biométricos. É também apresentada uma alternativa ao processo normal de

pagamento, que apesar de menos cómoda permite efectuar pagamentos quando não é possível estabelecer um

canal de comunicação sem fios, aumentando assim a tolerância a falhas. Esta solução não implica custos de operação

para o cliente na comunicação com o ponto de venda do comerciante, que é realizada através de tecnologias de

comunicação local sem fios, pode ser necessária a comunicação através da rede móvel com o emissor do agente de

pagamento para a actualização do agente de software ou de dados de segurança, mas essas transmissões são

ocasionais. O modelo de segurança recorre a certificados para autenticação dos intervenientes e a uma infra-

estrutura de chave pública para cifra e assinatura das mensagens. Os dados de segurança incluídos no agente de

software móvel, para desabilitar a cópia ou corrupção da aplicação mas também para a comparação com as

credenciais inseridas pelo cliente, devem igualmente ser encriptados e assinados de forma a garantir a sua

confidencialidade e integridade. A arquitectura de pagamento utiliza o standard de Web Services, que é amplamente

conhecido, aberto e interoperável, para a definição do serviço de pagamento. Existem extensões à especificação de

Web Services relativas à segurança que permitem trocar itens de segurança e definem o modo de cifra e assinatura

de mensagens, possibilitando assim a sua utilização em aplicações que necessitem de segurança como é o caso de

serviços de pagamento e controlo de acesso. O contracto de um Web Service define o modo de invocação dos

serviços, transmissão de informação e representação de dados, sendo normalmente utilizado o protocolo SOAP que

na prática não é mais que um protocolo de troca de mensagens XML (eXtensible Markup Language). O envio e

recepção de mensagens XML; ou seja, a transmissão de simples sequências de caracteres, é suportado pela maioria

dos protocolos de comunicação, sendo portanto uma solução abrangente que permite a adopção de diversas

tecnologias de comunicação sem fios. O protótipo construído inclui um agente de software móvel, implementado

sobre a forma de uma MIDlet, aplicação Java para dispositivos móveis, que implementa o protocolo de pagamento

comunicando sobre uma ligação Bluetooth com o ponto de venda do comerciante, simulado por uma aplicação

desenvolvida sobre a plataforma .NET e que por isso faz prova da heterogeneidade da solução. A comunicação entre

o comerciante e o seu banco para autorização do pagamento e transferência monetária utiliza o protocolo existente

para a autorização de pagamentos com base em cartões de crédito/débito.

A definição desta especificação aberta e genérica em conjunto com o forte interesse demonstrado pelos

intervenientes, proporcionam uma boa perspectiva em termos de adopção da solução, o que pode impulsionar a

12 Resumo

implementação de serviços móveis e dessa forma simplificar as rotinas diárias das pessoas. Soluções móveis de

pagamento reduzem a necessidade de transportar vários cartões de crédito/débito na nossa carteira. A avaliação

dinâmica de risco permite aumentar a segurança dos pagamentos, com a solicitação de mais credenciais ao cliente

para pagamentos com um maior risco associado, sendo um ponto importante quer para os clientes quer para as

instituições financeiras pois diminui o risco de fraude e aumenta a confiança no sistema. Esta solução de pagamento

electrónico pode também facilitar a consulta de pagamentos efectuados e saldos, mantendo um histórico dos

movimentos, o que não é possível nos cartões de crédito/débito sem uma visita a uma ATM (Automated Teller

Machine) ou utilização de homebanking.

Palavras-chave: pagamento sem fios, controlo de acessos, comércio electrónico, serviços móveis, dispositivos

nómadas, segurança, avaliação dinâmica de risco.

13 Introduction

Introduction

Since the beginning of mankind, economic trades were a fundamental activity for civilizations prosperity. Commerce

and business concepts have evolved over the years however the money notion remained essentially the same till the

20th

century. Currency is the unit of exchange most used in our common history, these metal or paper objects have

intrinsic value for humans and thus facilitate the transfer of goods and services [9]. In the last century the money

perception has changed, with the evolution of information technologies new means of payment had appeared and it

is nowadays possible to buy items with virtual money. This concept first emerged with bank money transfers and

credit cards, either way without the use of physical currency. The shift from physical to virtual payments has brought

benefits to clients and merchants. Virtual money usage simplify the payment transaction as it eliminates currency

searching and money change, the risk of theft is also decreased as the amount of currency carried by each person

reduces. Financial organizations view virtual money as a way of providing added convenience to their clients along

with an opportunity to reduce their operating costs [17].

Credit and debit cards, also known as ‘plastic money’, were the first successful alternative form of money, especially

designed to substitute currency in proximity payments. The issuer of credit cards grants a line of credit to the client

from where he can borrow money for payments or as a cash advance, debit cards on the other hand only allow the

cardholder to conduct payments if he has enough balance in his bank account. To perform payments it is typically

necessary to sign a receipt or introduce a Personal Identification Number (PIN) in the merchant’s Point of Sale (POS).

There are several brands of credit and debit cards, however they follow the same shape and size standard and

merchants typically support all the major brands. These cards can also be used in Automated Teller Machines (ATM)

to access to financial services in a public space without the need for a human clerk. Initial cards had a magnetic stripe

where bank account data was saved, however they are being replaced by more secure chip cards. Credit cards, ATMs

and telephone banking were the initial forms of electronic commerce (e-commerce), which consists in buying and

selling products or services over electronic systems [6]. However it was until the advent of Internet that e-commerce

would develop further and redefine the way in which business was conducted. The Internet and e-commerce

allowed the development of business-to-consumer (B2C) transactions and enabled trading between remote entities.

Security concerns emerged due to the unsecure nature of Internet, allied to the fact that nearly all the transactions

carried out through e-commerce are monetary and involve the flow of money in some form, usually using a credit

card. To address this issues and providing confidentiality, authenticity, and integrity of payment, e-commerce

protocols use a variety of cryptographic techniques, including encryption, digital signatures and certificates [6][17].

Recently, the emergence of wireless and mobile networks had made possible the extension of electronic commerce

to a new application and research area, mobile commerce (m-commerce), which is defined as the exchange or

buying and selling of commodities, services, or information through the use of mobile handheld devices. In just a few

years, mobile commerce has emerged from nowhere to become an important new trend in business transactions

[17]. The nomadic nature of mobile devices and their increasing capabilities enables proximity payments, which

involves the use of wireless technologies to pay for goods and services over short distances. Proximity transactions

develop the potential of m-commerce, for example, using a mobile device to pay at a POS, vending machine, ticket

machine, market, parking, and so forth. Using short-range wireless communication protocols, such as Bluetooth,

14 Introduction

Infrared or NFC (Near Field Communication), the mobile device can be transformed into a sophisticated terminal that

is able to process both micro and macro payments. In our modern society, communication and connectivity are

major requirements, as shown by the profusion of mobile phone terminals and wireless network access points,

known as hotspots, hence most people in an urban scenario carries at least one mobile phone. The ubiquity and

increasing computing capacity of mobile phones increases the interest in the development of wireless services and

foresights a bright future for m-commerce. The unification of various services in one device, providing new interfaces

for existing services, is a challenge that can simplify our daily routine. In an idyllic world we will stop using physical

money, credit cards, residence keys, or even any identification documents. The future of m-commerce, its prosperity

and popularity, will be brought to a higher level only if information can be securely and safely exchanged among end

systems, mobile users and content providers. Also, like in any type of commerce, clients have to trust merchants

and, likewise, merchants have to trust customers [17].

M-commerce has a widespread interest across stakeholders, from mobile phone manufacturers and mobile network

operators to financial institutions. While some players see mobile payments (m-payments) as a unique opportunity

to consolidate their role in the m-commerce value chain others are interested in adding value to their products or

services [17]. M-payment services are currently provided by mobile network operators, financial institutions and

independent vendors. Many differences exist between these enclosed proprietary payment solutions, most of them

answer to particular payment scenarios only supporting one service provider or a specific payment operation.

Although, there are a few organizations which were setup to develop a common mechanism for deploying mobile

payment services, yet no common standard has been adopted for mobile payment services [19]. The design of an

open, generic, interoperable and extensible architecture is therefore necessary for m-payment services widespread

adoption, supporting several service providers and payment types. The majority of existing wireless payment

solutions rely on mobile network communications, some see the mobile phone merely as a WAP (Wireless

Application Protocol) terminal that can browse the internet while others enable payment services through the

interchange of short text messages, using the SMS (Short Message Service) protocol. The utilization of mobile

network protocols implies the existence of communication fees in all payment transactions, operational costs make

such solutions inappropriate for micropayments and may have a limited acceptance by clients. These solutions focus

on remote payments scenarios, where client and merchant are not face-to-face but in reality most of our daily

payments are conducted near the merchant, thus they do not take advantage of proximity payments characteristics

and are not a real alternative to credit/debit card payments. Proximity electronic payments scenarios are illustrated

at Figure 1.

Figure 1 – Electronic payment scenario overview

15 Introduction

Mobile payment architectures involve several actors, besides clients and merchants, mobile network operators

(MNO) and financial institutes are usually present. Mobile network operators provide communication services over

which the payment transaction is usually performed, however instead of simply enabling the communication

between the parties they typically want to take place in the value chain. If the payment solution is provided by a

single financial institute then it must make available the necessary software agents both for the client and the

merchant, which typically communicate with the financial institute to approve each payment transaction. However if

several financial organizations endorse a payment system, more actors should be part of the process, the issuer, the

bank who delivers the mobile software agent to the client; and the acquirer, which provide clearing services on

behalf of the merchant; much like the credit card payment scenario. The existence of a clearing entity is common in

e-commerce because money transfers do not usually take place at purchase time, therefore a clearing entity must be

responsible for the transactions, including debiting the client and crediting the merchant.

Security is a main concern in several areas of human life, the fear induced due to terrorism or the apprehension

caused by the last financial crisis are examples where physical and economic security is necessary. In m-payment

solutions, which involve money transactions, security solutions must also mitigate risks and eliminate threats. In any

virtual money payment system, currency theft is not a risk, however these systems contain sensitive data like bank

account information that when compromised may enable access to client’s money. Besides keeping back account

details confidential, the solution must provide authentication and authorization measures to confirm client identity

and his/her permission to conduct payments. Authentication and authorization are the key features of access control

systems, where users need to present their credentials, in order to be authorized to access a particular resource.

Therefore inside a mobile payment service there is an access control service, Figure 2 depicts an access control

scenario.

Figure 2 – Access control scenario overview

The WPAC main goal is to define an open architecture for wireless payment and access control, using nomadic

devices and in particular mobile phones. WPAP solution should follow service oriented architecture (SOA),

preferentially through the usage of Web Services, which enables functionalities similar to credit cards. Security,

dependability [6] and dynamic risk assessment are key challenges and the biggest contribute of the WPAC project for

the development of m-commerce.

Roadmap

In the next chapter it will be discussed the state of art, including payment systems, current mobile technologies and

security solutions. Further ahead the WPAC architecture will be presented, with a focus on risk assessment and

security.

16 State of Art

State of Art

In this chapter it will be presented current mobile payment and access control solutions, mobile devices platform

characteristics, wireless communication protocols, security risks and solutions.

Mobile Payment and Access Control

Mobile payment (m-payment) is a new alternative payment method, focused on nomadic devices, which

complements traditional payment methods, such as cash, check or credit cards, and enables mobile phone users to

pay for wide range of services and digital or hard goods [6].

Payment Solutions

PayPal Mobile

PayPal is a popular online payment service. Via WAP-enabled phones the customer can use PayPal’s wireless

interface to accommodate mobile-payment. With PayPal Mobile, users can send money, purchase items or donate

to charities from their mobile devices. PayPal Mobile users make payments by sending a text message to PayPal.

PayPal calls the user back to confirm the mobile payment, and then sends the money to the recipient. In the case of

a Text to Buy purchase, after the merchant receives the payment, the item is shipped to the address already saved in

the user’s PayPal account. There are three convenient ways to use PayPal Mobile, through mobile phone web

browser, by text message or via a phone call to an automated voice system, as illustrated in the figure below.

Besides buying products, PayPal Mobile allows to check PayPal account balance and send money to anybody [4].

Figure 3 – Ways to use PayPal Mobile

P2P-Paid

The P2P-Paid architecture is a wireless payment system [1], which defines a lightweight peer-to-peer mobile

payment system that allows users to conduct wireless payments over mobile phones and perform secure

transactions with the P2P-Paid Server. The system is divided in two parts, the mobile client to mobile client

communication and the mobile client to server communication. The wireless communication between the mobile

devices is achieved through Bluetooth communication protocol. Both payer and merchant act as peers and join a

Bluetooth network advertising their role. The merchant publishes his information, a protocol specific identifier

(P2PID), onto the network to become visible to payers. Then the payer searches for payees in the network using

Bluetooth’s Service Discovery Protocol (SDP) and selects one to make a payment. At this time the user inputs the

amount and a simple description for the payment. His mobile phone encrypts the data and send to the P2P-Paid

Server. The server decrypts the payment data, validates client and merchant accounts and checks for available

17 State of Art

balance in client’s account. In case of success the transaction is performed and the parties are notified through a

receipt is sent to payer and payee mobile devices. This communication is performed over HTTP/HTTPS protocols with

a security header attached to messages. This usage scenario is depicted in Figure 4.

The P2P-Paid business process relies on an online server to commit the money transaction synchronously. The

mobile phone Bluetooth communication between client and merchant only provides the identification of the

merchant. The communication with the server via HTTPS has an associated fee that is debited from client mobile

operator account.

Figure 4 – P2P-Paid usage scenario

SEMOPS

SEMOPS (Secure Mobile Payment System) is a complex, universal, user friendly payment system. The possible

transactions include POS payments, in band purchases – Internet and WAP, P2P transfers, purchases made at

vending machines and also bill payments. The payments are not limited by values either, as both micro and macro

transactions can be performed. For customers and merchants, the payment service is provided by their own banks or

mobile operators. As no intermediaries are involved in this relationship the whole payment transaction is based on

trust between known partners. In SEMOPS customers do not provide any sensitive data to the merchant during the

payment process therefore they can practically remain anonymous during the payment process. Having received the

necessary transaction details, the customer prepares and signs a payment request and forwards it to its own

payment processor. If the necessary funds are available the merchant receives a payment notification, a kind of

guarantee from its own payment processor [74].

Reverse-Charge/Billed SMS

Reverse-billed premium rate SMS services deliver content to mobile phones for a fee. Clients typically subscribe a

service and are charged a premium for the messages they receive. The payment model enables clients to use SMS

text messaging to anonymously pay for access to digital entertainment and content. Reverse SMS billing means that

the owner of the recipient phone rather than the message sender is charged for the cost of the SMS message

received. There are various vendors offering reverse-charge SMS services, however this payment scenario is not

suited for the purchase of hard goods but rather digital goods received on the mobile device, such as ringtones or

informative messages [19].

18 State of Art

Vodafone m-pay

In the Vodafone m-pay solution, users are billed for the purchase items directly on their mobile phone invoice, next

to phone services. Hence, on opposite to reverse-billed SMS, there is no need to send a SMS each time a client

makes a payment or receives a solicited content. Instead, clients are billed when they enter their username and

password details on the web or WAP site where they are buying content from [19].

Secure Electronic Transaction

Secure Electronic Transaction (SET) is a standard protocol for securing credit card transactions over insecure

networks, specifically, the Internet [3]. SET is not itself a payment system, but rather a set of security protocols and

formats that enables users to employ the existing credit card payment infrastructure on an open network in a secure

fashion. Although SET is not designed to support payments on mobile devices, it provides a good clarification of

actors, roles and protocols in an electronic distributed payment system. The SET system includes the following

participants: cardholder, the client performing a purchase; merchant, the entity providing products or services;

issuer, the company that provides the cardholder with the credit card; the credit card’s brand; acquirer, an

organization that provides card authorization and payment capture services for merchants; payment gateway, which

provides, in behalf of the acquirer, an interface between SET and existing bankcard association; and certification

authority, which provides public key certification [3].

Figure 5 – SET actors

The SET specification include five protocols that can be divided into two phases: the registration phase, where the

participants obtain electronic credentials that replace traditional credit cards numbers and protect their privacy; and

the purchase phase which is at the center of the SET protocol. The registration phase includes the cardholder,

merchant and payment gateway certification processes, all of which include communication with the corresponding

certification authority. The cardholder provides additional details in his registration process, so that a credit card

number is associated with him. The SET payment transaction includes a Purchase process between the cardholder

19 State of Art

and the merchant; a Payment Authorization process, which allows a Merchant to verify and authorize the

Cardholder's details with a Payment Gateway; and Payment Capture process that is used by Merchants for the

actual fund transfer [3][37].

Access Control Solutions

Most payment solutions are traceable, that it, there is complete information about every step in a process chain.

This means that payers identity is know and the payment is not anonymous like in traditional cash payments. The

introduction of client’s credentials, to validate his/her identity, also can be used for access control. Furthermore the

purchase of digital tickets binds m-payments and access control in the same usage scenario.

M-Ticket

M-Ticket (mobile ticket) is a proposal of a virtual ticket that substitute the conventional paper version. Upon ticket

purchase a text message is sent to the client’s mobile phone. This message includes a numeric code relative to the

ticket and optionally may also contain an electronic code. The electronic code represents the same information that

the numeric one. However it simplifies the ticket presentation process, as the client only needs to approach the

mobile phone screen, displaying the electronic code, to an optic reader.

A ticket must be unique and not transmissible. Personal identification credentials share the same premises, but with

an extra focus in its security. The M-Ticket solution provides a good base for studying an alternative for personal

identification and access control. This is important to provide countermeasures when the main process is not

available, and thus increase dependability.

Figure 6 – M-Ticket detail

Summary

Nowadays there are two primary models for mobile payments, premium SMS based transactional payments, and

Mobile Web payments through WAP or Mobile Network communication. Reverse-billed premium rate SMS are still

common as a payment option for the purchase of digital content for mobile phones, however this model never

achieved success in others payment scenarios, mainly due to poor reliability. On the other hand, m-payment

solutions, based on Mobile Network communications to access online payment servers, provide a richer usage

experience but are tightly connected with remote online payment scenarios and imply communication fees, not

taking advantage of mobile phones local communication capabilities.

20 State of Art

Mobile Devices

There are several types of mobile devices, in fact the definition is too broad and includes any piece of equipment

that is easily carried around, ranging from pagers to laptops. M-payment solutions require mobile computing

capabilities and thus are limited to certain types of devices. Devices’ availability is also critical to the success of such

applications.

Types and availability

Pagers, calculators, digital cameras and music players are examples of mobile devices not suitable to payment

solutions, even though all of them have intrinsic processing capabilities they are not easily programmable nor have a

generic interface. Devices that support the installation of new applications, like laptops and mobile phones, but even

game consoles, are more suited as platform for the development of m-services. Laptops are probably the most

powerful mobile devices but they are not as available as others devices and are somewhat difficult to carry around.

In the last years, a smaller version of portable computers, called netbooks, have been emerging, although more easy

to transport they are even less available then their laptops counterpart. Portable computers are not the ideal choice

because typically, in order to use them, it is necessary some kind of installation, like sitting down, open the lid and

power on the device. On the other end, mobile phones are highly available in urban scenarios and are becoming

smaller and smaller, thus increasing its mobility. PDAs (Personal Digital Assistants) and smartphones are typically

bigger then mobile phones, but also have more processing power, however they are slightly less available due to the

higher purchase cost. Portable game consoles can also receive customized applications and typically have intrinsic

communication capabilities, but they have a lower mobility and availability thus removing them from the first choice.

Figure 7 estimates the positioning of several mobile devices accordingly to availability and mobility.

Figure 7 – Devices mobility and availability

Mobile phones

In Portugal mobile phones reached a penetration rate of 137% in 2008, meaning that there are 137 active mobile

phone numbers for each 100 habitant [7]. In 2007, European Union reached a penetration rate of 112%, while

United States and Japan, still below 100%, attained rates of 87% and 84% respectively [55]. There are an estimate 1.5

billion mobile phones in the world today, this is more than three times the number of personal computers (PCs), and

today’s most sophisticated phones have the processing power of a mid-1990s PC. The high availability, mobility and

increasing computing capabilities make the mobile phone the key device for the development of mobile solutions.

Also, the rapid and widespread adoption of camera phones suggests that stakeholders and consumers are willing to

Mobility

Availability

PDA

Laptop

Mobile phone

Game console

Netbook

21 State of Art

invest in more expensive devices and mobile services

benefits [53]. Observers speculate that in a near future a new class of ‘always

products categorized as Ultra-Mobile Devices (UMDs)

an alternative to a PC [59].

Figure

Almost all new mobile phones have a digital camera embedded, some devices have a video

others are tailored for music reproduction and some smartphones are shipped with touch screens. The diversity of

models in the modern mobile phone market caters for a wide variety of customer

are tiny and discreet, some are chosen

match the owner’s outfit, some just offer basic functionalit

leisure services to their users [53]. Thus mobile phone users can be grouped in various profiles according

tastes, but more significantly by their typical mobile phone’s service usage. Users that only make use of typical voice

services are less likely to endorse m-payment solutions than young users eager to try the every new feature.

Nokia is the predominant mobile phone manufacturer in Portugal but also worldwide, reaching a market share over

50% in the global market. Nokia also has a leading role in mobile applications development, providing tools for

developers and supporting them in online foru

Figure 9 – Mobile phones manufacturers’ Portuguese market share in February 2009

98%

0

5

10

15

20

2004

Su

bsc

rib

ers

(M

illi

on

s)

9,84

and mobile services if they are attractive enough and offer significant or perceived

Observers speculate that in a near future a new class of ‘always-on’ devices,

Mobile Devices (UMDs), will emerge and mobile phones will become more and more

Figure 8 – Mobile phone penetration rate in Portugal

Almost all new mobile phones have a digital camera embedded, some devices have a video


ne market caters for a wide variety of customer tastes and lifestyles. Some phones

are tiny and discreet, some are chosen for their appearance, like a fashion accessory with alternative covers

just offer basic functionality while some others provide a wide range of

Thus mobile phone users can be grouped in various profiles according


payment solutions than young users eager to try the every new feature.

predominant mobile phone manufacturer in Portugal but also worldwide, reaching a market share over


developers and supporting them in online forums.

Mobile phones manufacturers’ Portuguese market share in February 2009

106% 113% 122% 137%

0%

50%

100%

150%

2005 2006 2007 2008

PT Subscribers PT Penetration Rate

44,05

15,73

25,74

Nokia

Sony-Ericsson

Samsung

Sharp

Motorola

Sagem

if they are attractive enough and offer significant or perceived

on’ devices, Internet-connected

, will emerge and mobile phones will become more and more

Almost all new mobile phones have a digital camera embedded, some devices have a video-game oriented interface,


tastes and lifestyles. Some phones

with alternative covers to

y while some others provide a wide range of business and

Thus mobile phone users can be grouped in various profiles accordingly with their


payment solutions than young users eager to try the every new feature.

predominant mobile phone manufacturer in Portugal but also worldwide, reaching a market share over


Mobile phones manufacturers’ Portuguese market share in February 2009

0%

50%

100%

150%

Pe

ne

tra

tio

n R

ate

Ericsson

Samsung

Motorola

22 State of Art

Operating Systems

Modern mobile phones are systems that have mobile operating system like Symbian, iPhone OS, Windows Mobile or

the recent Android. In these devices, users can have different applications like operating-system dependant native

programs, or virtual-machine dependant programs [56]. Java Micro Edition platform is supported is most devices,

some of them, most likely smartphones with Windows Mobile operating system, can also support applications

written for .NET Compact Framework.

Symbian

Symbian OS is an operating system designed for mobile devices, with associated libraries, user interface, frameworks

and reference implementations of common tools, developed by Symbian Ltd., which runs exclusively on ARM

processors. Symbian OS is superseded by Symbian, following the official launch of the Symbian Foundation in April

2009. Symbian is the leading OS in the smart mobile device market, used mostly by Nokia mobile phones. By

November 2008 statistics showed that Symbian OS had almost 50% of market share [6]. The native language of

Symbian is C++, although it is not a standard implementation. There were multiple platforms based upon Symbian OS

that provided SDKs for application developers wishing to target Symbian OS devices, including .NET and Java ME

platforms.

Windows Mobile

Windows Mobile is a compact operating system combined with a suite of basic applications for mobile devices based

on the Microsoft Win32 API. Devices that run Windows Mobile include Pocket PCs, Smartphones, Portable Media

Centers, and on-board computers for certain automobiles. Third-party software development is available both in

native code, with Visual C++, or Managed code that works with the .NET Compact Framework [6]. Like in the desktop

Windows editions, the Java Virtual Machine can be installed in Windows Mobile, yet this may not be a good solution

as the deployment of a Java MIDlet may also imply that clients need to install the JVM.

iPhone OS

The iPhone OS is the operating system developed by Apple for the iPhone. iPhone OS is derived from Mac OS X but is

targeted for ARM-based processors. iPhone OS' user interface is based on the concept of direct manipulation, using

multi-touch gestures, such as swiping, tapping and pinching. Interface control elements consist of sliders, switches,

and buttons. Additionally, using internal accelerometers, rotating the device on its axis alters the screen orientation

in some applications. The development of applications to iPhone is available through the iPhone SDK, using the

provided libraries and programming in the Objective-C language. Apple has not announced any plans to enable Java

to run on the iPhone, although Sun Microsystems announced plans to release a Java Virtual Machine for iPhone OS,

the SDK’s terms of agreement could hinder the development of the JVM without Apple's cooperation [6].

Android

Android is a mobile operating system running on the Linux kernel. It was initially developed by Google and later the

Open Handset Alliance. It allows developers to write managed code in the Java language, controlling the device via

Google-developed Java libraries. Android is a free and open source software that intents to become a de facto open

standard in mobile operating systems. According to Google, by the end of 2009 there will be at least 18 phone

23 State of Art

models shipped with Android worldwide, this includes manufacturers such as HTC, LG, Motorola, Samsung and Sony

Ericsson, that is, most mobile phones manufactures except Nokia [6].

Java is currently the predominant virtual machine supported by mobile phones, thus developers should aim for the

Java Virtual Machine in order to cover a larger audience. Initially Java MIDlets were very limited, and access to device

peripherals was not available, however the number of supported Java APIs has been increasing and thus mobile

applications can be more powerful.

Health issues

Over the last years some rumors about health issues associated with long term mobile phone usage have been

appearing. Even so, accordingly with the National Radiation Protection Board’s (NRPB) independent Advisory Group

on Non-Ionising Radiation (AGNIR), there is no biological evidence for mutation or tumor causation by Radio

Frequency (RF) exposure, and epidemiological studies overall do not support causal associations between exposures

to RF and the risk of cancer, in particular from mobile phone use. AGNIR found a number of studies that suggested

possible effects on brain function at RF exposure levels comparable with those from mobile phone handset use.

AGNIR regarded the overall evidence as inconclusive but did not state that mobile phones have been proven to be

entirely risk free. The weight of evidence now available does not suggest that there are adverse health effects from

exposures to RF fields below guideline levels, but the published research on RF exposures and health has limitations,

and mobile phones have only been in widespread use for a relatively short time [53].

Wireless Communication

Wireless communication technologies and protocols have a significant role in mobile payment systems. However

they are really only a mean to an end, thus communication technologies, usually present at mobile devices, will be

analyzed by a user view point, not focused on inner architecture but instead understanding their functionalities and

possibilities, as the WPAC solution builds on top of them.

Mobile Network Telecommunication

Originally designed for voice-only communication, mobile systems have evolved from analog to digital and from

circuit-switched to packet-switched networks. Currently we are in the third generation of wireless cellular networks.

1th Generation system such as AMPS (Advanced Mobile Phone System) and TACS (Total Access Control System) are

obsolete and thus will not play a significant role in mobile commerce systems. GSM (Global System for Mobile

communications) and its enhancement GPRS (General Packet Radio Service) protocol have mainly been developed

and deployed in Europe. GPRS can support data rates of only about 100 kbps, but its upgraded version, the EDGE

(Enhanced Data for Global Evolution) protocol, is capable of supporting 384 kbps. Currently, most of the cellular

wireless networks in the world follow 2G and 2.5G standards. However, there is no doubt that in the near future, 3G

systems with a quality-of-service capability will dominate wireless service, the two main standards for 3G are

Wideband CDMA (WCDMA) and CDMA2000, both use a 5 MHz bandwidth. Technical differences between them

include a different chip rate, frame time, spectrum used, and time synchronization mechanism. The WCDMA system

24 State of Art

can inter-network with GSM networks and has been strongly supported by European Union, which call it UMTS

(Universal Mobile Telecommunication System) [17].

WAP

The WAP (Wireless Application Protocol) protocol is designed to work with all wireless networks. The most

important technology is probably the WAP Gateway, which translates requests from WAP protocol stack to the

WWW stack, so they can be submitted to Web servers. For example, requests from mobile stations are sent as a URL

through the network to the WAP Gateway, responses are sent from the Web server to the WAP Gateway in HTML

and are then translated to WML (Wireless Markup Language) and sent to the mobile stations [17].

Short-Range Wireless Communication Technologies

Besides mobile network communications, usually mobile phones also support short-range wireless communication

protocols, like IrDA, Bluetooth or NFC.

IrDA

IrDA (Infrared Data Association) was launched in 1993 as a cable replacement technology using infrared light pulses.

In 1997, IrDA introduced the first version of the OBEX (OBject EXchange) protocol, allowing IrDA-enabled devices to

wirelessly exchange business cards, calendar items, and other object types [58]. IrDA physical connections are

established by pointing devices at each other at relatively close range. The primary device initiates a device

discovery, and if a remote device, the secondary device, is detected, it may establish a connection. Once a

connection is open, the primary sends data to the secondary, periodically offering the secondary a chance to

transmit as well [58]. Because IrDA connections are limited to two devices with a direct line of sight, IrDA is not

practically useful for a real intercommunication scheme, thus mobile phones supporting IrDA communication are

disappearing.

Bluetooth

Bluetooth is a short-range, low-power and standard technology used in many different devices, such as mobile

phones, laptops and PDAs [18]. The Bluetooth radio hardware operates in the 2.45-gigahertz Industrial, Scientific,

and Medical frequency band (ISM band), allowing for unlicensed operation worldwide. Bluetooth networks are

formed ad hoc and dynamically, when Bluetooth-enabled devices come into proximity of one another. A Bluetooth

network can assume three types of models: point-to-point, a simple one-to-one communication where the device

who starts the connection is the master and the one who accepts it is the slave; multi-point, where a device can

provide various services to other devices; and a scattered net, which combines the two [39][58]. In m-payments,

Bluetooth must be used in a point-to-point network, between client and merchant.

Bluetooth media access is based on a frequency-hopping scheme allowing many independent point-to-multipoint

connections in the same physical space. Through separate inquiry and paging processes, a master device searches for

and connects with a slave device in range. To establish the connection, the slave must synchronize with the master’s

clock and pseudo-random hopping sequence before any data exchange can occur. This process can take up to 1

minute, which is a major protocol drawback, but it can often be accomplished in less than 5. Bluetooth allows

additional connection states, known as park, hold, and sniff, which are used to minimize connection traffic, enter

25 State of Art

power-saving modes, or even to allow devices to temporarily participate in other networks. Media access is

controlled entirely by the master, which periodically polls slaves for data [58].

Bluetooth is defined as a layered protocol architecture stack, depicted in Figure 10, consisting of core protocols,

cable replacement protocols, telephony control protocols, and adopted protocols. Bluetooth connections can be

established over the OBEX (OBject EXchange) protocol, a session-layer protocol for the exchange of objects;

RFCOMM (Radio Frequency COMMunications), a serial cable replacement protocol; or L2CAP (Logical Link Control

and Adaptation Protocol), which is a low level host layer responsible for the logical connection between two devices,

segmentation and reassembly of on-air packets. RFCOMM is the suitable protocol for most applications, due to the

widespread support and publicly available API, but also because it provides a simple reliable data stream similar to

TCP [6].

Figure 10 – Bluetooth stack protocol

Wi-Fi

IEEE 802.11 is a set of standards for Wireless Local Area Network (WLAN) communication in the 2.4, 3.6 and 5 GHz

frequency bands. Wi-Fi is the trademark for certified products based on the IEEE 802.11 standards [6][58]. 802.11b

and 802.11g use the 2.4 GHz ISM band, the same of Bluetooth protocol, thus interference may occur. Wi-Fi and

Bluetooth try to control their mutual interference by using different modulation, while Bluetooth uses FHSS

(Frequency Hopping Spread Spectrum) 802.11b/g use DSSS (Direct Sequence Spread Spectrum) and OFDM

(Orthogonal Frequency Division Multiplexing) respectively. 802.11a uses the 5 GHz, which offers at least 19 non-

overlapping channels rather than the 3 offered in the 2.4 GHz ISM frequency band. The range of 802.11 is greater

when comparing to Bluetooth, due to higher transmission power, but by the same reason it is less adequate to

battery-powered devices like mobile phones. The availability of WiFi on mobile devices is rising especially in smart-

phones and PDAs.

NFC

NFC (Near Field Communication) is a short-range high frequency wireless communication technology, which uses

magnetic field induction to enable the exchange of data between electronic devices over about a 10 centimeters

distance. The technology is a simple extension of the proximity-card standard, contactless card and RFID (Radio-

Bluetooth Radio

Baseband Link Controller (LC)

Link Manager Protocol (LMP)

Host/Controller Interface Firmware

Radio Frequency Communication (RFCOMM) Service Discovery Protocol (SDP)

OBject EXchange (OBEX)

API for Bluetooth

Application

Logical Link Control and Adaptation Protocol (L2CAP)

Host/Controller Interface (HCI)

Bluetooth

Host

Protocol

Bluetooth

Host

Controller

(Firmware

26 State of Art

Frequency IDentification), and is thereby compatible with existing contactless infrastructure. NFC has been

successfully used for payments in physical stores or transportation services in Asia. However NFC faces significant

challenges for wide and fast adoption, due to the lack of support in European mobile phones’ manufacturers [6].

NFC technology is perceived as easy by users, mainly due to the physical interaction scenario where the user

approaches his device to the target device in order for them to communicate. However, although NFC provides a rich

usage experience, in certain scenarios where the user is requested to view or insert information, like in the payment

scenario, it may be difficult for users to use their phone’s keypad or read the phone’s screen while touching another

device. This means that systems using NFC could not ask for user input while an NFC communication is taking place

[49]. NFC can be used for the set-up of other longer-range wireless technologies, in fact NFC cooperation was

proposed on Bluetooth 2.1 specification [6]. This cooperation allows a fast connection establishment and other

advantages, such as location and identification, associated with NFC and an easier interaction with the user when he

must use the phone interface.

Summary

If all the discussed short-range wireless communication protocols were equally available in mobile devices, the ideal

choice for usage in m-payment and access control would be NFC or Bluetooth with NFC cooperation for connection

establishment. With the usage of NFC, clients have an increased trust in the system, knowing that the

communication is performed with the intended target device, the one they approach their mobile phone to.

However, because in payment scenarios clients will be prompt for payment amount confirmation and credentials

introduction, the usage of Bluetooth, after connection establishment with NFC, may provide a richer usage

experience. When comparing Bluetooth to Wi-Fi, the preference falls on Bluetooth because both protocols provide

similar communication capabilities and Bluetooth is optimized for low power consumption. IrDA is closer to NFC than

Bluetooth, because devices must be kept near, in line of sight, during communication. However usage experience

showed that IrDA connections are easily lost if the communicating mobile phone is just slightly moved, making it

unsuitable for real world payment scenarios. Table 1 resume short-range wireless communication standards

characteristics.

Protocol Max Data Rate Typical Range Frequency Band

Bluetooth 1 Mbps < 10 m 2.4 GHz

802.11b 11 Mbps < 100 m 2.4 GHz

802.11g 54 Mbps < 150 m 2,4 GHz

802.11a 54 Mbps < 100 m 5 GHz

IrDA 16 Mbps < 1 m Infrared

NFC 424 Kbps < 20 cm 14 MHz

Table 1 – Short-range wireless communication standards

Short-range communication protocols are not equally distributed in mobile phones. To analyze the availability of

these protocols, was performed a study on the evolution of wireless protocols supported by Nokia phone models,

the biggest worldwide manufacturer, over the last years. This study, depicted in Figure 11, shows that only Bluetooth

is generally available in mobile phones, with availability close to 100% in Nokia phone models, as of 2007 only one

27 State of Art

new phone model from Nokia was shipped without Bluetooth, and two new models in 2008. In 2002 most Nokia

phones had support to IrDA communication and Bluetooth support was low, however by 2008 only two Nokia phone

models were shipped with IrDA, Bluetooth has replaced IrDA as preferential wireless communication technology.

The support for Wi-Fi has been increasing, mostly because it can share part of the radio hardware with Bluetooth,

however availability is still low when comparing to Bluetooth. NFC is supported only in two Nokia phone models, one

release in 2007 and the other in 2008. Hence, due to the lack of support for NFC, Bluetooth should be used in the m-

payment solution.

Figure 11 – Mobile Communication Technologies availability on Nokia phones

Security

Regardless of the type of payment system, it relies on some fundamental principles, trust and security [2]. The buyer

has to be able to trust that the merchant will actually deliver the goods and the merchant has to trust that the

promise represented by the payment will be realized. Besides trust, security must also be imposed so that the

transaction can be performed safely, without payment being stolen in transit. For cash payments this is just a matter

of physical security, but for credit card payments it is more complex as the cardholder wants to be sure that his

credit card details are not stolen and the merchant wants warranties that the payment is transferred without

interference. In m-payment, due to the wireless nature, communication between actors is still more prone to attacks

and communication security must be assured, as we will see ahead.

In the best of all possible worlds, all buyers and sellers would be completely trustworthy and all transactions would

be totally secure. In reality, any transaction has some degree of risk attached and payment systems attempt to

mitigate the risk with an appropriate response for the payment value and the dangers of the environment in which it

takes place. Typically threats exploit system vulnerabilities, which expose assets and thus may impose liabilities to

service providers. Threats and vulnerabilities increase security risks which in turn also increase liabilities. Security

risks indicate the security requirements or properties that should be addressed, defining security solutions, in order

to reduce the risks and protect from threats. Following this security matrix, shown at Figure 12, it will be discussed

the security threats and risks that arise in mobile payment systems, followed by the security properties that must be

addressed and an explanation on the available solutions.

0%

20%

40%

60%

80%

100%

2002 2003 2004 2005 2006 2007 2008

IrDa

Bluetooth

WiFi

NFC

28 State of Art

Threats Exploit Vulnerabilities

Security

Requirements

Security

Solutions

Security

RisksAssets

Liabilities

Expose

Have

Increase

Increase

Increase

IndicateDefine

Protect

Reduce

Figure 12 – Security risk assessment and management matrix

Security Threats and Risks

Any application running in a computational device, besides the weaknesses of the application itself, inherits the

flaws of the underlying software platform, including any operating system vulnerabilities. A mobile payment solution

relies on wireless communications, which are more prone to interference and fading than wired communications,

thus reducing system reliability and availability. The broadcast nature of the radio channel makes it also easier to

tap, thus communication can be intercepted more easily. The mobility of wireless devices introduces an additional

difficulty in identifying and authenticating mobile terminals. Wireless devices usually have limited computation

capability, memory size, communication bandwidth and battery power; this might be a problem for the adoption of

high-level security schemes with long ciphers.

The motivation of the attacks can be diverse, from economic benefit, where the attacker attempts to leak or tamper

with system data in order to achieve profits or steal resources in self benefit; to pure vandalism, where the attacker

has no advantage other than to see the system fail. The security threats are divided into communication attacks,

where a third-party tries to capture or modify transmitted data; cryptographic attacks that include security schemes

weaknesses; software attacks, which include underlying software platform vulnerabilities; and physical attacks that

correspond to physical threats such as theft.

Communication attacks

The transmission of data through a wireless channel is vulnerable to attackers that listen to the radio environment.

Below it is described typical communication attacks:

• Eavesdropping – Any network can be susceptible to sniffing if someone has access to the medium, although

this might be done by a legit network analyzer it can also be part of an eavesdropping attack. Wireless

networks are more vulnerable to eavesdroppers due to the nature of the radio environment, thus it must be

assumed that every message can be intercepted. Therefore any message that contains sensitive information

must be encrypted [3].

• Spoofing – A spoofing attack is a situation in which one person or program successfully masquerades as

another by falsifying data and thereby gaining an illegitimate advantage [6].

29 State of Art

• Man-in-the-middle – An active eavesdropper may relay messages instead of just capturing them, making

independent connections with the victims and impersonating, in turn, each end of the communication, thus

spoofing both emitter and receiver. With this impersonation the man-in-the-middle attacker can obtain

sensitive data even if it is encrypted, as he may be able to negotiate the encryption key, and commit

payment orders [3][6][17].

• Message tampering – Even if sensitive data is protected and the emitter authenticated, in a wireless

environment an attacker can easily intercept and modify messages in transit. This message tampering may

have no propose other then vandalism, because if encrypted the attacker does not understand it; however

the receiver must detect the message corruption [6].

• Replaying – A replay attack is a form of network attack in which a valid data transmission is maliciously or

fraudulently repeated or delayed, this can include the repetition of a single message or the entire

conversation. This attack is carried out either by the originator or by an adversary who intercepts the data

and retransmits it, possibly as part of a spoofing attack [6].

• Denial-of-Service – A Denial-of-Service (DoS) attack is an attempt to make a resource unavailable to its

intended users, preventing a service from functioning efficiently or at all, temporarily or indefinitely.

Perpetrators of DoS attacks typically do not achieve any income with it, unless there is an entity supporting

such attacks in order to disable the competition [17][57].

Cryptographic attacks

Cryptographic solutions, although providing security schemes, may as well be attacked thus compromising their

effectiveness. A cryptanalyst that has access to several blocks of encrypted data with the same key, or even both

encrypted and decrypted data, has increased probabilities to mount a successful attack. Thus information made

available should be kept to the minimum. Known cryptographic attacks are detailed below:

• Brute Force – If an encryption algorithm has no known flaws, the encryption strength derives from the size

of the key space, which is the total number of possible shared secrets. A brute force attack generates all

possible keys within the key space and tries to use them to decrypt a message, in most schemes the

theoretical possibility of such an attack is recognized, but their strength relies in the computational

infeasibility [3][6].

• Dictionary attack – A dictionary attack is a technique for defeating a cipher or authentication mechanism by

trying to determine its decryption key or passphrase by searching a large number of possibilities. In contrast

with a brute force attack, where all possibilities are searched through exhaustively, a dictionary attack only

tries possibilities which are most likely to succeed, typically derived from a list of words in a dictionary [6].

• Birthday attack – A birthday attack exploits the mathematics behind the birthday problem in probability

theory, given an unknown function this attack tries to find two input values that give the same output, thus

finding a collision. This method can be rather efficient due to the birthday paradox [6].

• Meet-in-the-middle – The meet-in-the-middle cryptographic attack tries to discover a collision of values,

however unlike the birthday attack, it attempts to find a value in each of the ranges and domains of the

composition of two functions such that the forward mapping of one through the first function is the same

30 State of Art

as the inverse image of the other through the second function, thus meeting in the middle of the composed

function [6].

• Ciphertext attack – In the Ciphertext-only attack, the attacker has access to several encrypted messages, or

ciphertext, all of which have been encrypted using the same encryption algorithm. Thus he can perform

frequency analysis or use other statistical techniques to try to recover the original messages, or better yet

deduce the key used to encrypt the messages. In the Chosen-ciphertext attack, the attacker can choose

different ciphertext to be decrypted and has access to the decrypted message [6][11].

Software attacks

Within the mobile environment, the mobile host must be protected against malicious mobile software agents but

also the mobile software must be protected against a malicious host [56]. If the platform where the payment

solution is running has security breaches, then the payment system may become vulnerable, thus the following

threats should be addressed:

• Virus – A computer virus is a program that can copy itself and infect a computer without permission or

knowledge of the user, virus may modify its copies, or the copies may modify themselves, as occurs in a

metamorphic virus. Computer viruses can compromise a payment system by disabling the software agents

or even tamper with application data. Consequently sensible data should not only be protected when

transmitted but also when stored in the computational device. Although viruses are not a major concern in

mobile devices as in computers, Phage and LibertyCrack viruses are examples of malware that infect

PalmOS systems [6][17], and the Cabir virus, although harmless, can infect devices running the Symbian

operating system and be passed to other devices via Bluetooth [53].

• Trojan horse – A Trojan horse is malware that appears to perform a desirable function but in fact performs

undisclosed malicious functions, such as allowing remote access to the device, hence the analogy with the

Greek stratagem applied during the Trojan Wars [6]. If a virus present in a mobile device can alter data, the

presence of a Trojan horse is even more problematic as it can transmit the sensitive data to the attacker,

thus encryption should also be applied to it [3].

• Key-logging – Key-logging refer to a method of capturing and recording user keystrokes, nowadays also

mouse operations. Key-loggers usage can be legit, if the user knows his actions are being captured, for

tracing operations as a debug method. However they can be also used without user knowledge in order to

capture passwords or encryption keys. Key-loggers can be based on software programs or hardware

equipment, the last is not easily adapted to mobile devices, however spying software can be present at

mobile devices. Home banking solutions usually overcome this threat by enforcing a changing virtual

keyboard [3].

• Buffer overflow – A buffer overflow is an anomalous condition where a process attempts to store data

beyond the boundaries of a fixed-length buffer, the result is that the extra data overwrites adjacent

memory locations, which may cause erratic program behavior. Buffer overflows can be triggered by inputs

specifically designed to execute malicious code or to make the program operate in an unintended way [3].

31 State of Art

Physical attacks

Even if no technologic attack is possible, due to security solutions, criminals may also assault the client physically in

order to obtain the payment tool, as described in the following attacks:

• Equipment theft – Every object can be stolen, however mobile devices, due to their nomadic nature, are

more prone to theft, thus allowing the thief to use every mobile service present in the device, from voice

services to payment solutions.

• Software agent copy – If an attacker has access to the mobile device, even for a short period, and with or

without client knowledge, he may copy the payment software agent and later use it to conduct payments.

Although this threat is different from equipment theft, in what the payment tool is concerned, it has similar

risks, the unauthorized usage of the payment tool and thus the same solutions should apply.

• Physical coercion – An assaulter instead of just stealing the mobile device can actually coerce the client to

give all the required passwords to use the system, he can also force the client to perform payments in his

behalf. There are little technological solutions in such cases, thus such criminal behaviors should be

discouraged by strong police enforcement.

Social engineering could also be very successful attack against any kind of security system, as it depends on the

individual humans and their trust to each other. Attacker usually impersonates to someone else and tries to ask

passwords and other critical information. Humans are usually the weakest link, system users should understand and

verify the information that the protocols and systems are presenting to them about the on-going situation and based

on this information they should make correct decisions [56]. Hackers and attackers will always exist, therefore new

security threats and holes will constantly appear. All of today’s security solutions will need to be continually updated

to remain effective, they will need patches, upgrades, support and perhaps replacement to provide the same

amount of value tomorrow [16].

Security Properties

An effective security methodology must deal with an extensive list of security properties. It is the adequate

combination and interoperation of security properties, together with time-proven designs, that provide the usually

required resiliency of a secure system, which should not collapse when subjected to an attack or fail silently leaving

no trace of the attack [16]. These security requirements are defined by the security risks previously analyzed. A

secure mobile payment system should have the following properties [16][17][56]:

• Confidentiality or privacy – Sensitive data must not be available or disclosed to unauthorized individuals,

entities or processes, thus preventing eavesdroppers or interceptors from understanding the secret

communication. Privacy is accomplished using cryptographic encryption and decryption computation,

making the data only understandable for decryption key holders.

• Integrity – Information and systems should not be altered or corrupted by outside parties, mobile software

agents can however be signed thus ensuring that they are not tampered. Besides application data, also

transmitted messages should not be altered accidentally or maliciously without being detected at the

receiver side. Integrity is achieved with message-digest schemes and digital signatures.

32 State of Art

• Non-repeatability – Even if an eavesdropper cannot understand transmitted messages and a man-in-the-

middle cannot modify them, an attacker can repeat a message or the entire captured communication in

order to assign more expenses to client or simple use the messages to perform a DoS attack. Hence each

message and each communication session should not be repeatable.

• Authentication – Authentication ensures that each entity is who claims to be, thus disabling impostors from

participation in the payment process. Before business transactions can be performed, the participating

entities must confirm the identity of each other. Authentication prevents an unauthorized third party from

masquerading as one of the legitimate parties, therefore disabling the man-in-the-middle attack. Merchants

need a way to verify that the client is a legitimate user of a valid branded payment system, while clients

must confirm that the merchant has a relationship with a financial institution allowing it to accept payment

cards [3].

• Authorization – Even if someone is who he claims to be, that does not mean that he is able to conduct

payments, the payment transaction must be authorized. Access control is typically imposed in secure

systems, granting access to objects, operations or places to authorized users, processes or systems,

accordingly to access privilege. In payment systems the client account is usually verified for enough balance

to commit the transaction. This authorization is performed by the merchant with his acquirer given the

client payment instruction.

• Non-repudiation – Non-repudiation is about providing proof that a particular act was actually performed,

preventing the ability to deny it. Mobile commerce transactions are official business deals, neither the

sender nor the receiver should be able to deny the existence of a legitimate transaction afterwards, that is,

the receiver can prove that the specified sender did send the message. A historical log with all m-commerce

actions must be maintained thus enabling auditing.

• Availability – The system must be accessible for authorized users at any time, the availability of a mobile

commerce system ensures that legitimate users can access the business service. DoS attacks should be

minimized because they can cause mobile commerce services to become unstable or unusable for long

periods of time.

Cryptography

A cryptographic algorithm, also called a cipher, is the mathematical function used for encryption and decryption. The

input of an encryption algorithm is known as plaintext, or cleartext, if the data is comprehensible to a human being;

while the output is identified as ciphertext. Modern ciphers include a key as part cryptographic algorithm, a key is a

parameter for both encryption and decryption operations and determines the functional output of a cipher, the

range of possible values is called the keyspace. Keys are also often easier to protect than an encryption algorithm,

and easier to change if compromised. Thus, the security of an encryption system in most cases relies on some key

being kept secret. Generally, there are no absolute proofs that a cryptographic technique is secure; at best, there are

proofs that some techniques are secure if some computational problem is difficult to solve [6]. However there is a

proven unbreakable cryptographic algorithm, one-time pad cipher is considered unbreakable, provided the key

material is truly random, never reused, kept secret from all possible attackers, and of equal or greater length than

the message [6][11].

33 State of Art

Symmetric-key algorithms

There are two general types of key-based algorithms: symmetric and public-key. Symmetric algorithms are

algorithms where the decryption key can be calculated from the encryption key and vice versa. In most symmetric

algorithms the encryption key and the decryption key are in fact the same, these algorithms are also called secret-

key or single-key algorithms [11]. The secret key must be shared by the sender and receiver of a security session. The

sender encrypts messages using this key and then sends it over to the receiver through the public network. To agree

upon this symmetric key requires both sides to use out-of-band channels, or a specially designed key distributed

center. Nowadays the most commonly used symmetric-key algorithm is AES, not only it is considered secure but also

has a worldwide implementation.

Asymmetric-key algorithms

Asymmetric-key algorithms, also called Public-key algorithms, are designed so that the key used for encryption is

different from the key used for decryption. Furthermore, the decryption key cannot, at least in any reasonable

amount of time, be calculated from the encryption key [11]. The key pair includes a public key and a private key,

while the public key can be made public and transmitted over an untrusted network, the private key must be stored

in a safe place. Thus unlike symmetric-key algorithms there is no need for an initial phase of secret keys exchange,

although it is still necessary to send a key, it is a public key, which anyone can see. Although public-key cryptography

overcomes the key distribution problem, trust issues still remain. It must be assured that the public key belongs to

the person or entity claimed, and has not been tampered with or replaced by a malicious third party, or else the

sensible data may be sent to undisclosed recipients. The usual approach to this problem is to use a public-key

infrastructure, which will be discussed further ahead [3].

Public-key cryptography can be used for two different applications, accordingly with which key of the key pair is used

to encryption. In Public-key encryption, messages are encrypted with the recipient's public key and cannot be

decrypted by anyone except the holder of the matching private key. On the other hand, in Digital Signatures, the

message is signed with the sender's private key and can be verified by anyone who has access to the sender's public

key [6]. Public-key cryptographic algorithms may be suited for key agreement, key transport, encryption or digital

signatures. While some algorithms are designed with a single propose others can be applied in different applications,

moreover any encryption protocol is typical suitable for key transport [11].

Public-key encryption algorithm is a much less efficient encryption technique than any symmetric key algorithm, by a

factor of 100 or more, therefore it is not a good choice for encryption of bulk data [11]. RSA is the de facto

asymmetric-key standard and is used worldwide in several solutions, both for encryption and digital signatures.

Digital Signatures

Digital signatures are another application of public-key cryptography. A digital signature, like a conventional

handwritten signature, identifies the person signing a document. Properly implemented digital signatures are more

difficult to forge than the handwritten type, because it contains encrypted information that is unique to the signer

and is easily verified. For messages sent through an insecure channel, a digital signature gives the receiver reason to

believe the message was sent by the claimed sender, therefore providing authentication of the signer. Also, any

34 State of Art

change in the message will invalidate the signature, thus digital signatures also impose message integrity. There is no

efficient way to modify a message and its signature to produce a new message with a valid signature, because this is

still considered to be computationally infeasible by most cryptographic algorithms Digital signatures can also provide

non-repudiation services, given that a public key infrastructure is used, so that certificate authorities maintain a

certified public repository of public-keys and associated private-key [3][6]. A common algorithm for digital

signatures, which include the digest function, is illustrated at Figure 13.

Figure 13 – Digital Signature algorithm

Public Key Infrastructure

Public-key cryptography enables secret key transport, encryption and message authentication. Nonetheless, to

guarantee these properties, it is necessary to be sure that the public-key really came from who claims it, or else the

authentication may be forged and the encryption may be disclosing private data to an unintended third-party. A

public-key infrastructure (PKI) is a set of policies and procedures that bind public-keys to entities, hence identifying

the owner of a public-key. The tamperproof binding is achieved through the issuing of digital certificates, which

incorporates a digital signature to bind together the public-key and the identity information, such as the name of a

person or organization. Public-key infrastructures must also provide means for public-key certificate validation and

revocation services, thus enabling ongoing management of keys in a distributed system. A PKI relies on a trusted

third party (TTP) to distribute the digital certificates and authenticate the identity of the party associated with the

corresponding key pair [3][46][47].

A public-key infrastructure is composed by Certification Authorities (CA), Registration Authorities (RA), repositories,

and archive. The users of a PKI are certificate holders and relying parties, which receive and wish to validate

certificates. The certification authority is the trusted third party between the users of a PKI, the certificate holder and

the relying party. Once users establish that they trust a CA, directly or through a certification path, they can trust

certificates issued by that CA. The CA may delegate certain functions to the other components of the infrastructure,

for example, the registration authority is an entity that is trusted by the CA to register or vouch for the identity of

users to a CA [3][11][46][47]. An overview of the PKI entities is depicted in Figure 14.

35 State of Art

X.509 is a standard for a public key infrastructure. X.509 specifies, amongst other things, standard formats for public

key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm

[6][11][47].

Figure 14 – Public key infrastructure

Summary

Each cryptographic technique solves a particular issue and enables a certain security property. Symmetric-key

encryption algorithms are suitable for bulk encryption of data, thus providing privacy, but are unable to guarantee

data integrity. Also, secret keys, used in symmetric encryption, must be shared in a secure way. Some asymmetric-

key algorithms are appropriate for key distribution, through asymmetric-key encryption, while Diffie-Hellman even

allows key agreement. However these algorithms are not adequate for bulk encryption and their key-pair should be

certified in order to be trustworthy. Public key infrastructures solve the certification issue and bind a public-key to an

entity. HMACs (Hash-based Message Authentication Code) and Digital Signatures impose message integrity and

authentication. With a trusted-third party, like a certification authority, digital signatures also provide non-

repudiation services [47]. Security properties achieved through cryptographic algorithms are resumed in Table 2,

while Table 3 shows the different applications of symmetric and asymmetric algorithms.

Privacy Integrity Authentication Non-repudiation

Symmetric-key encryption Yes No No No

Asymmetric-key encryption Yes No No No

Cryptographic hash functions No Yes No No

HMAC No Yes Yes No

Digital signatures No Yes Yes Yes (with TTP)

Table 2 – Cryptographic algorithms and security properties

Bulk Encryption Key Transport Key Agreement

Symmetric-key algorithms Yes No No

Asymmetric-key algorithms Not advised Yes Yes (Diffie-Hellman)

Table 3 – Encryption algorithms application

36 State of Art

Security Solutions

Mobile payment systems are not the first electronic payment systems available, thus the analyzed security issues are

not also new. Even several non payment systems have their security constraints, studying these solutions is a good

approach to industrial patterns with proven security properties. The TLS/SSL protocol [29][32] enables the

establishment of a communication channel that provides confidentiality, integrity, message authenticity, and replay

protection. However peer authentication and non-repudiation properties are not achieved. The SET protocol [3],

besides privacy and integrity, also provides entity authentication and non-repudiation through the usage of digital

signatures, though it does not take any step to prevent replay attacks and thus might be vulnerable to single

message or entire conversation repetition. On the other side the Kerberos protocol [6][38] achieve authentication

through the usage of tickets and a trusted third party, also providing privacy and non-repeatable properties, but not

message integrity.

The protection against replay attacks is not achieved by any cryptographic algorithm, but rather by the introduction

of a sequence number or timestamp in each message. This token must be protected from tampering, adding it to the

data that is digitally signed or passed through a cryptographic hash function. The receiver is responsible to verify the

value of the token and discard out-of-sequence or old messages. The entire conversation can also be retransmitted,

to protect from this attack, the sequence number should be global and not restarted in each conversation.

Availability is partly enforced by the use of public-key authentication, because one peer must identify himself before

the other commits any resources to it. However, authentication does not completely protect against the attacks

because the authentication protocols often leave ways for an unauthenticated client to consume a server’s memory

space and computational resources by initiating a large number of protocol runs and inducing the server to perform

expensive cryptographic computations. This can be address by forcing the client to solve cryptographic puzzles, like

the brute-force reversal of a one-way hash function, thus forcing the client to commit its resources before the

server, as proposed in [57]. Although the complexity of the puzzle may vary accordingly with the server load, this

type of solution penalizes legit clients that are trying to use the system, especially if they are using computing

constrained devices such as mobile phones. Moreover, even though with such approaches application-level

protocols may be protected, nothing is done to prevent exhaustion of communications bandwidth, which may

disable the system from a lower level. To minimize this, it should be applied, when possible, a firewall along with an

active policy of refusing unknown connections, through the use of network equipment with rate-limiting and access

control lists (ACL) capabilities [6].

One of the biggest impediments to the growth of mobile commerce has been a lack of consistency in security and

payment methods, and an absence of consensus on technology standards. Various wired or electronic commerce

security and payment methods have been modified and applied to mobile commerce, but experience shows that

simply adapting those solutions to mobile commerce is not feasible [17]. The SET protocol is the most adequate

protocol to use as a starting point to build a secure mobile payment system. However it implies processor intensive

cryptographic actions, which should be minimized, ideally without compromising security, due to the limited

capabilities of mobile phones. One improvement may be the elimination of public-key encryption in every

transmitted message, for securely distribute a symmetric key. For example, the TLS protocol negotiates a session key

37 State of Art

before the communication and reuses it to encrypt all transmitted messages, in that conversation. Although this

negotiation may include, like in TLS, cipher algorithm and key size agreement, it should not support ciphers or key

sizes with proven weaknesses, or else the entire security may be compromised.

38 WPAC Architecture

WPAC Architecture

This chapter details the WPAC open architecture, focusing on players’ roles and relationships. WPAC operational

protocols for purchase and clearing, along with solution’s lifecycle and technological stack are also described. But

first it is important to clarify the challenges, intended payment scenarios to address, and associated requirements.

Challenges

As described in the previous chapter, there is a widespread heterogeneity of technologies for mobile devices, both at

operating systems and wireless communication levels. It is extremely important that the proposed architecture seek

interoperability between different computational devices and technologies, this strengthens the open payment

solution, ensuring that any WPAC enabled payment agent can be used at any merchant adopting the system [17].

The design of an open architecture also makes the payment and access control solution a multi-vendor

infrastructure therefore reducing client’s technology dependence and minimizing the overall cost of ownership. Due

to the swift evolution of mobile technologies, especially wireless communication protocols, the architecture should

also promote technology independence, through a modular design, thus providing extensibility capabilities.

Many Mobile Network Operators are working in the area of m-commerce in order to provide value-added services

and generate revenues, thus there are lots of standards and approaches for m-payment which are running

independently. The existence of multiple independent solutions, which do not address integration with other

systems developed by other vendors, raises the need for a standard interface. M-payment is still being held back due

to lack of common standards and disparity of systems that do not necessarily work together, it is essential to find

common approaches, ideally defining a standard, both at national and international level [2].

For people to embrace the solution it should have an easy to use interface and simple usage scenarios, with

utilization steps similar to traditional payment and access control. The client should be prompted for payment

confirmation, like in conventional Pin Pads, and not for which value to pay for. Accordingly to the study on the

consumers’ consumption behavior, clients do not like to change their major habit and tend to adopt user-friendly

products, thus, usability is an important issue [17]. Dependability is also a key aspect. The system should be highly

reliable and/or provide countermeasures to allow the user to always make the payment or the identity proof. Even

so, third-party dependencies, like mobile phones batteries, will always bring a lower dependability, and their failure

rate must be added to the equation.

Usage scenarios

WPAC payment open architecture aims at allowing people to conduct their every day payments through the usage of

their mobile phones, however due to the technology dependence not all payment scenarios can be addressed. In a

supermarket, as depicted in Figure 15, customers usually shop by placing their selected merchandise into shopping

carts or baskets and pay for the merchandise at the check-out, where the merchant attends the payment at the cash

register. Most shops and supermarkets already enable credit card payments, this technology awareness is crucial for

the adoption of WPAC m-payment system. Today many supermarket chains are shifting to self-service check-out

machines, in order to further reduce labor costs, where a single employee can oversee a group of four or five


machines at once, assisting multiple customers at once [6]. This self-service payment machines are typically more

technologically advanced so the integration of m-payments systems can be done even more seamlessly, the

introduction of new machine can also be seen as an opportunity to support new payment schemes straight from

production. The support for WPAC payment solution includes the introduction of a Bluetooth antenna and a

microcontroller board, which communicate with the client and obtains the necessary clients’ credentials for the POS

to complete the payment.

Figure 15 – Supermarket payment scenario

Figure 16 – Vending machine payment scenario

Other unattended payment scenarios, like vending and ticket machines, include computational systems even though

some can simply include a currency detector and a product dispenser. These machines are also highly susceptible to

attacks, from the stealing of vending machines products and money to the violation of ticket machines in order to

get an excuse to miss payment. The integration of WPAC payment system brings two advantages, the reduction of

currency inside the machine and the increased strength against disabling attacks. A particular example of ticket

machines are the pay and display machines used for regulating parking in urban areas, which was the focus of the

WiMo project [12]. In a typical scenario, the costumer must go to the pay and display machine, pay the fee for the

desired parking period and display the printed ticket on the vehicle’s windshield. An m-payment system can replace

the currency payment step, but ideally it replaces also the necessary display of the ticket, the machine can record

the vehicles with a valid parking payment which the law enforcement patrol can check rather than search for a

displayed ticket, this usage scenario is illustrated in Figure 17.


Figure 17 – Car parking payment scenario

As referred before, not all payment scenarios can be addressed with a technology enabled solution, street vendors

will unlikely support m-payment solutions as they also do not generally support credit card payments, Figure 18

illustrates the purchase of food in a street vendor cart, but we can also rapidly imagine a flea market as another

place unsuitable for m-payments. Another type of unsuited payment scenarios are those were the usage of radio

frequency is prohibited due to interference hazards, places like gas stations, depicted in Figure 19, hospitals or

airplanes.

Figure 18 – Street vendor payment scenario

Figure 19 – Gas station payment scenario


Merchant attendance

The usage scenarios enumerated before show that the merchant does not need to be present at the payment site, in

the contemporary society more and more unattended vending machines are available. Although these electronic

payment machines imply a slightly different purchase protocol, as will be describe ahead, these scenarios are an

opportunity rather than a threat. In one hand, unattended POS are technology aware and thus facilitate the

integration of m-payment systems; on the other hand, these vending machines imply the client to take a more active

role in the purchase protocol, which is also mandatory in the WPAC m-payment system.

Payment amount

Payment characterization must include not only the payment places, type of products and services purchased,

merchant attendance, but also the payment amount. While some usage scenarios address payments from small to

high amount, others, typically unattended vending or ticket machines, are only prepared to deal with low amounts.

WPAC m-payment system is proposed to address all the following payment amount categories [62]:

• Micropayments – Payment amounts up to 2€ are considered micropayments. In urban scenarios this

payment type is frequent, from the newspaper or coffee in the morning, to the small snack in an afternoon

break, but also including subway and bus tickets, parking fees or even toll for short highway journeys. Most

people conduct more than a micropayment in a daily basis.

• Mini-payments – Micro-payments include amounts from 2€ to 20€. Some small payments are also

commonly performed with a daily frequency, for example when buying food at restaurants or

supermarkets; however they also cover less common purchases like a magazine, music record, or cinema

ticket.

• Macro-payments – Payment transactions above 20€ are classified as macro-payments. Ordinary people are

not expected to frequently conduct such payments to fulfill their everyday needs, thus macro-payments are

likely to take place in a weekly rather than daily basis. Typical usage scenarios include the purchase of

clothes, electronic appliances, gas, books and theater tickets. The purchases of expensive items like cars or

even houses are also macro-payments however such payments are more sporadic.

Architecture

Roles

The WPAC payment architecture follows closely the successful credit/debit card design in terms of player’s roles and

relationships. There are several credit cards brands, some of which are owned by a single financial organization and

others by bankcard associations, consortiums of financial institutions that promote and advertise the brand,

establish operating rules and provide a network for payment authorizations and fund transfer. In the proposed

wireless payment scenario the brand is the WPAC itself, which is responsible for defining the rules and procedures

for payments to occur. In the credit card architecture the client is the cardholder, in m-payments he is the mobile

device holder. The merchant, the issuer and the acquirer remain with their roles adjusted to the wireless payment

scenario [3].


IssuerAcquirer

Mobile Network

Operator

Client Merchant

Figure 20 – WPAC Roles

The main actors managed by WPAC are:

• The client is every person that holds a WPAC payment enabled nomadic device and uses it to conduct

payments.

• The merchant is the person or organization that has goods or services to sell to the client, he may the

person behind the counter or the company that owns the automated point-of-sale (POS) or vending

machines.

• The issuer is the company that provides the client the m-payment software agent and is responsible for the

payment of his debt. Issuers are typically financial institutions, such as banks.

• The acquirer is an organization that provides payment authorization and clearing services for merchants.

The merchant will normally want to accept more than one payment provider, allowing multiple financial

institutes to support the WPAC payment system. However merchants do not want to have to deal with

multiple institutions, they achieve this by using the services of an acquirer. In the WPAC architecture,

clearing services include electronic authorization support and electronic transfer of payments to the

merchant’s account. Like in typical credit card payment model, the acquirer will be paid by the merchant in

the form of a small percentage charge on each transaction.

• The mobile network operator is an entity external to the payment process, however it plays a role in the

WPAC system setup, working as a mobile communication provider between the client’s mobile device and

the payment provider. The payment provider relies on the mobile operator to deliver updates to the mobile

software agent. Mobile phone users have an account with the mobile network operator that may be used

not only to pay for communication services but in a broad vision to pay for other products or services, thus

the mobile network operator can itself act as a payment provider.

If the WPAC solution is implemented and is successfully used by clients, is advisable to create another organization,

an interest group formed by the stakeholders who defines and maintains the WPAC open specifications. This so

called WPAC Interest Group would be also responsible to identify and correct implementation issues and deliver new

improved software versions.


In order to support secure communications and to assure entity authentication a public key infrastructure is used, as

we will see ahead, this makes use of public key certification and therefore implies the existence of a certification

authority.

In an initial adoption phase, the payment provider and the clearing house can be the same entity, a financial

institution that develops and supports the WPAC solution, however ideally the WPAC architecture is implemented by

several financial institutions thus allowing for inter-bank money transactions. In the later case, the payment provider

may be one financial institution and the clearing house another, as shown at Figure 20.

Relationships

There are different inter-role relationships, which may be divided into three types: contractual relationships, that

represent agreements in law between the different parties to provide services and accept responsibilities;

administrative relationships, which are required to set up and maintain the WPAC environment but do not take part

in the payment process; and operational relationships that represent short-term relationships that take place when

a payment happens. Figure 21 illustrates these relationships.

Figure 21 – WPAC Relationships

The client must have a contractual relationship with the issuer, which defines the payment system acceptance and

includes all security tokens as well as the account from which the issuer debts the client. The client should also have

an account, an administrative relationship, with a mobile network operator so that he/she may receive payment

system related updates from the issuer. The inexistence of such account means that the client needs to go personally

to an issuer’s shop to perform all the required updates. In order to the issuer to push updates to the client, he also

must have a mobile network operator account. The merchant must have a contractual relationship with the acquirer,

on which he relies to execute payment authorization and clearing, performing electronic fund transfer to his

account.

Client

Issuer Acquirer

Mobile Network

Operator

Merchant

POS

Network

Software agent

Payment account

Local wireless communication

Mobile network

Local wireless communication

Network

Mobile account

Client account

Mobile network

Payment account

Merchant account

Issuer account

Mobile network

Client account

Mobile account

Operational relationship

Administrative relationship Contractual relationship


When conducting a payment, the client establishes an operational relationship with the merchant, accepting the

payment amount and sending the payment credentials, over the wireless communication protocol. The merchant

then sends the payment order to the acquirer through a dedicated network, and the operation concludes with the

electronic fund transfer from the client’s account to the merchant’s account. The actual fund transfer can occur at a

later time given that the payment is previously authorized.

Purchase Protocol

The Purchase Protocol is an essential protocol in the m-payment solution. It defines the iteration between client and

merchant, including the manual operations involving client and mobile device and linking merchant and point-of-sale

(POS), but also the wireless communication between the mobile device and the POS. In certain scenarios the

merchant is not present and thus the purchased protocol only includes client, mobile phone and POS.

Figure 22 – Client-Merchant Purchase Protocol

The client-merchant purchase protocol, depicted in Figure 22, defines the payment procedure when the merchant is

present at the POS. In order to the client use the WPAC payment method, he should ask if the WPAC payment

protocol is supported by the merchant, or search for the WPAC logo in the list of available payment types. The same

lookup procedure has common in the early days of credit and debit cards, but nowadays most common credit/debit

card brands are ubiquitously available. With the confirmation of the WPAC support, the client may start the mobile

software agent, which validates itself in order to guarantee the integrity of the payment agent. Further details about

security and validation will be discussed in the chapter WPAC Security chapter. The software agent running on the


mobile device will then communicate with the POS, which should be always running or at a low-power sleep state

wakening upon message delivery. The mobile agent request the payment data, which includes everything necessary

to payment validation by the client, this includes the payment amount, optionally the list of products with partial

costs, and the merchant identification. The merchant identification enables the client to confirm that he is paying to

the right entity, this identification is important due to the payment’s wireless nature. At this time the merchant

should insert the payment amount into the POS, if not collected earlier by the scanning of products’ barcodes. When

the mobile software agent receives the payment data it displays it on the device screen, thus enabling the client to

view and approve the payment. The software agent then evaluates the risk for the current payment, accordingly

with the amount, time and place, and requests the appropriate set of credentials to the client. More detail on risk

assessment can be found in WPAC Dynamic risk assessment chapter. When the client complies with the request, and

after validation of the credentials, the mobile agent sends the payment confirmation to the POS, including the

necessary data to authorize the payment. The POS delegates the authorizing step in the acquirer, as will see ahead,

and upon success informs the merchant and sends the payment receipt to the client.

Figure 23 – Client-POS Purchase Protocol

The client-POS purchase protocol, illustrated in Figure 23, which defines the payment procedure when there is no

merchant present and the POS is fully automated, is quite similar to the previous procedure, with the difference that

there is no interaction with a person. In a typical scenario the client will need to select a product from a vending

machine, thus determining the payment amount. The payment authorization is performed in the same manner, but


the result is only saved in an audit log, not shown, on the merchant side. Further detail on the data model used in

the purchased protocol will be presented in WPAC Implementation chapter.

Clearing Protocol

The clearing process is responsible to determine if the client is able to commit the payment, checking the account

status and balance, and for actual fund transference. The clearing protocol is a fundamental part of the payment

solution, however because WPAC reuses the credit/debit card payment clearing scenario no architecture or

implementation will be further detailed, thus setting the focus of this work to the purchase protocol. Furthermore,

accordingly with the payment scenario there are different agreements for credit/debit card clearing services, for

example in low value toll payments the PIN introduction is not mandatory, in some fuel payments the magnetic card

and PIN are provided before the gas is actually pumped into the vehicle, while in most merchandise purchase this

only happens when the items are checkout at the POS. Thus the exact details of the clearing protocol will depend on

the agreement upon merchant, acquirer and financial institute or banking network. Even so, the WPAC considers the

existence of a two-step clearing protocol, the first step for payment authorization and the second for monetary fund

transfer, although these two logical steps can be grouped in one request to the acquirer. In the purchase protocol,

after the merchant’s POS receives the payment confirmation message from the client’s payment agent, it sends the

authorization request to the acquirer, as detailed in Figure 22, the capture request can be sent after the purchase

protocol completion and merchandise delivery.

Figure 24 – Clearing Protocol

Lifecycle

The mobile software agent, like any product, has a lifecycle. However in this project more than the commercial

success or total product curve it is important to identify the necessary setup to install the operational environment.

The payment protocol also has typified phases that describe the necessary steps of an electronic payment

transaction.


Software agent lifecycle

The lifecycle of a software application starts with the analysis, design and development of the agent. The analysis of

the solution requirements and subsequent design is detailed by this document, a proposed implementation is also

provided. Due to the trust issues of a payment agent, it is necessary to sign and certify the application before

distributing it, thus the authenticity and integrity of the software agent can be verified by the client at installation

time. The mobile software agent is then deployed at an online repository, the deployment server, which should be

maintained by the issuer or a trustee. When the client wants to join the WPAC payment protocol, he/she should go

to the issuer’s website or physical shop and request the application to be downloaded to his mobile device. The

software agent can be installed locally over a serial cable or deployed Over-The-Air (OTA) [60] depending on the

internet access, which is typically provided by client’s mobile network operator. Moreover, in OTA deployment, the

client browses the internet for the MIDlet suite link, or receives the link via a WAP Push message, which is opened

and downloaded by the Java Application Manager (JAM) [60]. The client should verify if the code signature match a

trusted entity, in this case his WPAC issuer, and proceed to installation. Upon completion the client is able to use his

mobile device to conduct m-payments. The POS software agent also has a developing phase, however the

application is not available at a deployment server but rather installed in the POS device when the merchant adhere

to the WPAC system.

Figure 25 – M-payment solution lifecycle

Payment phases

In a payment transaction, there are usually four stages, including set-up and configuration, the initiation of the

payment, authentication, and completion of the payment [17]. The necessary environment to conduct payments is

configured in the set-up phase, including the establishment of the contractual relationships and installation of the

software agent in the mobile device. Set-up and configuration could take place over a mobile network, making use of

the administrative relationships, or they can be done physically. The payment initiation phase matches the initial

part of the purchase protocol, where the payment information is transmitted to the merchant over the wireless

network. The authentication of the client is essential for any payment transaction, it takes place during the

authentication phase, where the merchant validates the client credentials and the acquirer authorizes him to

perform the payment. The payment completion phase occurs after the client’s details have been authenticated and

the transaction is authorized, and includes the transmission of the digital receipt to the client.


Technology Stack

The purchase protocol is implemented by a technology stack, depicted in Figure 26, which provides all the necessary

functionalities, including wireless communications and cryptographic operations, and defines the interface both at

user and network level. The first level, the communication layer, includes the necessary infrastructure to provide

communication between client’s mobile device and merchant’s POS. On the second level, resides the contract layer,

which defines the network interface and common language for the distributed systems, mobile device and POS, to

understand each other. The session layer is responsible for everything necessary in a session of the purchase

protocol, basically includes the security measures for a secure data transmission. Finally, on top of the technology

stack is the application layer, which match the software agent implementation and user interface.

Figure 26 – Technology Stack

Communication layer

As discussed previously, the chosen protocol to provide wireless communication is Bluetooth, NFC would provide a

richer usage experience but it is not yet available in mainstream mobile phones in Europe. In top of the Bluetooth

stack resides the RFCOMM and OBEX protocol, which provide respectively an emulated serial communication and

object transference channel. The communication layer includes all the technologies, protocols and libraries

necessary to create a communication channel and make it available to the upper layer. The communication layer

also abstracts the above layers from the communication logic this modularity enables an easier communication

protocol exchange.

Contract layer

The contract layer defines a common language and data representation between systems. Web Services were

chosen due to simplicity and usability, SOAP (Simple Object Access Protocol) messages, which are merely XML-

formatted text messages, can be transmitted over most communication protocols and pass through firewalls. Web

Services enables implementation abstraction and a loosely coupled system, also modeling the solution into a Service

Oriented Architecture (SOA) [6], which promotes reusability and composition of services through service

orchestration. The definition of the purchase protocol by a WSDL contract, enable the division into functional

building-blocks of the payment service, which can later be used in evolutions of the purchase protocol, for example


including ticket emission for access control. The purchase protocol is divided in two web service methods, the first to

retrieve the payment data and the second to actually perform the payment, although the first method can be

skipped in some situations, like in the Client-Merchant Purchase Alternative Protocol as we will see ahead, typically

the two are called in a execution of the Purchase Protocol. The payment data is sent by the merchant to the client

but must also be maintained in the POS in order to keep track of pending payments, thus the Web Service is not

entirely stateless, although this data already existed before the first call to the web method and is not a result of it.

Session layer

The session layer is responsible for every artifact necessary for the execution of the purchase protocol. This includes

mostly the cryptographic suite for a secure transaction, which architecture is detailed in chapter WPAC Security. The

cryptographic tokens, XML Encryption and XML Signature, are included over the SOAP message through the usage of

the WS-Security specification [6].

Application layer

The application layer includes the software agent actual implementation, including the user interface. Both the

mobile software agent and the POS application are implemented in Java. In the chapter WPAC Implementation this

topic will be discussed further.

Dependability

Any electric appliance is intrinsically dependent of electricity. Mobile devices have increased energy dependence

due to their nomadic nature which disables typical power cord usage and imply the utilization of batteries. These

batteries must be recharged at a power outlet and desirably their charge last all day or the amount of time the user

needs. If the payment tool is out of power there is little it can be done to perform the payment. The client is

somewhat responsible to keep the mobile device battery with enough power, when he wants to make a call, his

mobile phone must also have energy. Batteries and mobile phone chargers are evolving providing greater energy

capacity and faster charging times, also more and more charging possibilities are emerging, from car mobile chargers

to public charging stations at shopping centers, where the user can freely charge his mobile phone in exchange of

some publicity visualization [23].

Mobile payment systems uses mobile devices wireless communication capabilities, from mobile network

communications like SMS or GPRS, to local communications as Bluetooth. The usage of mobile network

communication protocols introduces a dependence of the mobile network operator, with his failure rate being

added to the payment system failure rate. Besides, transmissions will only be enabled if the mobile phone is in reach

of an operator antenna. In the proposed solution, the payment procedure relies essentially in local communication

technologies, mobile network communications will only be used occasionally to perform mobile software agent or

payment system data updates, thus reducing the dependence. However although Bluetooth or other local

communications technologies are not dependent of an external entity, they may also be affected by a noisy radio

environment, if the noise level is high enough it can be disabling, avoiding the client’s mobile software agent to

communicate with the merchant’s POS. Thus, several communications protocols can and should be supported, in


order to provide higher noise resilience due to the combination of different protocols that may be differently

affected by radio noise. If none of the supported local communication technologies can establish a successful

connection, an alternative method should be defined to raise the payment tool dependability and inherent client’s

payment system trust and acceptance.

Indicate sucess

Show barcode

Annouce payment amount

Request payment amount

Acknowledge WPAC payment support

Ask for WPAC payment support

Start midlet

Request payment data

Notify failure

Enter credentials

Authorize payment

Show sucess

Insert amount

Validate midlet

Risk assessment

Request credentials

Validate credentials

Request amount

Generate barcode

Instruct to

show barcode

Close agent

Figure 27 – Client-Merchant Purchase Alternative Protocol

The payment process includes two transmissions between the mobile software agent and the POS, as shown at

Figure 22, the first one is to exchange security tokens and obtain the payment amount while the second is to confirm

the payment, sending the client’s account number and PIN to the POS, and receive the receipt. When the connection

cannot be established, communication security related tokens do not need to be exchanged and the payment

amount must be introduced by the client himself in the mobile software agent. Credentials introduction and

validating step occurs in the same way, after that a 2 dimension barcode is generated by the mobile software agent

that includes the client’s account number and PIN. The client is instructed to show the 2D barcode, which is being


displayed at mobile device screen, to the POS 2D barcode reader. The POS reads the barcode and submits the

payment order, upon payment confirmation the merchant receives the success message and indicates it to the

client, which in turn acknowledges the payment success in the mobile software agent. This alternative payment

process, depicted at Figure 27, forces the client to have a more active role, introducing the payment amount and

approaching the POS to show the 2D barcode, however it is the available solution when no wireless communication

can be established. The client can refuse to perform such actions but it that case the WPAC payment system will be

unavailable. This solution also obliges the POS to have a 2D barcode reader, once again if the merchant is not willing

to support this alternative payment procedure the payment system will be disabled when radio noise avoids the

communication. 2D barcodes usage is rising and the m-ticket solution, discussed previously, is such an example.

Another approach to deal with local communication failure is through the usage of mobile network communications

like GSM, SMS or GPRS. In this case, the Purchase protocol remains the same, only replacing the technology used at

the communication layer. However, one of the WPAC objectives is to provide an operational fee free payment

solution, hence the main focus of the alternative protocol is to keep that paradigm.

Besides the mobile device energy and local communication issues, the payment system also relies on a

communication from the POS to the acquirer, and from acquirer to issuer, for authorizing the payment and debiting

the amount. If this network is unavailable the payment cannot be concluded, a similar situation occurs with credit

card payments. Although this is another dependence which may increase the failure rate such problems are

uncommon, also if the payment tool supports more than one payment provider the problem can be mitigated as

when we use another credit card brand to make the payment.

52 WPAC Dynamic risk assessment

WPAC Dynamic risk assessment

Risk assessment is the determination of quantitative or qualitative value of risk related to a concrete situation and a

recognized threat [6]. In traditional payment scenario, dealing with currency, the main threat is the currency theft.

This can occur from the moment a person perform a cash withdrawal at an ATM to the actual purchase of a product

or service, and any time in between when a person carries the currency in his wallet. With electronic money, debit or

credit card theft is not by itself a monetary theft because the magnetic stripe card does not really have any intrinsic

value and to pay for products or withdraw money from an ATM it is usually necessary the PIN introduction or the

person signature. However credit/debit cards lack of intrinsic value does not means that people should not be

concern if their electronic payment tool is stolen, in fact they should report the theft as soon as possible, the burglar

can somehow acquire the PIN code, fake successfully the signature, or simply use the card in POS that do not require

the introduction of credentials. Another risk is the coercion of the cardholder by brute force or gun point to

withdraw cash or buy products for the robber.

In a wireless payment system, besides the theft of the payment tool or physical coercion, other threats exist due to

the wireless communication nature. An eavesdropper can capture the communication or an attacker can

impersonate merchant’s POS and commit the monetary transaction in self benefit. Security protocols mitigate these

risks by enforcing integrity and privacy to the wireless communication. Although the security schemes enables a

technological attack resilient system, there is little that they can do against physical attacks, the payment tool theft

and client coercion, as referred before, therefore the risk assessment will focus on these threats.

Theft and coercion are a type of crime more probable to occur in dark alleys in the middle of the night, than in a

crowded street in the middle of the day. Hence time and place are two factors that influence the risk level. Even

though the theft can take place in a dangerous neighborhood, the stolen mobile device can be carried to a safer

place to perform the purchase, thus avoiding a high risk assessment. The mobile agent only evaluates the risk at the

payment moment, not on every street the carrier may pass, nevertheless it is expected that thieves prefer not to use

the stolen mobile device in public places, as they will never know if the mobile device is already referenced as stolen

and if the police is following it. Physical coercion is also improbable to occur in crowded places were bystanders

could help the victim and neutralize the attacker.

Besides time and place, the payment amount is a crucial factor for risk assessment. Typically burglars should not be

interested in stealing a mobile device to make small payments, since their goal is to achieve the greatest income

possible. Also if the fault of a compromised payment falls on the issuer and it has to reimburse the client with the

amount spend, the bigger the amount the lesser the risk the system provider is willing to accept. Repetitive

payments of low amounts can be considered an attempt to spend a big amount disguised in small parts for a lower

risk, thus the same considerations apply. Therefore the overcome of a threshold value daily should increase the risk.

A similar approach in followed in ATM with a limited of money that can be cashed-out daily.


Risk categories

The risk assessment should determinate the value of the risk associated with each payment, considering the threats.

Although the risk evaluation can determine a quantitative value it should be mapped into a qualitative value group

that defines the mandatory credentials requested to the client. WPAC supports six risk categories, which is

considered more than enough to qualify the risk because even for military proposes, like United States Armed Forces

readiness level DEFCON, five levels were considered sufficient [6].

As depicted at Figure 28, risk levels range from low risk to prohibitive risk, with the later one representing payments

with such a dangerous level that are disabled. Associated with each category is defined a quantitative risk value

interval, which spans from zero to twenty and is evenly distributed between the low risk and very high risk

categories, as detailed in Table 4. The prohibitive risk level accommodates all payments with a risk value above 20.

This approach, although it does not define a maximum quantitative risk value, allows that the issuer defines a risk

factor as payment disabling without caring about the relative risk presented by other factors. It would be possible to

define different intervals for each category however this distribution only defines a reference scale, the relative

weight of each threat, and the inherent risk category the payment falls on, should be defined accordingly with issuer

requirements.

Low

Risk

Normal

Risk

Increased

Risk

Prohibitive

Risk

High

Risk

Very High

Risk

20 0 16 12 8 4

Figure 28 – Risk Levels

Risk level Value interval

Low Risk [0 , 4[

Normal Risk [4 , 8[

Increased Risk [8 , 12[

High Risk [12 , 16[

Very High Risk [16 , 20[

Prohibitive Risk [20 , ∞[

Table 4 – Risk levels values interval

Low Risk

The low risk level is intended to cover micropayments carried out in public places at day time hours, where the risk

should be minimal. For these payments, with a small risk associated, the client can be allowed to perform the

payment without entering any credential. Although this might sound dangerous there are working examples, like in

toll payments, were the client only presents their credit/debit card without providing the PIN or signature.


Normal Risk

The Normal risk category is planned to include micropayments with a greater associated risk, by the repetition of

micropayments or due to a more dangerous time or place where the payment is being carried out. Small payments

or even macro-payments can be enclosed in this level if no other risk factor is present. In payments with a normal

risk, the client must introduce his PIN (Personal Identification Number) code as a security and authorization

measure. This PIN code will be sent to the merchant’s POS that resends it to the clearing house attached with client’s

account number as part of the payment order.

Increased Risk

The following risk level includes more security measures because it is assigned to cover payments with an increased

risk, payments with an evaluated risk above normal fall in this category. Besides the PIN code it is also required that

the client specified his password. In addition to the increased security associated with two code introduction, the

password can overcome the short numeric code limitation of the PIN code. Although brute force attacks are not a

serious threat due to the limited error attempts, it is more likely to someone guess by pure chance a shorter code.

High Risk

The high risk category is intended to cover big macro-payments or smaller payment values with increased risk. In

addition to the security credentials required in the previous level, in this category the client must present biometrical

credentials. This obligation requires that the client must be present at the payment moment. Any mobile phone has

implicit voice analysis capabilities, allowing the authorization through this biometric characteristic.

Very High Risk

For higher risk payments it is defined the very high risk level. This group includes the more unsafe payments that are

authorized by the issuer, hence all the available security credentials should be asked to the client. Besides the

credentials requested in the high risk category, other biometric characteristics should be processed including, for

example, iris recognition.

Prohibitive Risk

The prohibitive risk, as referred before, disables the payment. The issuer can disable payments for very high values.

Security credentials

With the increase of the assessed risk level more credentials are requested to the client in order to make the

payment. As seen before and illustrated at Figure 29, higher risk categories include all the credentials of lower risk

levels and introduce a new credential in order to raise the security. Other solution would be to replace the

credentials asked and only request the new one, for example the high risk level could only use the voice analysis and

dismiss the PIN or password introduction, however the high risk nature of the payment justify the increased security

achieved with the introduction of several security credentials. Also it is expected that high risk payments are not

frequent, thus the annoyance of having to introduce several credentials is minimized.


The PIN and password credentials work essentially the same way, they are codes that only the client should know

and use to confirm and authorize a payment. The inclusion of the two is not redundant, as might appear, while the

password has increased security, the PIN code is also used by the merchant to authorize the payment order, thus it is

required. The password could somehow contain the PIN number, however this solution would force the password to

be generated, not chosen by the client, and consequently of difficult memorization. Moreover the utilization of two

codes is always more secure than a single one, if one code is compromised the other still protects against

unauthorized payment.

Figure 29 – Security credentials and risk levels

PIN

The PIN (Personal Identification Number) code functionality is well-known by the most people. Two notorious

applications are the debit card payment and the mobile phone SIM card activation. The four digit code is therefore a

common security measure to confirm payments, and it is no exception for this wireless payment system. There is a

myth that entering the PIN backwards at an ATM would generate an alarm to the police [21], although this is not

true for ATMs it could be easily true for our m-payment system, the only problem would be to know how to deal

with palindrome PINs, symmetrical code numbers like 1331. There is some concern about introducing the PIN code

in public places, in fact most Pin Pads do not physically prevent that a bystander watch the code introduction. A

possible solution is to define the PIN code as a pattern rather than a fixed numerical code [61], in this approach the

client watches a screen with random positioned digits and introduces the ones matching his positional pattern,

because the screen has duplicated digits, knowing the digits inserted does not reveal the code pattern. However this

solution implies the replacement of current Pin Pads by more sophisticated and expensive ones. In WPAC, mobile

phones replace Pin Pads as the place where the PIN code is inserted, because mobile phones are computing devices

with an embedded screen, the adoption of a pattern PIN code solution is easier, yet all the solution needed to be

changed, including the clearing protocol between merchant and acquirer, breaking the compatibility with existing

protocol. The introduction of the PIN code in a mobile phone also reduces the chances of capture, mobile phones

have smaller digits and may be used more close to the client and thus more distant of bystanders.

Password

Passwords are also a known feature for computer and web users. In this case the introduction of the correct

alphanumerical code enables the payment. The client selected password should be considered secure, with a


minimum of eight characters, the mandatory inclusion of letters and numbers and the exclusion of dictionary words.

These requirements for secure passwords generally turns the guessing attempts more difficult even for people that

know personal details about client. For an increased security this password must be changed yearly if not

compromised sooner. The PIN and the password have a limited error attempts. If a user fails to give the correct PIN

or the correct password three times the payment tool will be blocked and no one will be able to make a payment

without contacting the issuer and justifying the reason.

Voice analysis

Voice analysis is the first biometrical characteristic considered because of the inherent voice processing capabilities

of a mobile phone. Biometrical credentials are a good security measure because they require the presence of the

client, disabling a thief to use the payment agent. However they are not the first credential choice due to the effort

required to process the physical characteristic which is significant for limited devices as mobile phones. The client’s

voice should be analyzed to identify distinct acoustic patterns that reflect his anatomy, size and shape of the throat

and mouth; and learned behavioral patterns, voice pitch and speaking style. As for all security credentials, the client

must provide the credentials at the time he joins the m-payment system in order to they be included in the mobile

software agent, for later comparison at credentials validation time. Although this step is quite trivial for PIN and

password credentials, the voice recognition requires a more complex training with the speaker's voice being

recorded and a number of features extracted to form a voice print. This security feature should force the client to

pronounce a random word of phrase generated by the mobile software agent at each time, in order to disable the

reproduction of a fixed word pronounced previously by the client and recorded by an assaulter. Finally if the voice

processing could also perform a stress analysis it might detect the client coercion and notify the authorities.

Iris/face recognition

Iris recognition is another biometric feature that can be processed by mobile devices with embedded camera,

although some of these cameras might have small resolution and face recognition might be more adequate. This

recognition relies on image processing, analyzing and detecting contours, patterns and colors. Although the presence

of a camera is now ubiquitous for recent cell phones some older models might not have it, in this case and in the lack

of alternative biometrical measures very high risk payments might be disabled.

Recent laptops models are starting to include fingerprint readers, if the same trend reaches to the mobile phones it

would enable another biometrical feature that could be explored for wireless payment authorization.

Risk factors

As announced before, the amount of payment, the time and place where it takes place and the existence of several

others payments performed in the same day constitute the risk factors that are evaluated for the payment risk

assessment. Each risk factor contributes with a score that it be summed to obtain the risk value. Next we will detail

exactly how the risk value of each threat is determined and their relative weight.


Payment amount

Accordingly with the value, the payment can be classified into different categories

2€ it is considered a micropayment, small payments range from 2€ to 20€ and over

payment. This division is somehow inadequate for macro

associated risk of paying just 21€ or for example 2000€. Therefore the macro

we choose to maintain the geometric progression and defined two boundaries at 200

macro-payments into three fractions, as shown in

Micropayments match very small payments where the risk is minimal. When the client buys a candy at a vending

machine or pays for a newspaper, he is performing a micropayment, as long as the value in kept under 2

little risk in these payment operations, so for micropayments the risk calculation contribution is null. If the client

wants to buy a small meal, around 10

still a low risk payment as long as there is not pre

risk calculation, which is the upper integer bound of the low risk payment level.

payments between 20€ and 200€, for example when the client goes to the supermarket, to the restaurant, or when

he wants to buy a couple theater ticket. These payments have an increased risk associated due to the higher

payment amount and for that reason it gives 6 points to the risk calculation, meaning that it will be at best a

payment with a normal risk level which requires PIN introduction. Bigger payments, up to 2000

macro-payment category; use cases are the purchase of

contributes with 9 points for risk calculation, which implies that besides the PIN also the password will be always

asked. Last, when the client performs really big payments, buying a car or a house,

category. In these cases he will be prompt to enter a biometrical credential, due to the 12 points given from the

payment amount risk factor. The payment amount categories, including the value intervals and the risk poin

listed at Table 5.

Payment amount

Payment repetition

Micro

Payment

0€ 2€

WPAC Dynamic risk assessment

Figure 30 – Risk value calculation

payment can be classified into different categories [62]. For

€ it is considered a micropayment, small payments range from 2€ to 20€ and over that it is considered a macro

payment. This division is somehow inadequate for macro-payments risk assessment, there is a big difference in the

€ or for example 2000€. Therefore the macro-payment category must be subdivide

we choose to maintain the geometric progression and defined two boundaries at 200€ and 2000€ hence dividing

payments into three fractions, as shown in Figure 31.

match very small payments where the risk is minimal. When the client buys a candy at a vending

machine or pays for a newspaper, he is performing a micropayment, as long as the value in kept under 2

operations, so for micropayments the risk calculation contribution is null. If the client

wants to buy a small meal, around 10€, he is doing a small payment. Although the payment amount is bigger, it is

still a low risk payment as long as there is not present any other risk factor, thus small payments add 3 points to the

risk calculation, which is the upper integer bound of the low risk payment level. Low macro

€ and 200€, for example when the client goes to the supermarket, to the restaurant, or when


hat reason it gives 6 points to the risk calculation, meaning that it will be at best a

payment with a normal risk level which requires PIN introduction. Bigger payments, up to 2000

category; use cases are the purchase of electronic appliances or vacations trips. This category


asked. Last, when the client performs really big payments, buying a car or a house, it falls in the

ese cases he will be prompt to enter a biometrical credential, due to the 12 points given from the

payment amount risk factor. The payment amount categories, including the value intervals and the risk poin

Figure 31 – Payment amount division

Payment repetition

Time Place

Small

Payment

Low

Macro

Payment

Medium

Macro

Payment

2000€ 200€ 20€

Huge

Macro

Payment

. For payment amounts up to

that it is considered a macro-

payments risk assessment, there is a big difference in the

payment category must be subdivided,

€ and 2000€ hence dividing

match very small payments where the risk is minimal. When the client buys a candy at a vending

machine or pays for a newspaper, he is performing a micropayment, as long as the value in kept under 2€. There is

operations, so for micropayments the risk calculation contribution is null. If the client

. Although the payment amount is bigger, it is

sent any other risk factor, thus small payments add 3 points to the

Low macro-payment cover those

€ and 200€, for example when the client goes to the supermarket, to the restaurant, or when


hat reason it gives 6 points to the risk calculation, meaning that it will be at best a

payment with a normal risk level which requires PIN introduction. Bigger payments, up to 2000€, fall in the medium

electronic appliances or vacations trips. This category


it falls in the high macro-payment

ese cases he will be prompt to enter a biometrical credential, due to the 12 points given from the

payment amount risk factor. The payment amount categories, including the value intervals and the risk points are

Risk value

Huge

Macro

Payment


Payment type Value interval Risk points

Micropayment [0€, 2€[ 0

Small payment [2€ , 20€[ 3

Low macro-payment [20€ , 200€[ 6

Medium macro-payment [200€ , 2000€[ 9

Huge macro-payment [2000€ , ∞[ 12

Table 5 – Payment types and risk points

Payment repetition

The second risk factor is payment repetition. When the same m-payment agent is used to perform several payments

in a small time period, the chance of it being used by a thief rises and so do the risk. The threshold of money and the

time period where the risk is considered to grow can assume different configurations. WPAC considers a daily time

period and two reference thresholds. Money withdrawals at ATMs also have a daily limit, however in opposition to

the ATM limit, in this solution when the thresholds are exceeded the payment is still possible but with greater

assessed risk. The thresholds values are defined to roughly half of the low and medium macro-payment intervals,

100€ and 1000€ respectively.

Each payment must be recorded by the mobile software agent, therefore determining the daily accumulated

expended money is as easy as to perform a sum. When this sum exceeds one of the thresholds its risk points are

added to every payment conducted in that day. The risk points, which contribute to the overall risk value, are

defined in such way that increases the risk level of the payment amount category immediately before the category

that includes in its interval the threshold value. For example, if a small payment is being performed after the 100€

threshold being exceeded, besides the 3 points of the small payment risk factor we must add 1 point which result on

4 points and a normal risk level. The 1000€ threshold besides increasing the risk level of a low macro-payment,

adding 3 to the 6 points contributed by the payment amount category, also increases the medium macro-payment

score achieving the high risk payment level. It is intended this way because a medium macro-payment following

previous payments with a sum above 1000€ should be considered more than an increased risk payment. Table 6

resumes the daily threshold intervals and the risk points added to risk evaluation.

Daily threshold Risk points

[0€, 100€[ 0

[100€ , 1000€[ 1

[1000€ , ∞[ 3

Table 6 – Daily threshold and risk points

Time and Place

The time and place where the payment occurs are the other risk factors. These two factors are related, conducting a

payment at a determinate hour on a place can be more dangerous that paying at the same hour on another place,

moreover the same place can have different risks accordingly with the time the payment is done. The exact detail of


how the two factors are related is important to know how to determine the risk points, if we consider that one place

is always more dangerous than the next and that one time period is always more secure than another, we can have

different risk calculation for place and time. However if, for example, a neighborhood is more insecure at night than

at day but another neighborhood by opposite is less secure at day times, and we want to correctly evaluate these

situations, time and place must be used together for risk points calculation. By common sense, late night hours

always imply a greater risk than day time hours. However the payment providers will be less interested in common

sense and more worry about real risk assessment justified with criminal reports.

To determine the risk associated with a place and a time it is necessary to have a table that associates risk points to

each location and time periods, this table should be provided by the issuer accordingly with his risk assessment. The

existence of such a table brings some practical issues, how to codify different places and which area resolution is

advisable, which time period is suitable, and last, how big is that table and how to update it. Mobile devices have

reduced memory and processing capabilities, therefore is not viable to use huge tables with millions of entries.

Time detail

In order to define the risks associated with different time periods it is not enough to consider the hour or part of the

day on which the payment takes place, the day of week and the time of year can alter the risk value. This happens

due to client’s routine change at weekends and summer vacations, and by an increased risk associated with some

days and seasons. At weekend’s eve, for example, people often go out at night thus exposing their assets, including

the mobile phone. Holidays are another case to consider, although they can occur in the middle of the week, they

are days of rest which brings them close to weekends, especially to Sundays because Saturdays are workdays in

some cultures. In Table 7 we analyze different time period resolutions, starting on a low detail resolution only

discriminating three periods of a day, with eight hours each one, and ending on an hourly-daily-monthly time period,

i.e. a different risk definition available for every hour of every weekday of every month. Although the first can be a

low resolution, the last is surely excessive. This analysis enables to verify the number of different combinations for

each time resolution and estimate later, in conjunction with the area resolution, the size of the table.

Id Time Period Number of

combinations Day Week Year

TP1 8 hours 7 days 12 months 3 x 1 x 1 = 3

TP2 8 hours workdays and weekend/holidays 12 months 3 x 2 x 1 = 6

TP3 4 hours workdays and weekend/holidays 6 months 6 x 2 x 2 = 24

TP4 3 hours workdays and weekend/holiday 3 months 8 x 2 x 4 = 64

TP5 2 hours workdays, Saturday and 3 months 12 x 3 x 4 = 144

TP6 1 hour 1 day (holiday as Sunday) 1 month 24 x 7 x 12 = 2016

Table 7 – Time periods resolution and combinations number


Location detail

To codify the locations we can take advantage of the existing postal code system, which already assigns different

codes to different regions. The majority of countries have a national postal code system, with Ireland being a notable

exception 90[6]. In these exceptional cases we would have to define the codes. Postal codes differ from country to

country, as shown at Table 8, ranging from four to eight digit codes or seven alphanumeric characters as in the

United Kingdom.

Country Postal code length Postal code format Example

Portugal 4+3 digit [0-9]{4}-[0-9]{3} 1959-007

France 5 digit [0-9]{5} 75058

UK 2 digit + 3 chars 3 digit + 3 chars 2 digit + 4 chars 3 digit + 4 chars 2 digit + 5 chars

[A-Z]{1,2}[0-9][0-9A-Z]? [0-9][A-Z]{2}

M2 5BQ M34 4AB W1A 1AB RG9 4AJ SK23 7JG SW1A 0PW USA 5 digit [0-9]{5} 20500

Brazil 5+3 digit [0-9]{5}-[0-9]{3} 04552-050

Russia 6 digit [0-9]{6} 103132

China 6 digit [0-9]{6} 100600

Australia 4 digit [0-9]{4} 1225

Table 8 – Countries postal codes format

Postal codes are generally structured in a hierarchical form, the first part of the code indicates the country’s region

or state and the last part details the town within that region. Typically postal codes identify the post office that

serves a relatively small area, towns or city sections, however there are other countries with extended postal codes

that identify in more detail the final recipient. Portuguese postal service is one of such system with its four plus three

digit postal codes; the four digit part identifies the postal office, with the first digit designating the postal regions and

the following two digits the postal distribution center, while the three digit extension provide a building block detail

level [6]. In the following table we summarize and exemplify the postal codes formats of some countries.

The different postal codes format is not an issue, when a client wants to perform payments in a foreign country the

risk table just needs to be updated. The real problem is how to store all the code combinations for long postal codes.

In Table 9 we can see that for Chinese and Russian’s six digits length postal codes it would be necessary a table with

at least one million entries, which is inappropriate for mobile device processing capabilities. The five digits codes

have a hundred thousand different combinations, which multiplied with the number of time period combinations

will also reach an unsuitable table size. The four digits code, even multiplied with time period, presents a viable table

dimension. To overcome the issue of lengthier postal system, only part of the country’s postal codes should be

loaded in the mobile agent, the ones near the zone where the client is performing the payments. For example, a

client using the WPAC payment system in New York City will only have the United States East coast postal codes

loaded in the mobile agent, however if the travels and uses the wireless payment system in Los Angeles the previous

code table is discarded and a new one with the West coast or California postal codes will be downloaded. Other


solution, considering than the codes are hierarchical, is to trim the postal codes only using the part that identify the

zone not the postal office. The first solution allows for a bigger area resolution, defining more precisely the location

where the payment is being done, but with more frequent table updates, whereas the second solution diminish the

number of updates but imply less location detail. Financial institutes supporting this m-payment system will prefer

more area detail in detriment of occasional updates, however if these updates are too often the client may decline

to use the payment service due to download waiting time and communication costs, hence we must define a

intermediate situation.

Postal code Number of combinations

4 digit 10000

5 digit 100000

6 digit 1000000

4+3 digit 10000000

5+3 digit 100000000

1 digit + 3 chars 175760

2 digit + 5 chars 1188137600

Table 9 – Postal codes combinations number

Although Table 9 enumerates the number of possible different combinations for each postal code format, generally

not all of the combinations are used due to the hierarchical postal code attribution. For example, in Portugal

although there are 10 million possible combinations only 195618 numbers are really assigned, less than 2%, if we

consider only the first part of the Portuguese postal codes, the 4 digit code, then from the 10 thousand possibilities

only 703 are used, about 7% [20]. This situation must be taken into consideration while modeling the risk table as we

will see ahead.

Area code and time period combination

Let’s consider further the Portugal example, if we use the full postal code format to encode the risk areas, we have a

risk definition for each small group of building blocks, however the number of combinations is above half a million

even for the lowest time period resolution, as can be seen at Table 11. Taken into consideration one of the above

solutions, loading only parts of the country’s postal codes, we divided Portuguese postal codes into the regions

identified by the first postal code digit thus having 9 different regions as listed at Table 10. Now considering the

fourth region, which is the one with more assigned codes, we calculated the number of different combinations for

each time period and conclude that the number of combinations even for the lowest time period resolution is still

unsuitable. Also this high detail but low area coverage approach would mean that, for example, a person working in

Lisbon but living outside the city, would need daily updates if he used the payment tool near work and latter that day

in his home neighborhood. Considering only the first part of the postal code, which identifies the postal office and

have a small town or big cities section detail, the number of combinations ranges from 2 thousand to near 1.5

million, although the upper limit is again too high if we only consider the first times periods, the resulting risk table

size is possible to maintain and process.


Region Region

Code

Number of

assigned codes

City of Lisbon 1 10502

Lisbon District except City of Lisbon, Santarém District, part of 2 55704

Coimbra and Aveiro Districts, part of Leiria and Viseu Districts 3 26992

Viana do Castelo, Braga and Porto Districts, part of Viseu and Vila 4 55964

Bragança District, most of Vila Real District, part of Viseu and 5 8961

Castelo Branco and Guarda Districts, part of Portalegre District 6 8602

Beja and Évora Districts, part of Portalegre and Setúbal Districts 7 13396

Faro District (Algarve) 8 6881

Madeira and Azores Islands 9 8630

Table 10 – Portugal postal regions and number of assigned codes

4 digit 7 digit (region 4) 7 digit (all regions)

TP1 703 x 3 = 2109 55964 x 3 = 167892 195618 x 3 = 586854

TP2 703 x 6 = 4218 55964 x 6 = 335784 195618 x 6 = 1173708

TP3 703 x 24 = 16872 55964 x 24 = 1343136 195618 x 24 = 4694832

TP4 703 x 64 = 44992 55964 x 64 = 3581696 195618 x 64 = 12519552

TP5 703 x 144 = 101232 55964 x 144 = 8058816 195618 x 144 = 28168992

TP6 703 x 2016 = 1417248 55964 x 2016 = 112823424 195618 x 2016 = 394365888

Table 11 – Area code and time period combinations

Risk table update

Besides limited process capabilities, a mobile device also has limited storage, therefore huge risk tables will simply be

unsupported by some mobile phones. Typical non high-end devices have small memory sizes, around some dozens

of megabytes, the Nokia 6288 for example, have 6 megabytes of user storage [22]. Thus the mobile software agent

code and all the data attached to it must be kept small in size, more than 1 megabyte is considered excessive. Newer

mobile devices usually include the possibility to include a memory card yet this system should not require that. The

risk table must be updatable, although incremental updates can and should be supported, the travel to another

country or a different state in big countries will imply a full table download. Transferring huge amounts of data

through GPRS or other protocol can be cumbersome, 3G protocols, like UMTS, can theoretically achieve 14 Mbits/s

although 384 Kbits per second is the expected transfer rate; GPRS provide from 56 up to 114 Kbit/s, meaning it can

transmit 7Kbytes per second in worst case scenario [6]. Observing the Table 12 we can see that a risk table up to 100

Kbytes in size is acceptable, even though 14 seconds for the lowest download speed can be considered too much, it

is expected that full table updates are occasional and that transmission speeds will be upgrading in the future.

2 Kbytes 4 Kbytes 16 Kbytes 45 Kbytes 100 Kbytes

GPRS (56 Kbits/s) 0,286 0,571 2,286 6,429 14,286

GPRS (114 Kbits/s) 0,140 0,281 1,123 3,158 7,018

UMTS (384 Kbits/s) 0,042 0,083 0,333 0,938 2,083

Table 12 – Risk table sizes and download time


Time and place risk matrix

With all the above considerations in mind, WPAC will use a 4 digit code area resolution and the time period TP2, i.e.

a three 8 hour period per day, differencing weekends from workdays. The chosen hour periods are from 6 to 14

hours, from 14 to 22 hours and from 22 to 6 hours, this way we cover the average sleep time, the period from wake

up to lunch, and from that to bed time. This time period do not take into consideration year seasons, which may

have different associated risks, however this limitation can be easily overcome by table updates, 2 or 4 updates a

year are justifiable by the lower table size. From the studied countries, only Australia and Portugal, without

considering the last three extension digits, have 4-digit length postal codes, countries with lengthier postal codes

must divide them in regions. It only should be used a postal code resolution that identifies postal offices, the

extension digits for street or building block identification can be discarded.

Now that the location and time resolution is chosen we will detail the risk table structure. For starters the risk table

is not really a table but more a matrix, with the area codes as rows and time periods as columns. This matrix can be

supported over multidimensional arrays or by a vector of vectors, with the area codes pointing to the time periods,

as illustrated in Figure 32. To fetch time and place defined risk from the matrix, we must first search the line with the

specified area code, upon obtaining it the correct column is indexed and the risk value obtained. As seen before the

postal code number assignment is not continuous thus in order to optimize the search, the area code vector should

be ordered, also it can be cached the last searches results.

The mobile software agent can easily obtain the current time, however it is difficult to determine in which area he is

conducting the payment, points-of-sale on the other hand are typically fixed in one place and therefore can be

configured to announce their installation area. This area code should be transmitted to the mobile software agent so

it may perform a correct risk assessment. When a POS is carried to another place it must be reconfigured to reflect

the new area code, if this exchange is frequent it may be imposed that the POS include a GPS receiver to correctly

announce the zone it is in. The POS can also transmit the payment time, which the mobile software agent compares

with his time value, thus decreasing the probability of an incorrect time being used in risk assessment. This time

comparison should have an error window due to the communication and process time, or even small clock

differences, an offset lower than 5 minutes is acceptable. If the time offset is greater, nothing can be assumed about

the correct time and therefore the maximum risk value defined for that place should be used. In case the area code

cannot be obtained or the corresponding risk table entry is missing, for example a payment being performed in a

different country with the risk table not updatable at the time due to some mobile network operator problem, the

payment is not disabled, however the maximum time/place risk is imposed, which is 6 as we will see next.

The risk factor contributed by time and place to the overall risk value is codified between zero and three, therefore

only 2 bits are necessary for encoding. Taking advantage of an approach that encodes 4 time period per byte we can

reduce significantly the table size, optimizing memory used and table update time. The risk value obtained from the

table is multiplied by 2, half the interval for each risk level, hence ranging from zero to six risk points. This rule

implies that a defined risk of 2 in the table represents a risk contribution of 4 points and the implicit increase to the

next risk level, Table 13 shows an example of a partial risk table and Figure 32 the equivalent risk table structure.


Workday

6h – 14h

Workday

14h – 22h

Workday

22h – 6h

Weekend

6h – 14h

Weekend

14h – 22h

Weekend

22h – 6h

1349 0 0 1 1 1 2

1959 2 1 3 2 2 3

1990 0 0 1 0 0 2

Table 13 – Risk table example

1349

1959

1990

…

0 0 1 1 1 2

2 1 3 2 2 3

Figure 32 – Risk table structure

In resume, the risk assessed quantitative value is the sum of the risk points contributed by the payment type, the

daily threshold table and the time/place risk table value multiplied by two, as shown in Equation 1.

�� = �� + ��ℎ��ℎ��

+ �2 × ��

Equation 1 – Risk assessment formula

65 WPAC Security

WPAC Security

In this chapter it will be presented the security architecture for the WPAC solution. Firstly, it will be detailed the

chosen cryptographic algorithms and public-key infrastructure, next we describe the secure communication channel

and software agent.

Cryptographic algorithms

RSA with 1024 bits keys and AES with a 256 bits key size are, respectively, the chosen asymmetric and symmetric-key

cipher suites. RSA is the de facto standard nowadays, it has withstand years of cryptanalysis and, as a result, brings

trust to the security protocol. AES is also used worldwide, it is recommend by NIST (National Institute of Standards

and Technology) and does not have any proven weaknesses [6], on opposite to some other popular algorithms, like

DES, which are susceptible to attacks. The RSA algorithm was also chosen for digital signatures together with the

SHA-256 NIST standard as cryptographic hash function. SHA-256 is not as widely used as SHA-1, however some

security flaws have been discovered and the use of SHA-2 variants is recommended.

Public-Key Infrastructure

The usage of a Public-Key Infrastructure (PKI) enables the establishment trust relationships through a common

Trusted Third Party (TTP), the certification authority, even if the peers do not know each other. The certification path

length is defined accordingly with the solution and real life relationships. SET protocol defines a certification

hierarchy with five certification authorities (CA) types and a certification path of four public-key certificates, this

implies a considerable amount of certificates needed to be stored and validated. In WPAC solution, due to the

limited processing power of mobile devices but also because of the shorter trust paths imposed by security

constraints and real life relationships, the PKI architecture is simple and with a short validation path.

Figure 33 – WPAC PKI

The bound between entity’s name and public-key is critical for the establishment of trusted relationships in a PKI.

Different CAs may have different policies for the binding, although in a hierarchical architecture all of them are

trusted by a root CA. Long certification paths may weaken trust relationships, as the overall trust is as great as the

strength of the weakest link. The same applies in the real world, people tend to trust more in the people they know

66 WPAC Security

that in other people, even if they are recommended by a common friend or trustee. When a client wants to use a

payment system, he establishes an agreement with a trusted institution that supports the system, transferring trust

only for that institution.

This project proposes a simple PKI, depicted in Figure 33, with only one certification authority, the root CA, thus

achieving the highest level of trust possible. With such architecture all certificates are signed by the same

certification authority, clients know that the entity that signed his certificate is the same who signed merchant’s

certificate. However, because clients and merchants may have agreements with different financial institutions, the

root certification authority may delegate the identity registration in different registration authorities (RA), the ones

that know the user, like illustrated in Figure 34. Using several registration authorities may weaken the PKI [56], like

when using different certification authorities, because the overall trust is again shared by different entities. Even so,

this delegation is not mandatory and may be used in a more dynamic way than with architectural defined

intermediate CAs. In worst case scenario the same level of confidence is achieved with shorter certification paths.

The architecture with only one CA dramatically reduces the amount of processing required to validate someone’s

identity, only needing to verify two digital certificates, those of the certificate holder and root CA. Because the root

certificate is statically distributed with the software agent, one may think that it would not be necessary to

continuously validate it, however even though it is a self-signed certificate which inherently cannot be revoked, the

expiration date must be verified each time.

Client Merchant

Regist

identity

Regist

identity

Certification

AuthorityRegistration

Authority

Registration

Authority

Request

certification

Request

certification

Issue

certificate

Issue

certificate

Exchange

Certificates

Figure 34 – WPAC registration authority

The emission of certificate revocation lists (CRL) should be published periodically and software agents must fetch it

accordingly with the define timeframe, although for critical revocations the CA may actively push the revocation list

to the agents. In order to minimize the online access to CA’s CRLs, which may be expensive in mobile phones or not

always be available, revoked certificates are cached locally and checked upon transactions, for the same reason the

Online Certificate Status Protocol (OCSP) [6] is not used. In high risk payments, like those involving large sums of

67 WPAC Security

money, the client’s software agent can be forced to fetch the latest CRL, thus reducing the risk of disclosing

extremely sensible data.

Secure communication channel

In a wireless environment, data transmission is more exposed to attacks, and therefore data must be protected. The

WPAC security architecture defines a secure communication channel upon which all application data can be

transmitted securely, rather than following a per message approach. Although such design can presumably include

an unnecessary overhead when non security critical data is transmitted, it allows for greater expandability and ease

integration of composite services.

Security properties

A secure solution for payment and access control must impose privacy, integrity, authentication and non-

repeatability. Privacy is achieved through data encryption. There are two types of encryption algorithms, symmetric

and asymmetric-key, asymmetric-key encryption is not suitable for bulk-encryption, thus following the SSL/TLS [34]

and SET [3] design pattern, public-key encryption will only be used for secure key transport. After session key

exchange, both peers can protect sensible data by using a symmetric-key encryption scheme. SET uses a different

symmetric-key in every transmission, thus implying the need to also securely transport that key using public-key

encryption, bringing a huge computational effort without significant benefits. SSL/TLS has a more reasonable

solution, exchanging a master secret, from where each peer derives a session key. In our solution, taking in

consideration the limitations of mobile devices, we simplified a little more, exchanging and using the same session

key for both peers. The increased usage of the same key and the availability of additional ciphertexts, can more

easily reveal statistical information of the plaintext, even though, the amount of encrypt messages is low and the

chosen algorithm should be resilient to such attacks.

Message integrity, authentication and non-repudiation security properties will be granted by the usage of digital

signatures, following the approach of SET protocol. Authentication and non-repudiation are only achieved if the

public-key can be securely associated it an entity, in that case the identity of the signer can be verified. To

accomplish this, digital certificates will be used along with a Public-Key Infrastructure, where a Trusted Third Party,

known as Certification Authority, is responsible for the association between the entity name and his public-key.

Non-repeatability will be imposed by the usage of sequence numbers, in a similar way to what happens in SSL/TLS,

however using a global sequence number instead of a sequence number per peer. There are two types of repetition,

the replay of a single or out-of-order message and the retransmission of an entire conversation. Although the usage

of a per peer sequence number detects repeated and out-or-order message, it does nothing to prevent entire

session repetitions. Presumably, an attacker could capture a previous transmission and repeat it latter, because his

messages have correct sequence numbers between them the attack could prevail. With the usage of a global

sequence number this attack is somewhat prevented, because the sequence of one peer is dependent of the number

received from the other, however the issue still remains for the initial sequence number. It is necessary some king of

challenge-response scheme, in which each peer sends a challenge number and waits for it in the response, if this

68 WPAC Security

happens the peer can be certain that who responded to his challenge is not repeating a conversation. In our solution

we implemented such scheme, using the challenge-response scheme also as a sequence number negotiation.

Protocol overview

In Figure 35 it is depicted an overview of the secure communication protocol. The client initiates the communication

with a Client Hello message, optionally specifying the protocol version, which includes a challenge number and a

digital signature. No encryption can be applied so far because there is no exchanged session key, neither any way to

use public-key encryption because the public-key of the other peer is yet unknown. This is the only message send in

cleartext, but there are no sensible data being transmitted, nevertheless integrity and authentication are imposed.

The specification of the protocol version can enable the coexistence of different versions, particularly different

cipher suites, however this support should be limited to secure algorithms and discard deprecated versions, on

opposite to what happens in SSL/TLS, which can severely weaken security. The Merchant Hello message carries also

a digital signature, the response to the client’s challenge number, the merchant’s own challenge number and the

session key to use in the following transmissions. This message is encrypted using the client’s public-key and

therefore is only decipherable by him. After the two initial messages of security tokens exchange, the normal flow of

application-level messages can begin. All the application level messages include a sequence number, a digital

signature and are encrypted with the session key.

Figure 35 – Secure communication protocol overview

Initially each peer has its key-pair, a public-key certificate with his public-key and the certification authority

certificate, which signed his and other peer’s certificates. In the Client Hello message, the client’s certificate and

challenge number is sent to the merchant. The merchant can validate the message digital signature using the public-

key received in the certificate, also authenticating the client. Then the merchant generates a session key and a

challenge number, and sends them, along with his public-key certificate and client’s challenge number response, to

the client in the Merchant Hello message. When the client receives the message both peers have all the security

tokens needed for the establishment of a secure communication channel, certificates and session key are exchanged

and the sequence number can be computed from the two challenge numbers. In fact, the merchant already had the

security tokens upon receive of the Client Hello message. Figure 36 depicts security tokens exchange.

69 WPAC Security

Figure 36 – Security tokens exchange

Messages

As described before, there are two specific messages for the establishment of the secure communication channel,

the Client Hello and Merchant Hello messages, after which application-level data can be transmitted securely. Next

it will be detailed the actions needed for creating and processing these messages.

The Client Hello message is composed by the protocol’s security-level data, with the security suite version and any

necessary future info, also including the digital signature, client’s challenge number and client’s certificate. To create

this message the client’s software agent generates a secure random number, which is his challenge number, joins it

with the data and signs it, as described in Figure 37. In order to sign the data, the client uses the defined hash

function, which is SHA-256, and encrypts the resulting message digest with his private key. The Client Hello message

is not encrypted because necessary security tokens are not exchanged yet, although message contents are not

protected against eavesdroppers this is not an issue since no sensible data is being transmitted. It would be possible

to encrypt the first message if the system requires so, by using a key agreement protocol such as Diffie-Hellman,

however it would imply a communication and processing overhead to negotiate the parameters and calculate the

key. When the merchant receives the Client Hello message he must validate the digital signature in order to prove its

authenticity and authenticate the client. To do so, he applies the same hash function to the data and decrypts the

digital signature, using client’s public key extracted from client’s certificate, and compares the resulting message

digests.

70 WPAC Security

Figure 37 – Client Hello message

Figure 38 – Send Merchant Hello message

71 WPAC Security

The Merchant Hello message also includes security-level data, now transmitted encrypted along with the challenge

numbers, a digital signature, merchant’s certificate and an encrypted digital envelope with the session key, as

depicted in Figure 38. The challenge number received from the client is sent back with the same value, in order to

protect against merchant-side session replays the random generated merchant’s challenge number is also sent. The

merchant processes both numbers, calculating the sum of them, in order to obtain the sequence number to be used

in this session further transmissions. The digital signature is processed in a similar way as before, but including data

and both challenge numbers, using a hash function and merchant’s private key. The session key used in bulk

message data encryption is generate at this phase by the merchant and it is sent securely to the client by encrypting

it with client’s public key, thus using public-key encryption for key transport. This session key is used to encrypt

Merchant Hello message data.

419839

815482

419839

815482

1235321

419839

Figure 39 – Receive Merchant Hello message

Upon receiving the Merchant Hello the client must firstly obtain the session key from the digital envelope by

decrypting it with his private key, then the session key is used to decrypt the message data. The decrypted data must

be checked upon the received digital signature by applying the hash function to it and compare with the result of the

decrypted digital signature, the digital signature is decrypted with the merchant’s public key extracted from the

merchant’s certificate. The client must also compare the value of the received client’s challenge number with the

value he sent previously, then he processes both challenge numbers to calculate the sequence number to be used

next. This process is illustrated in Figure 39.

72 WPAC Security

Figure 40 – Send message

Figure 41 – Receive message

After the transmission of Client Hello and Merchant Hello messages the secure communication channel is

established, the following messages will use encryption, digital signatures and sequence numbers to provide privacy,

integrity, authentication, non-repudiation and non-repeatability properties to the application-level protocol. When

any peer wants to send a message, as part of the application protocol, he increases the global sequence number,

joins it with the application data and encrypts with the session key, the same data is passed through a hash function

and digitally signed using the sender’s private key, as described in Figure 40. The message is composed solely by the

encrypted data and digital signature, certificates and session key were exchanged previously. When a peer receives a

message he must decrypt it, validate both the digital signature and sequence number and pass the application data

to the above protocol, as depicted in Figure 41.

73 WPAC Security

Secure software agent

Sensible data and critical security tokens must be protected not only while being transmitted but also when

processed and stored at the terminal equipments, the security requirements are essentially two, integrity and

privacy. The mobile software agent must not be modified by illicit entities, like a virus, when installed in the mobile

device, and unauthorized copies of the software agent should be detected and disabled. Any personal info and, more

important, passwords and private keys, cannot be accessible to external entities, this includes protection against

key-loggers. Buffer under or overflows can also constitute a serious risk as they may enable the injection of code.

Most of these risks and the possible security measures are dependent of the software and hardware platform, the

operating system should include malware protection thus disabling virus, worms and key-loggers. Indexing out of the

bounds of a buffer should generate and runtime error and not fail silently.

The mobile agent MIDlet must be signed in order to authenticate the author, in this case a WPAC certified issuer,

and guarantee that the code has not been altered or corrupted while in transit. The signature of the MIDlet

application suite is created according to PKCS#1 standard, the signature algorithm used is RSA and the hash

algorithm is SHA-1, while the result of a signing process is base64 encoded and inserted into MIDlet application

description file [56]. In order to verify the signature, the public-key certificate, matching the private-key used to sign

the JAR, must be signed by a trusted CA, like in the PKI discussed previously. However most mobile phones may be

unable to install a new root certificate, the WPAC root CA, in this case it is necessary to use a certificate signed by a

pre-installed certification authority, like VeriSign. The signature of the Java ARchive (JAR) imposes the integrity of the

code but also of the entire archive, therefore sensible data or other security tokens present in a signed JAR, have

their integrity assured.

Security tokens, the WPAC root CA certificate and client’s key pair, should be securely stored in a keystore. The

access to the keystore depends upon a password, which must be specified in the agent code, somewhat

compromising security, in order to the software agent retrieve the keys to validate and generate the digital

signatures. The introduction of the keystore access password could be delegated on the client however this would

force the client to always introduce the password upon m-payment software agent utilization, besides the

credentials to approve the payment. The access to mobile device’s keystore with the purpose of extracting keys,

even with the knowledge of the password, is presumably a difficult operation which forces the attacker to hold the

mobile phone for a period of time. Such situation is likely to occur in mobile phone theft, which must be report to

the issuer by the client, thus revoking the public-key certificates. Sensible data, such as the value of the credentials

for validation upon payment confirmation, should be secured by the usage of one-way hash functions. With such

approach, the agent archive contains irreversible hash values for every credential, thus allowing validation without

disclosing in code or anywhere else the original credential values. The Java language also has many other features

and mechanisms like type safety, lack of pointers and a bytecode verifier, which strengths the solution by avoiding

software related attacks.

The unauthorized copy of the MIDlet suite, that is, the mobile payment agent cloning, should be avoided. Typical

solutions validate mobile device details upon MIDlet start, like IMEI (International Mobile Equipment Identity), IMSI

74 WPAC Security

(International Mobile Subscriber Identity) or even Bluetooth address. However there are no perfect solutions and

these values can also be cloned along with the software agent, by modifying the device’s firmware. Even so, the

mobile agent should do its best effort to prevent the clone and thus these values should be verified. The clone of the

payment agent is also a real attack to magnetic stripe credit cards, in m-payments like in credit card’s payments the

risk should shared by client and issuer.

All the above considerations, discussed with a focus on the client’s mobile software agent, are also applied to the

merchant’s software agent. Even so, the merchant’s software agent is less restricting, for example in terms of root

certificate installation, and the POS is not mobile, therefore it is more easy to secure.

Denial-of-Service

A common approach to protect against denial-of-service attacks is to validate entities identity. In this case, this

means that each client, or potential attacker, needs to be authenticated before the POS commits any resources to it.

Although client authentication, through the verification of the digital signatures, protects against unauthenticated

attackers and disables them from establishing an application-level communication channel. Attackers can still force

the merchant software agent to validate the digital signature and certificate sent in the Client Hello message, even if

they are not valid or signed by an untrusted third-party, in order to consume merchant’s computational resources

and thus disable the system. In order to discourage attackers from doing this, the client should commit its resources

first and the merchant should be able to verify the client commitment before allocating its own resources. The

resource commitment can be achieved through the usage of client puzzles [57], which implies computational effort

to resolve, for example the brute-force reversal of a one-way hash function. Client puzzles can have a dynamic

difficulty, increasing when merchant’s resources are close to being exhausted; however the burden of resolving

puzzles will be set upon attackers and clients alike, thus penalizing legit users. Because the WPAC m-payment system

must respond in real time, client puzzles are not used.

Besides disabling attacks on application-level connection establishment, other techniques are needed to protect

individual clients against denial-of-service attacks and to prevent exhaustion of communications bandwidth. Hostile

applications, maliciously installed in client mobile device, could steal CPU cycles, spawn new resource consuming

threads, or try to grab as much of the system memory as possible. Wireless communications are sensible to radio

interferences and can be disabled by a high power radio emitter transmitting at a vicinity frequency. If an attack

floods the wireless channel with junk data the client may also be unable to establish a connection. There is little that

can be done in order to prevent these attacks on the radio environment, but the WPAC alternative purchase

protocol can overcome such limitations.

75 WPAC Implementation

WPAC Implementation

The WPAC implementation follows the approach described in Technology Stack chapter. Next it will be presented the

software packages needed to support the proposed technologies and implement the software agent, afterwards it

will be detailed the Web Service contract and discussed the test results of Bluetooth Inquiry and cryptographic

benchmark.

Software packages

The technological stack defines Bluetooth as the communication channel, Web Services for purchase protocol

definition and data representation, the cryptographic suite for security and Java for agent implementation. In order

to implement these features of the mobile agent, some external software packages where bundled in the software

agent, while others must be present at the mobile device, thus acting as an implementation requirement.

Libraries

The mobile agent implementation aims to support the larger number of different mobile phones models and

manufacturers, thus the application cannot follow the latest industry standards but should have the minimum set of

requirements possible. Even so, newer and more powerful equipments can take advantages of its supported

software modules, if at deployment time different mobile agent applications are compiled, accordingly with mobile

phone model.

Required Libraries

The actual WPAC implementation uses Bluetooth as the wireless communication channel, thus it is mandatory that

mobile phones have a Bluetooth antenna. Most, if not all, mobile phones with Bluetooth communication also

support Java APIs for Bluetooth, specified by JSR 82 [65], thus no Bluetooth stack will be bundled with the mobile

software agent. CLDC 1.1 and MIDP 1.0 libraries, which are the core of Java Micro Edition, must also be supported by

mobile phones.

3rd Party Libraries

The need to include external library code comes from the limitations of Java ME and the JSRs supported by the

mobile phones. For Web Services and SOAP message processing was used the kSOAP library [68], a lightweight and

efficient SOAP engine suitable for Java ME or constrained java devices. The Java Community Process have published

a Java Specification Request (JSR) entitled ‘JSR 172: J2ME Web Services Specification’ [70] as an optional package

that provides standard access from Java ME to web services, however this package is not yet available in all mobile

devices. The cryptographic suite necessary to provide security for the WPAC payment system was implemented by

using the Bouncy Castle Crypto APIs [63]. The SATSA (Security And Trust Services API for J2ME) package, defined by

JSR 177 [69], provides similar functionality, however it is also unavailable is some mobile phones. From the mobile

phones available in our test environment, Nokia e61, Nokia 6630 and Nokia 6288, only the first one possessed JSR

172 and JSR 177 libraries. Although these mobiles devices are not state of the art nowadays, they are close, in

functionality, to the majority of mobile phones available at people’s pockets.


The implementation of the POS application is less restricted because there is no dependence of built-in libraries, and

they can be installed at deployment time. Furthermore the 3rd

party libraries, Bouncy Castle for security and kSOAP

for Web Services, can also be installed in POS in order to reutilize the implementation. Even so it is worth notice that,

on opposite to what happens on mobile phones, it is necessary to install the Bluetooth API, Avetana provides a JSR-

82 implementation both for Windows ad Linux operating systems.

Runtime environment

Java applications run over a Java Virtual Machine and are therefore abstracted of the underlying operating system

and hardware. Nevertheless it is important to detail the types of virtual machines and operating systems available as

runtime environments.

The mobile software agent uses the Java Micro Edition platform while POS application runs over Java Standard

Edition. There are two types of Java Virtual Machines (JVM), the just-in-time (JIT) compilers, which converts

intermediate bytecode into native machine code on the fly, and on some less powerful devices a bytecode

interpreter. Another approach is to execute Java bytecode directly in hardware, which is enabled by the Jazelle JVM

on some processors.

Mobile devices and POS have different operating systems. Even so, Java bytecodes are able to run in should

heterogeneous environments given that a JVM is available in the target operating system. Symbian OS is a popular

operating system for mobile devices, but others are available like the proprietary Nokia OS [6]. The POS is likely to

have a Linux or Windows based machine.

Figure 42 depicts the relation between the different software packages, including the necessary libraries and typical

runtime environments.

Figure 42 – WPAC software packages

Purchase Web Service

The WPAC purchase protocol follows a Service-Oriented Architecture, through the usage of the Web Service

standard. The merchant is the purchase service provider, thus enabling clients to consume the web service to


complete the payment process. The purchase protocol is defined by the WSDL (Web Services Definition Language)

contract, which also describes the purchase data model in a standardized way.

Data Model

The WSDL contract, present in the Appendix, defines the two methods necessary to complete the purchase protocol,

the first to retrieve the payment details and the second to confirm the payment, as illustrated in Figure 44. With the

getPaymentData operation clients can obtain the necessary payment data to validate the payment, this includes the

payment amount and merchant’s identification, in order to confirm that the payment is performed to the correct

entity. It is also received the local code, which is used for risk assessment, and a transaction identifier which will be

used to identify the transaction across the purchase protocol. With the confirmPayment operation the client can

confirm the payment, by providing his credentials along with the previously received payment amount, transaction

and merchant identifiers. The client credentials include the client unique identifier in the WPAC system, the client’s

account number and authorization code. In response to the payment confirmation, the client receives from the POS

the payment receipt, which includes again the transaction id, merchant information, the payment amount and date,

and the status of the payment authorization. Figure 43 shows the data model used in purchase protocol.

-clientId

-clientAccountNumber

-clientAuthorizationCode

ClientCredentials

-merchantId

-name

-local

-localCode

MerchantInfo

-merchantTransactionId

-amount

-merchantInfo

PaymentData

1

1

-merchantId


-amount

-clientCredentials

PaymentCredentials

1

1


-amount

-datetime

-merchantInfo

-status

PaymentReceipt

1

1

Figure 43 – Purchase Protocol data model

SOAP Messages

The getPaymentData operation has no request data, thus the getPaymentDataRequest SOAP message has no

elements on the body, on opposite the getPaymentDataResponse message carries a PaymentData object. The

confirmPayment operation holds the PaymentCredentials complex type in the request message and returns the

PaymentReceipt type on the response.

The payment amount is critical information in a purchase protocol, thus it is a mandatory parameter in all SOAP

messages, expect the getPaymentDataRequest which do not include any data. The merchant information is also

mandatory data both the getPaymentDataResponse and confirmPaymentResponse messages, however the

MerchantInfo type only requires that the merchant name and local code are specified, the first for merchant identity

confirmation by the client and the latter to use in dynamic risk assessment. The confirmPaymentResponse SOAP

message must also include the date and time of the payment. The confirmPaymentRequest besides the payment


amount also obliges that the clients account number and authorization code are provided. Further details on

operations and SOAP messages are available in the WSDL contract at Purchase Protocol WSDL appendix.

Figure 44 – Purchase Protocol WSDL

Bluetooth Binding

The usage of a Bluetooth binding in Web Services is not yet standardized, thus the Purchase Web Service is not WS-I

(Web Services Interoperability) Basic Profile [6] compliant. However the Web Service consumers, WPAC clients, are

known entities which accept the WSDL contract and have certified mobile agent implementations, thus no

compatibility issue arises. Even so, steps should be taken in order to define the standard for Bluetooth binding on

Web Services. In WPAC proposal, the binding address if defined by the Bluetooth service UUID (Universally Unique

IDentifier).

Security Tokens

The security tokens, data encryption and digital signatures, discussed previously in WPAC Security chapter, are

applied over the SOAP messages, following the technology stack approach. There are several standards for using a

cryptographic suite together with Web Services. The XML Encryption recommendation [72], governed by a W3C,

defines a set of XML nodes that carry the security tokens, including cryptographic algorithms and keys, especially the

EncryptedData element which contain the encrypted data and reference to the encrypted element. The XML

Signature recommendation [73], also maintained by W3C, provides a standard way to include digital signatures and

X509 certificates into a SOAP message.

Bluetooth Discovery

In order for the client’s mobile agent to communicate with the merchant’s POS it must establish a Bluetooth

connection and to do so it needs to search for Bluetooth devices offering the payment service in the vicinity. The

Bluetooth inquiry protocol is a slow process, typically it takes 10.24 seconds to complete, but accordingly to

specifications it can be up to a minute [64]. Such magnitude of time is unusable in real time solution like a proximity

payment, therefore it is necessary to better evaluate the average necessary time to search and establish a Bluetooth

connection and find possible solutions. To do so, some trials were executed, using a Java MIDlet and embedded JSR

82 Java API for Bluetooth [65]. These tests were performed on Nokia e61, Nokia 6630 and Nokia 6288.

Inquiry time and device discovery

The inquiry process was executed several times, the test results, depicted in Figure 45, confirmed that the time for

process completion may vary from 10 seconds on Nokia 6288 to 26 seconds on Nokia e61, but on average is between


10 and 17.5 seconds. Although the inquiry protocol is slow, devices can be discovered before the inquiry protocol

completes, even so, there is no warranty that the indented device is discovered fast. To verify the time taken to

discover devices two trials were executed, in the first each mobile phone searched only one other mobile phone,

while in the second type each device performed the inquiry in an radio environment with four other Bluetooth

antennas, the other 2 mobiles devices and 2 Bluetooth dongles. In the first trial, the device was discovered as fast as

200 milliseconds for Nokia e61, but in other inquiry the same device toke more than 13 seconds to discovery it, as

illustrated in Figure 46, the average time, across all discoverers, is 3.8 seconds. The second trial shows that on

average the first device is discovered in the first second, the second device between 1.35 and 3.78 seconds, the third

device takes around 8 seconds and the forth device 14 seconds, as depicted in Figure 47, except for Nokia 6288 that

finds them both in 3.71 seconds.

Figure 45 – Bluetooth inquiry time

Figure 46 – Bluetooth single device discovery time

Figure 47 – Bluetooth several devices discovery time

The performed test shows that devices are discovered without any apparent order. Nokia e61 and Nokia 6630

sometimes return the devices in the same order and with a discovery time below 50 milliseconds, this happens due

to an internal caching mechanism. The caching of inquiry results in some mobile devices, Nokia Series 60 developer

0

10

20

30

Min Mean Max

Inq

uir

y T

ime

(se

con

ds)

Nokia 6288

Nokia e61

Nokia 6630

0

5

10

15

Min Mean Max

Dis

cov

ery

(se

con

ds)

Nokia 6288

Nokia e61

Nokia 6630

0

5

10

15

20

1st Device 2nd Device 3rd Device 4thDevice

Dis

cov

ery

(se

con

ds)

Nokia 6288

Nokia e61

Nokia 6630


platform, possibly leads to devices being reported as found when they are not in range anymore. The repetitive

inquiries test in Nokia 6288 shown no evidence that the inquiry process will benefit from previous inquiries. Another

trial found no significant difference in the inquiry process when being performed on different distances between

inquirer and target Bluetooth devices, the test results show that from 0 to 9 meters the total inquiry and device

discovered times remained essentially the same.

Service search

To obtain a Bluetooth connection it is necessary not only to find the device but also the expected payment service. A

service search trial was conducted through the inquiry of all Bluetooth devices in range, with a subsequent service

search in each one, as depicted in Figure 48. Device inquiry and service search may not be executing in the same

time, thus it is always necessary to wait for the inquiry to complete. The results show that on average a 13 seconds

period is needed to discover the specified service, this in mainly due to the full inquiry time, the time taken to search

services in one device is negligible. The JSR 82 Java API for Bluetooth [65] enables the direct search for a service,

when the device that provides it is not important. In the WPAC solution this may be used because the mobile agent

will not know all the Bluetooth addresses of all merchant that support WPAC payment, hence it has no way to

validate the device at the communication level but only afterwards in the session layer where authentication is

enforced. Unfortunately Symbian OS based phones do not support this functionality. Even so a trial was executed on

Nokia 6288, which is has Nokia OS, with an average service discovery time of 11 seconds. The result is quite similar to

the full device inquiry followed by service search, possibly because that is what the method does internally, thus

there is no advantage on using it.

Figure 48 – Normal Bluetooth Discovery

Until now, although it has been shown that devices are discovered before the inquiry processes completes, some of

them at a reasonable time period, there is no way to know if the discovered devices have the payment service. The

service discovery and device inquiry cannot run at the same time, thus it is necessary to wait for the inquiry process


to complete or taking the risk of cancelling the inquiry when the first device is found and find if it has the service.

This second approach may have good results when only one Bluetooth antenna, the one with payment service, is

available in the radio environment but will have really bad results when several Bluetooth devices are at range,

mainly because when the inquiry process is canceled and the intended device not found the inquiry process must be

repeated from the beginning.

Friendly name search

The JSR 82 API enables that the discovery of devices retrieve their friendly name, which can be used to aid in the

detection of devices that support the payment service. Setting all POS devices with the same Bluetooth friendly

name, or a common prefix, enables that during the inquiry process when a device is discovered with the given name,

the inquiry is cancelled with a high probability that is payment service is supported. If the service is not found in a

device with the expected friendly name, the device address should be added to a blacklist and the inquiry restarted,

as detailed in Figure 49, thus when another device is discovered not only the friendly name should be verified but

also the blacklist. If the inquiry completes and no device is found the discovery process fails.

Device Inquiry

Fail

Search WPAC

Service in Device

Found

Service?No

Yes

Establish

connection

Yes

Device with

Friendly Name?

Yes

No

Stop

Device Inquiry

Inquiry

Complete?

No

Add Device to

Blacklist

Device

Blacklisted?

Yes

No

Found

Device?

Yes

No

Figure 49 – Bluetooth Discovery by Friendly Name


This scheme is susceptible to attackers in the vicinity which broadcast the same friendly name, thus misleading

client’s mobile agent to cancel the inquiry process and wasting time connecting to an invalid POS. Even so this brings

no advantage to the attacker as he will fail to authenticate as a valid POS and thus falls in the category of a denial-of-

service attack. Attackers who want to disable the payment service at the communication layer have many ways to

disable radio communications, like exhausting the wireless communications channels or introducing noise, thus the

attack on the friendly name is not considered a severe weakness but rather the best effort to overcome Bluetooth

inquiry process limitation. Figure 50 shows the results of a trial using the friendly name to help in the device

discovery and inquiry cancelation, on average, for Nokia e61 and Nokia 6630, the entire processes completes in 4

seconds. Yet, Nokia 6288 toke more time with this approach then it takes to complete an inquiry process, this

happens because while in Nokia Series60 platform the friendly name is fetched with the device inquiry, in Nokia

Series40 to obtain the name a new search in performed. Thus, although device name search is not the finest solution

for Nokia 6288, it is a good approach for other tested devices.

Figure 50 – Bluetooth device name discovery time

Same Bluetooth address

An entire different solution is to completely dismiss the inquiry process and hardcode the POS Bluetooth address

into clients mobile agents. This implies that all POS must share the same address, although it is against the Bluetooth

protocol, which relies on a unique network identifier to work properly, some Erickson’s P900 and Nokia 6670 phones

have been reported to share the same Bluetooth address [66][67]. With such approach no inquiry process would be

necessary, and the service search on a pre-known takes on average 200 milliseconds. Even so, if the two devices with

the same address are present in the same coverage area, for example automated POS machines in a supermarket,

one or both may be unable to communicate as data collisions are probable to occur. A possible solution to avoid

radio overlap is to physically control the antenna radiance diagram, yet because this solution goes against the

Bluetooth specification is should be left as last resort.

Connection caching

Another solution is to cache the last successful connections and try to reopen them when the mobile agent is

started, this is a good solution if clients pay frequently in the same store and the discovery process time can be

reduced. However for every connection unsuccessfully opened there is an amount of elapsed time, which in the

worst scenario is added to the inquiry process.

0

5

10

15

Min Mean Max

Dis

cov

ery

(se

con

ds)

Nokia 6288

Nokia e61

Nokia 6630


Conclusion

The trials shown that in some devices the Bluetooth friendly name can be used to shorten the device discovery time,

however not only this solution is not available for every device tested but there are plenty of other mobile devices

from different manufacturers, not tested, were the behavior of the JSR 82 Bluetooth API is unknown. Thus the best

solution is probably a mixture of the different approaches depending on client’s routines and payment scenarios

where the WPAC is used. The Bluetooth slow inquiry process is a known issue, Bluetooth 2.1 specification introduces

improvements in the inquiry process, providing more information during the inquiry procedure, and introducing NFC

(Near Field Communication) cooperation for automatic creation of secure Bluetooth connections.

Cryptographic operations benchmark

Cryptographic operations are intensive computing tasks, because mobile devices have limited processing capabilities

it is important to verify if mobile devices can perform the necessary cryptographic actions and deliver effective

security in real time. Next it will be presented and discussed the more significant results of a cryptographic

operations benchmark. The test has performed several iterations, one thousand in most cases, of the different

cryptographic actions using different cryptographic protocols and running on different mobile devices. The test was

implemented in a Java MIDlet using Bouncy Castle security API [63] and executed on three Nokia phones, Nokia e61,

Nokia 6630 and Nokia 6288, which have different operating systems and developer platforms between them. The

tested operations were symmetric-key and public-key encryption and decryption, cryptographic hash functions and

digital signatures.

Symmetric-key operations

Symmetric-key encryption and decryption operations are similar, some protocols, like DES, are even symmetrical,

using the same algorithm for both operations [11]. The benchmark confirmed this attaining similar time periods for

encryption and decryption. Although AES is the chosen algorithm due to security resilience, the benchmark test also

analyzed other symmetric-key algorithms, as depicted in Figure 51 AES is on average the slowest protocol, even so

the processing time is low enough not to be a restriction. Figure 52 shows that the increase of key size does not

greatly deteriorates the processing time, increasing on average from 14 milliseconds for 128-bit keys to 19

milliseconds for 256-bit keys on the slowest tested device, but only increasing 1 millisecond on the fastest. The

increase of the data block increments the encryption time linearly, as illustrated by Figure 53, even so, for 16 Kbytes

chunks of data the processing time is below 300 milliseconds. Symmetric-key operations were performed fast

enough, on this benchmark, not to be considered a restriction, thus the AES protocol with 256-bit keys should be

used for session encryption.


Figure 51 – Mean Symmetric cipher engines encryption time

Figure 52 – Mean symmetric key size encryption time

Figure 53 – Mean symmetric cipher data size encryption time

Asymmetric-key operations

The secure transport of the session key is achieved through public-key encryption by the usage of the RSA cipher

suite. Asymmetric-key algorithms have different computing weight for encryption and decryption operations, the

RSA protocol have slower decryption then encryption, also the processing time increases exponentially by a factor of

4 for encryptions of by a factor of 8 for decryptions [3]. Figure 54 and Figure 55 show the evolution of the computing

time for increasing key strengths, the slowest device, Nokia 6288, for 2048-bit keys has an encryption time that

exceeds half a second, for faster devices or shorter key lengths the processing time is below 0.2 seconds. The

bottleneck of the cryptographic solution is the private-key decryption operation. It takes on average 13 seconds for

the slowest tested device to perform a 2048-bit decryption and approximately 2.5 seconds for the faster devices,

computing times of this magnitude are unsuited for real time systems, thus it is necessary to use smaller key sizes. A

0

20

40

60

AES Fast

AES Light

AES DES Triple DES

RC5 RC6 IDEA None

En

cry

pt

Tim

e

(mil

lise

con

ds)

Cipher Engine

Nokia e61

Nokia 6630

Nokia 6288

0

5

10

15

20

AES 128 AES 192 AES 256

En

cry

pt

Tim

e

(mil

lise

con

ds)

Key Size (bits)

Nokia e61

Nokia 6630

Nokia 6288

0

100

200

300

0 4096 8192 12288 16384

En

cry

pt

Tim

e

(mil

lise

con

ds)

Data Size (bytes)

Nokia e61

Nokia 6630

Nokia 6288


1024-key decryption takes about 0.3 seconds to complete on faster devices and close to 2 seconds for the slowest,

which is an acceptable processing time. The use of 1024-bit keys is not an issue because they are considered secure

for corporate use by RSA Laboratories [26].

Figure 54 – Mean RSA Encryption time

Figure 55 – Mean RSA Decryption time

Digital Signatures

Cryptographic hash functions, such as MD2, MD4, MD5, SHA1, SHA-256 and SHA-512 all have mean processing times

below 1 millisecond, even for 16 Kbytes chunks of data, thus their processing weight is negligible. Digital signatures

are essentially a hash function followed by a public-key operation, therefore it is expected that the computing effort

to sign and verify signatures is similar to public-key decryption and encryption, respectively. However the benchmark

results demonstrate that the processing time for digital signatures is about 50% greater than for the matching

operation on asymmetric encryption, for example, it takes 2.9 seconds to sign a message using a 1024-bit key while it

takes only 1.8 seconds to decrypt a message. Figure 56 show that the processing time increases exponentially with

key strength, the slowest device takes almost 3 minutes to sign a message with a 4096-bit key. The usage of 2048-bit

keys is also not advisable for digital signatures because the tested devices toke between 2.6 and 21.8 seconds to

perform the signature operation. Again, 1024-bit keys is the wise choice for asymmetric operations, Nokia 6288, the

slowest of the tested devices, takes 3 seconds to sign the message but the other devices have an average processing

time below 0.4 seconds. Signature verification uses the public-key and thus is the faster operation for the RSA

algorithm, processing time is kept under half a second for faster mobile phones, even for 4096-bit keys, and is about

300 milliseconds on the slower device for a 1024-bit key. Besides RSA the benchmark also tested other digital

signatures, including DSA (Digital Signature Algorithm), GOST and Elliptic Curve implementation of the both. Figure

0

0,5

1

0 512 1024 1536 2048

En

cry

pti

on

Tim

e

(se

con

ds)

Key strength (bits)

Nokia e61

Nokia 6630

Nokia 6288

0

5

10

15

0 512 1024 1536 2048De

cry

pti

on

Tim

e

(se

con

ds)

Key strength (bits)

Nokia e61

Nokia 6630

Nokia 6288


57 show that RSA is one of the fastest digital signature algorithms available on the Bouncy Castle API. There are two

RSA Signer engine implementations, one of which follows the PKCS# 1 standard [6].

Figure 56 – Mean RSA Signature time

Figure 57 – Mean Digital Signature engines sign time

0

50

100

150

200

0 1024 2048 3072 4096

Sig

n T

ime

(se

con

ds)

Key strength (bits)

Nokia e61

Nokia 6630

Nokia 6288

0

10

20

30

DSA ECDSA GOST ECGOST RSA RSA-PSS

Sig

n T

ime

(se

con

ds)

Signer Engine

Nokia e61

Nokia 6630

Nokia 6288

87 Conclusions

Conclusions

This dissertation is a contribute in the area of wireless payments, it builds on the successful magnetic stripe

credit/debit cards payment scenario, hence providing an alternative new payment tool, the mobile phone, to

existing scenarios. Although some mobile technologies are still immature, the main reason which thwarts the

adoption of m-payment solutions is the lack of will and agreement between the different stakeholders, the

reutilization of the credit/debit card proximity payment scenario is a step to resolve this issue.

The WPAC service-oriented open architecture focused on extensibility and interoperability, hence providing a

flexible infrastructure to develop composed payment and access control services. Security issues have been

addressed and thus demonstrated that an m-payment solution can be at least as secure as a credit/debit card

payment. Another important contribution, which diverges from existing solutions, is the dynamic risk assessment of

the payment, hence increasing the trust in the payment protocol both for clients, merchants and financial institutes.

The dynamic risk assessment, which requests different credentials to the client accordingly with the assessed risk, is

an improvement to credit/debit card payment scenario and typical e-commerce solutions.

Although Bluetooth is not the most adequate wireless communication protocol for m-payment solutions, the lack of

support for NFC, turns it the best option. Even so, the WPAC solution has proven that Bluetooth can be used for an

acceptable usage experience. The WPAC architecture is built on a modular protocol stack, thus when NFC technology

becomes gradually available, Bluetooth can be removed and replaced by NFC, or even coexist with NFC and any

emerging wireless communication protocols.

This dissertation shows that typical credit/debit card payments can be complemented with WPAC m-payment

solution, both working with the same payment capture protocol. Thus enabling, if stakeholders wish so, that

magnetic stripe cards are progressively replaced by the nomadic computational agent. The challenge of defining a

proximity and secure payment architecture, based on mobile devices without operational fees, is therefore achieved.

In order to evaluate the adaptation of this project to a business venture, we will present a SWOT (Strengths,

Weaknesses, Opportunities, and Threats) analysis that identifies the internal and external factors that are favorable

and unfavorable to achieving commercial success.

Strengths

• The reutilization of the credit/debit card payment scenario not only provides a starting point for acceptance

by stakeholders but also minimizes the learning curve for clients.

• The availability of mobile phones potentiates the success of m-payments, because the payment tool, the

mobile phone, is already carried around by most people. Also the device interface is already known by their

owners thus making the usage experience easier.

Weaknesses

• Mobile phones reply on batteries to obtain energy, therefore reducing devices dependability.

88 Conclusions

• Some mobile technologies are still immature or not yet available in mobile devices, the consolidation of

such technologies is fundamental for the improvement of m-payments.

Opportunities

• The introduction of automated points-of-sale provides an opportunity to include WPAC payments support

straight from factory.

• The continuous development of mobile devices and enthusiastic adoption of new technologies by clients,

enable the evolution of mobile phones to support hardware and wireless communication protocols better

suited to m-payments, for example devices with fingerprint recognition.

• Mobile services have been increasing both in number and type, in the beginning only voice services were

supported by mobile phones but nowadays they also include camera and music players. The inclusion of

payment and access control services is a logical step that follows this trend.

Threats

• In the last years some concerns about health hazards associated with exposure to radio frequency have

been emerging, although no significant hazards have been proven, if one does, the usage of mobile phones

and m-payment solutions is compromised.

Future Work

This dissertation discusses especially the payment scenario, although access control is a subset of the payment

solution, where the identity proof is used to control the access, an interesting future task is to define a mobile

ticketing solution by extending the WPAC payment solution.

Typically electronic payments are traceable, thus the identity of every entity participating in the payment chain is

known. Although such approach is acceptable it is interesting to study the possibility the support anonymous digital

cash in m-payment solutions. With the expected gradually support of NFC by mobile phones the WPAC

communication layer should update in order to support NFC as a wireless communication protocol.

89 Acronyms and abbreviations

Acronyms and abbreviations

AES: Advanced Encryption Standard AMPS: Advanced Mobile Phone System API: Application Programming Interface ARM: Advanced RISC Machine ATM: Automatic Teller Machine B2C: Business-to-Consumer CA: Certification Authority CMDA: Code Division Multiple Access DoS: Denial-of-Service DSSS: Direct Sequence Spread Spectrum E-commerce: electronic commerce E-payment: electronic payment EDGE: Enhanced Data for Global Evolution FHSS: Frequency Hopping Spread Spectrum GPRS: General Packet Radio Service GSM: Global System for Mobile communications HMAC: Hash-based Message Authentication Code IMS: Industrial, Scientific, and Medical band IrDA: Infrared Data Association JVM: Java Virtual Machine L2CAP: Logical Link Control and Adaptation Protocol M-commerce: mobile commerce M-payment: mobile payment M-ticket: mobile ticket MNO: Mobile Network Operator NFC: Near Field Communication OBEX: OBject Exchange OFDM: Orthogonal Frequency Division Multiplexing P2P: Peer-to-Peer PDA: Personal Digital Assistant PIN: Personal Identification Number PKI: Public-Key Infrastructure POS: Point-Of-Sale RA: Registration Authority RF: Radio Frequency RFCOMM: Radio Frequency COMMunications RFID: Radio Frequency Identification RSA: Rivest, Shamir and Adleman SDK: Software Development Kit SOA: Service Oriented Architecture SOAP: Simple Object Access Protocol SMS: Short Message Service TACS: Total Access Control System UMD: Ultra-Mobile Device UMTS: Universal Mobile Telecommunication System URL: Uniform Resource Locator WAP: Wireless Application Protocol WML: Wireless Markup Language

XML: eXtensible Markup Language

90 References

References

[1] Jerry Gao, Jacky Cai, Kiran Patel, and Simon Shim, “A Wireless Payment System”, Proceedings of the Second

International Conference on Embedded Software and Systems, 2005 (ICESS’05).

[2] Saleem Kadhiwal and Muhammad Zulfiquar, Ali Bhutto Institute of Science and Technology, Pakistan,

“Analysis of mobile payment security measures and different standards”, Computer Fraud & Security, June

2007.

[3] Rob Macgregor, Catherine Ezvan, Luis Fernando Liguori and JaeSool Han, “Secure Electronic Transactions:

Credit Card Payment on the Web in Theory and Practice”, First Edition, IBM, June 1997.

[4] PayPal Mobile, https://www.paypal.com/mobile

[5] TMN M-Ticket, http://www.tmn.pt

[6] Wikipedia, http://en.wikipedia.org

[7] Anacom, http://www.anacom.pt/

[8] History of Automatic Teller Machines (ATM), http://inventors.about.com/od/astartinventions/a/atm.htm

[9] Glyn Davies, “A History of Money - From Ancient Times to the Present Day”, Third Edition, University of

Wales Press, Cardiff, 2002.

[10] E-Gold, http://www.e-gold.com/

[11] Bruce Schneier, “Applied cryptography: protocols, algorithms, and source code in C”, Second Edition,

Wiley, 1996.

[12] A. Luís Osório, Luís Sousa, Pedro Henriques, Gustavo Castelo, Diogo Remédios, Hugo Maurício, José Albino,

Rogério Rocha, Fernando Fortes, Carlos Gonçalves and António Serrador, “Wireless Money - Reference

Manual”, March 2007.

[13] Tatsuaki Okamoto and Kazuo Ohta, "Universal Electronic Cash," Advances in Cryptology-CRYPTO '91

Proceedings, Springer-Verlag, 1992, pp. 324-337.

[14] H. Wang and Y. Zhang, “Untraceable Off-line Electronic Cash Flow in E-Commerce”, Proceedings of the 24th

Australasian conference on Computer science, 2001.

[15] Steven H. Low, Nicholas F. Maxemchuk and Sanjoy Paul, “Anonymous Credit Cards and Their Collusion

Analysis”, IEEE/ACM Transactions on Networking Vol. 4 No. 6, 1996, pp. 809-816.

[16] Ed Gerck, “IT Security: Hackers, Crackers, Thugs”, NCR, July 2002.

91 References

[17] Wen-Chen Hu, Chung-wei Lee and Weidong Kou, “Advances in Security and Payment Methods for Mobile

Commerce”, Idea Group Publishing, 2005

[18] Vincenzo Auletta, Carlo Blundo, Emiliano De Cristofaro and Guerriero Raimato “Performance Evaluation of

Web Services Invocation over Bluetooth”, Proceedings of the ACM international workshop on Performance

monitoring, measurement, and evaluation of heterogeneous wireless and wired networks, 2006,

Terromolinos, Spain

[19] David McKitterick, “A Web Services Framework for Mobile Payment Services”, A dissertation submitted to

the University of Dublin, in partial fulfillment of the requirements for the degree of Master of Science in

Computer Science, September 2003

[20] CTT - Correios de Portugal S. A., www.ctt.pt

[21] Entering PIN Backwards, Banking Questions,

http://www.bankingquestions.com/accounts/q_backwardpin.html

[22] Nokia Forum, http://www.forum.nokia.com

[23] EmCarga, http://www.emcarga.pt/

[24] Lisha He, Ning Zhang, Lirong He and Ian Rogers, “Secure M-commerce Transactions: A Third Party Based

Signature Protocol”, Third International Symposium on Information Assurance and Security, 2007

[25] Jongsung Kim, Alex Biryukov, Bart Preneel and Seokhie Hon, “On the Security of HMAC and NMAC Based on

HAVAL, MD4, MD5, SHA-0 and SHA-1”, 2006

[26] RSA Laboratories, “How large a key should be used in the RSA cryptosystem?”,

http://www.rsasecurity.com/rsalabs/node.asp?id=2218

[27] M.J.B. Robshaw, “Security estimates for 512-bit RSA”, RSA Laboratories, 1995.

[28] Srivaths Ravi, Anand Raghunathan and Nachiketh Potlapally, “Securing Wireless Data: System Architecture

Challenges”, 15th International Symposium on System Synthesis, 2002, Japan.

[29] Homin K. Lee, Tal Malkin and Erich Nahum, “Cryptographic Strength of SSL/TLS Servers: Current and Recent

Practices”, Proceedings of the 7th ACM SIGCOMM conference on Internet measurement (IMC’07), October

2007

[30] Cristian Coarfa, Peter Druschel and Dan S. Wallach, “Performance Analysis of TLS Web Servers”, ACM

Transactions on Computer Systems (TOCS), February 2006

[31] Mihir Bellare, Ran Canetti and Hugo Krawczyk, “Keying Hash Functions for Message Authentication”,

Advances in Cryptology - Crypto 96 Proceedings, June 1996

92 References

[32] David Wagner and Bruce Schneier, “Analysis of the SSL 3.0 protocol”, Proceedings of the USENIX

Conference on Electronic Commerce (WOEC'96), November 1996.

[33] Lawrence C. Paulson, “Inductive Analysis of the Internet Protocol TLS”, ACM Transactions on Information

and System Security (TISSEC), August 1999.

[34] IETF, “RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2”,

http://tools.ietf.org/html/rfc5246

[35] L. Harn, “Batch verifying multiple RSA digital signatures”, Electronics Letters Volume 34, Issue 12, 11 June

1998, pages 1219 – 1220.

[36] Liang Jin, ShiRen, LiangFeng, and GaoZhengHua, “Research on WAP Client Supports SET Payment Protocol”,

IEEE Wireless Communications, February 2002

[37] Giampaolo Bella, Fabio Massacci and Lawrence C. Paulson, “The verification of an industrial payment

protocol: the SET purchase phase”, Proceedings of the 9th ACM conference on Computer and

Communications Security, November 2002

[38] Fulvio Ricciardi, “Kerberos Protocol Tutorial”, MIT Kerberos Consortium

http://www.kerberos.org/software/tutorial.html

[39] Jonathank Knudsen and Sing Li, “Beginning J2ME – From novice to professional”, Apress, 3rd Edition, 2005

[40] Alan Harbitter and Daniel A. Menascé, “The Performance of Public Key-Enabled Kerberos Authentication in

Mobile Computing Applications”, Proceedings of the 8th ACM conference on Computer and

Communications Security, November 2001

[41] Claude E. Shannon, “Communication Theory of Secrecy Systems”, Bell System Technical Journal, vol. 28,

page 656–715, October 1949.

[42] Federal Information Processing Standards Publication 197, “Advanced Encryption Standard (AES)”,

November 2001.

[43] N. Ferguson, J. Kelsey, S. Lucks, B. Schneier, M. Stay, D. Wagner and D. Whiting, “Improved Cryptanalysis of

Rijndael”, Seventh Fast Software Encryption Workshop, Springer-Verlag, 2000

[44] Ronald L. Rivest, Benjamin Agre, Daniel V. Bailey, Christopher Crutchfield, Yevgeniy Dodis, Kermin Elliott

Fleming, Asif Khan, Jayant Krishnamurthy, Yuncheng Lin, Leo Reyzin, Emily Shen, Jim Sukha, Drew

Sutherland, Eran Tromer and Yiqun Lisa Yin, “The MD6 hash function – A proposal to NIST for SHA-3”,

Massachusetts Institute of Technology, October 2008

[45] National Institute of Standards and Technology, “Secure Hashing”,

http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

[46] Ed Gerck, “Overview of Certification Systems: x.509, CA, PGP and SKIP”, in The Black Hat Briefings '99

93 References

[47] D. Richard Kuhn, Vincent C. Hu, W. Timothy Polk and Shu-Jen Chang, “Introduction to Public Key

Technology and the Federal PKI Infrastructure”, NIST, February 2001

[48] Annika Paus, “Near Field Communication in Cell Phones”, Ruhr-University Bochum Seminar, July 2007

[49] Vassilis Kostakos and Eamonn O’Neill, “NFC on mobile phones: issues, lessons and future research”,

Proceedings of the Fifth IEEE International Conference on Pervasive Computing and Communications

Workshops, March 2007

[50] Jan Ondrus and Yves Pigneur, “Near field communication: an assessment for future payment systems?”,

Information Systems and E-Business Management, Springer-Verlag, June 2008

[51] Mohsen Toorani and Ali Asghar Beheshti Shirazi, “LPKI - a Lightweight Public Key Infrastructure for the

mobile environments”, 11th IEEE International Conference on Communication Systems, 2008.

[52] Yuliang Zheng, “Signcryption”, http://www.signcryption.net/

[53] Jill Attewell, “Mobile technologies and learning”, Learning and Skills Development Agency, 2005

[54] GetJar, “Manufacturer market share”, http://stats.getjar.com/statistics/

[55] Commission of the European Communities, “Progress Report on the Single European Electronic

Communications Market 2008”, Brussels, March 2009

[56] Otto Kolsi and Teemupekka Virtanen, “MIDP 2.0 Security Enhancements”, Proceedings of the 37th Hawaii

International Conference on System Sciences, 2004

[57] Tuomas Aura, Pekka Nikander and Jussipekka Leiwo, “DOS-resistant Authentication with Client Puzzles”,

Helsinki University of Technology and Vrije Universiteit, 2000

[58] Glade Diviney, “An Introduction to Short-Range Wireless Data Communications”, Embedded Systems

Conference, San Francisco, April 2003

[59] Emily Clark, “Always-on mobile Internet device sales to reach 95 million by 2012”,

http://www.gizmag.com/go/8050/, Gizmag, September 2007

[60] Qusay H. Mahmoud, “Deploying Wireless Java Applications”,

http://developers.sun.com/mobility/midp/articles/deploy/, Sun, October 2002

[61] GrIDsure, http://www.gridsure.com/

[62] Mehdi Khosrow-Pour, “Encyclopedia of E-commerce, E-Government and Mobile Commerce”, USA, 2006

[63] Legion of the Bouncy Castle, http://www.bouncycastle.org/

94 References

[64] David Kammer, Gordon McNutt, Brian Senese and Jennifer Bray, “Bluetooth Application Developer’s

Guide”, Syngress, 2002

[65] Java Community Process, “JSR 82: Java APIs for Bluetooth”, http://jcp.org/en/jsr/detail?id=82

[66] Marek Bialoglowy, “Bluetooth Security Review”, Security Focus, 2005,

http://www.securityfocus.com/infocus/1830

[67] Forum Nokia Developer Discussion Boards,

http://discussion.forum.nokia.com/forum/showthread.php?t=70180

[68] kSOAP, http://ksoap2.sourceforge.net/

[69] Java Community Process, “JSR 177: Security and Trust Services API for J2ME”,

http://jcp.org/en/jsr/detail?id=177

[70] Java Community Process, “JSR 172: J2ME Web Services Specification”,

http://jcp.org/en/jsr/detail?id=172

[71] Avetana, “Bluetooth JSR-82”, http://www.avetana-gmbh.de/avetana-gmbh/produkte/jsr82.eng.xml

[72] W3C, “XML Encryption Syntax and Processing”, http://www.w3.org/TR/xmlenc-core/

[73] W3C, “XML Signature Syntax and Processing (Second Edition)” http://www.w3.org/TR/xmldsig-core/

[74] SEMOPS, http://www.semops.com/

95 Appendix

Appendix

Purchase Protocol WSDL

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://www.wpac.org" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="WPAC" targetNamespace="http://www.wpac.org"> <wsdl:types> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.wpac.org"> <xsd:complexType name="PaymentData"> <xsd:sequence> <xsd:element minOccurs="0" maxOccurs="1" name="merchantTransactionId" type="xsd:long" /> <xsd:element minOccurs="1" maxOccurs="1" name="amount" type="xsd:int" /> <xsd:element minOccurs="1" maxOccurs="1" name="merchantInfo" type="tns:MerchantInfo" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="PaymentCredentials"> <xsd:sequence> <xsd:element minOccurs="0" maxOccurs="1" name="merchantId" type="xsd:long" /> <xsd:element minOccurs="0" maxOccurs="1" name="merchantTransactionId" type="xsd:long" /> <xsd:element minOccurs="1" maxOccurs="1" name="amount" type="xsd:int" /> <xsd:element minOccurs="1" maxOccurs="1" name="clientCredentials" type="tns:ClientCredentials" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="PaymentReceipt"> <xsd:sequence> <xsd:element minOccurs="0" maxOccurs="1" name="merchantTransactionId" type="xsd:long" /> <xsd:element minOccurs="1" maxOccurs="1" name="amount" type="xsd:long" /> <xsd:element minOccurs="1" maxOccurs="1" name="datetime" type="xsd:string" /> <xsd:element minOccurs="1" maxOccurs="1" name="merchantInfo" type="tns:MerchantInfo" /> <xsd:element minOccurs="0" maxOccurs="1" name="status" type="xsd:string" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="MerchantInfo"> <xsd:sequence> <xsd:element minOccurs="0" maxOccurs="1" name="merchantId" type="xsd:long" /> <xsd:element minOccurs="1" maxOccurs="1" name="name" type="xsd:string" /> <xsd:element minOccurs="0" maxOccurs="1" name="local" type="xsd:string" /> <xsd:element minOccurs="1" maxOccurs="1" name="localCode"

type="xsd:integer" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="ClientCredentials"> <xsd:sequence> <xsd:element minOccurs="0" maxOccurs="1" name="clientId" type="xsd:long" /> <xsd:element minOccurs="1" maxOccurs="1" name="clientAccountNumber" type="xsd:long" /> <xsd:element minOccurs="1" maxOccurs="1" name="clientAuthorizationCode" type="xsd:string" /> </xsd:sequence> </xsd:complexType> </xsd:schema> </wsdl:types> <wsdl:message name="getPaymentDataRequest" /> <wsdl:message name="getPaymentDataResponse"> <wsdl:part name="paymentData" type="tns:PaymentData" /> </wsdl:message> <wsdl:message name="confirmPaymentRequest"> <wsdl:part name="paymentCredentials" type="tns:PaymentCredentials" /> </wsdl:message> <wsdl:message name="confirmPaymentResponse"> <wsdl:part name="paymentReceipt" type="tns:PaymentReceipt" /> </wsdl:message> <wsdl:portType name="WPAC"> <wsdl:operation name="getPaymentData"> <wsdl:input message="tns:getPaymentDataRequest" />

96 Appendix

<wsdl:output message="tns:getPaymentDataResponse" /> </wsdl:operation> <wsdl:operation name="confirmPayment"> <wsdl:input message="tns:confirmPaymentRequest" /> <wsdl:output message="tns:confirmPaymentResponse" /> </wsdl:operation> </wsdl:portType> <wsdl:binding name="WPACSOAP" type="tns:WPAC"> <soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/bluetooth" /> <wsdl:operation name="getPaymentData"> <soap:operation soapAction="http://www.wpac.org/getPaymentData/" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="confirmPayment"> <soap:operation soapAction="http://www.wpac.org/confirmPayment/" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="WPAC"> <wsdl:port binding="tns:WPACSOAP" name="WPACSOAP"> <soap:address uuid="CDEB7440-A89F-11DE-8A39-0800200C9A66" /> </wsdl:port> </wsdl:service> </wsdl:definitions>

WPAC_dissertation

Documents

Transcript of WPAC_dissertation