INSTITUTO SUP Departamento d Computadores Dispositivos M Ped Dissertação de nat Mestre em Orientadores: Professor- Júri: Presidente: Coorde Vogais: Professor-adjun Mestre Jorge Sa PERIOR DE ENGENHARIA DE LISBOA de Engenharia de Electrónica e Telecomuni Móveis no Pagamento de Serv Controlo de Acessos dro Miguel Alves Henriques (Bacharel) tureza científica realizada para obtenção do m Engenharia Informática e de Computadores (Documento Provisório) -coordenador António Luís Freixo Guedes Osó enador do Mestrado, ISEL nto Doutor Ricardo André Fernandes Costa, ESTG ales Gomes, Brisa Novembro de 2009 icações e de viços e grau de s ório, ISEL GF
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
Dispositivos Móveis no Pagamento de Serviços e
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
State of Art ..................................................................................................................................................................... 16
Mobile Payment and Access Control ......................................................................................................................... 16
Access Control Solutions ........................................................................................................................................ 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
Communication layer ............................................................................................................................................. 48
Normal Risk ............................................................................................................................................................ 54
High Risk................................................................................................................................................................. 54
Very High Risk ........................................................................................................................................................ 54
Time and Place ....................................................................................................................................................... 58
Secure communication channel ................................................................................................................................. 67
Purchase Web Service ................................................................................................................................................ 76
Data Model ............................................................................................................................................................ 77
Bluetooth Binding .................................................................................................................................................. 78
Bluetooth Discovery ................................................................................................................................................... 78
Inquiry time and device discovery ......................................................................................................................... 78
Service search ........................................................................................................................................................ 80
Friendly name search ............................................................................................................................................. 81
Same Bluetooth address ........................................................................................................................................ 82
Digital Signatures ................................................................................................................................................... 85
Future Work ............................................................................................................................................................... 88
Acronyms and abbreviations .......................................................................................................................................... 89
Figure 2 – Access control scenario overview .................................................................................................................. 15
Figure 3 – Ways to use PayPal Mobile ............................................................................................................................ 16
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 17 – Car parking payment scenario ..................................................................................................................... 40
Figure 18 – Street vendor payment scenario ................................................................................................................. 40
Figure 19 – Gas station payment scenario ..................................................................................................................... 40
Figure 43 – Purchase Protocol data model ..................................................................................................................... 77
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 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
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.
76 WPAC Implementation
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
77 WPAC Implementation
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
-merchantTransactionId
-amount
-clientCredentials
PaymentCredentials
1
1
-merchantTransactionId
-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
78 WPAC Implementation
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
79 WPAC Implementation
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
80 WPAC Implementation
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
81 WPAC Implementation
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
82 WPAC Implementation
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
83 WPAC Implementation
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.
84 WPAC Implementation
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
85 WPAC Implementation
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
86 WPAC Implementation
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