MOBILE COMMERCE PAYMENT METHODS
Among the many issues that arise with mobile
commerce security, mobile payment methods are probably the most crucial.
These are the methods used to pay for goods or services with a mobile
handheld device. A typical mobile payment scenario is as follows:
A user registers for the services via an Internet-enabled mobile handheld device.
The user submits his/her payment for the services he/she has received.
The
service/content provider deals with the request by authenticating and
authorizing the user and then contacting a wireless service provider and
a financial institution.
A confirmation of the completed transaction is delivered to the user.
This section examines the issues involved and
describes a set of standards for mobile payments. With the development
of commerce, there has been a tremendous evolution in the methods of
payment, from the seashell of ancient times to coins and notes, from
writing checks to on-line banking. The emergence of e-commerce has
revolutionized the traditional methods of payment. With the help of
mobile devices, the dream of "transaction without cash on the move" is
now possible. Mobile payment enables the transfer of financial value and
corresponding services or items between different participators without
the need for any actual physical contact between them. The mobile
device can be a wireless communication device, such as a mobile phone, a
PDA, a wireless tablet, or a mobile computer. Mobile payment can be
divided into two categories, generally according to the amount of
transaction value. One is micro-payment, which defines a mobile payment
of approximately $10 or less, often for mobile content such as video
downloads or gaming. The other is macro-payment, which refers to larger
value payments.
Mobile Payment Scenarios
The global spread of mobile telecommunications
has been so successful that the number of mobile subscribers had risen
to one billion worldwide by the end of 2002. In 2003, 60 million users
spent more than $50 billion on mobile services. One survey predicted
that combined e-commerce and m-commerce volumes would grow from $38
billion in 2002 to $128 billion in 2004. Accompanying this increase in
subscriptions has been an evolution in the sophistication level of
mobile devices, encouraging the emergence of new applications such as
enhanced messaging services (EMS) and multimedia messaging services
(MMS). In these applications, consumers are presented with more options,
such as the download of images, streaming video, and data files as well
as the addition of global positioning systems (GPS) in mobile phones,
which will facilitate location-based mobile commerce and make mobile
payment methods more feasible.
There are four participants in a mobile payment
transaction. The mobile consumer (MC) subscribes to a product or service
and pays for it via their mobile device. The content provider/merchant
(CP/M) provides the appropriate digital content, physical product, or
service product to the consumer. The payment service provider (PSP),
which may be a network operator, a financial institution, or an
independent payment vendor, controls the payment process. The trusted
third party (TTP) administers the authentication of transaction parties
and the authorization of the payment settlement. In fact, several of
these roles can be merged into one organization, e.g. a network bank,
which is capable of acting as CP/M, PSP, and TTP at the same time. In a
more general sense, a PSP and TTP can be performed by the same
organization.
Content Download
In this scenario, the consumer orders the
content he or she wants to download from a content provider. The content
provider then initiates the charging session, asking the PSP for
authorization. The PSP authorizes the CP/M, and then the download
starts. The transaction can be settled by either a metered or pricing
model. Metered content includes streaming services, where consumers are
charged according to the metered quantity of the provided service, e.g.,
the interval, the data volume or the number of game sessions. In a
pricing model, the consumer is charged according to the items downloaded
completely. A content purchase is also available via a PC Internet
connection, where the mobile device can be used to authorize the payment
transaction and authenticate the content user.
Point of Sale
In this scenario, services or the sale of goods
are offered to the mobile user using a point of sale location instead of
a virtual site, e.g., a taxi service. The merchant (e.g. the taxi
driver) will initiate the payment at the point of sale. The PSP asks the
mobile user to directly authorize the transaction via a SMS PIN, or
indirectly via the taxi driver through a wireless Bluetooth link. The
process is also applicable to purchases from a vending machine.
Content on Device
In this payment scenario, the user has the
content preinstalled in his/her mobile device, but he or she must be
granted a license to initiate the usage of the content, e.g., the
activation of an on-demand game playing service. The license varies with
usage, duration, or number of users, and determines the value that the
consumer must pay for the desired content.
Mobile Payment Methods
Two common kinds of mobile commerce payment methods are
Macropayments:
This kind of payments is commonly used by traditional electronic
commerce and involve significant amounts of money, for example more than
US $10.00. Payments by credit cards are the most common method for
macropayments.
Micropayments: These usually involve small amounts of below about US $10.00, which are too small to be economically processed by credit cards.
The amounts are usually charged to users' phone bills or accounts.
A typical macropayment/micropayment scenario proceeds as follows, as illustrated in Figures 2 and 3 for macro and micropayments, respectively, where the number is the order of steps taken:
A mobile user submits his/her credit-card or personal information to the mobile content via a handheld device.
A third-party processor verifies and authorizes the transaction.
The third-party processor routes verification and authorization requests to the card issuing bank or mobile carrier.
The user pays his/her monthly credit-card or phone bill.
The
bank pays the mobile content provider or the mobile carrier pays the
mobile content provider directly or through a bank after deducting a
transaction fee.
Mobile Payment Operations
In a card transaction, there are usually four
stages, including set-up and configuration, the initiation of the
payment, authentication of the user, and completion of the payment. In
the mobile payment environment, the payment methods can share the same
dynamics. Within the four stages, there are certain kinds of operations
among the four parties, although not all the operations may be needed,
depending on the stages and scenarios.
Registration.
There is a communication between the MC and CP/M that ensures that the
content is accessible. During this stage, the MC uses a personal
identification number (PIN) for identification and authentication. The
MC obtains service details such as the category of payment, the
characteristic of the content, as well as the confirmation of the
payment after the service. During this operation, an identity number is
allotted to the consumer, which uniquely defines the identity of the
CP/M during each transaction and a service is initiated. In general,
this operation ensures the security of the payment.
Charging.
Once the registration is completed, the CP/M submits the authentication
and authorization requests to the PSP, initiating the charging session.
At the end of every service or time interval, the content provider asks
for a charging operation. The PSP settles the payment according to the
default scheme, notifying both parties. This is usually presented to
mobile consumers in the form of a receipt.
Request authorization and authentication.
Before the start of a charging session, the mobile consumers must
confirm that they are willing to pay for the service. This authorization
request is often sent from the PSP in the form of a contract. The
contract will describe the conditions and agreements between the MC and
the CP/M. The charging session is initiated by the customer's acceptance
of the contract. The MC is also requested to authorize the PSP. This
can be settled by submitting the PIN from the MC. Authorization and
authentication are completed using the same request. Authorization
includes the authentication by PIN.
User authentication.
The PSP will notify the authentication result of the MC to the CP/M. If
the return of authorization request from the MC is positive, the PSP
sends the CP/M a session ID, signaling the initiation of a charging
session. It is vital to distinguish between micro- and macro-payments,
since the security required in the two types is distinctly different.
For example, authentication for every macro-payment transaction through a
trusted financial entity is extremely important, whereas network
authentication, such as SIM, may be sufficient for micro-payments that
only use the operator's infrastructure.
Out-of-Band Payment Method
In the "out-of-band" model, content and
operation signals are transmitted in separate channels, e.g., a credit
card holder may use their mobile device to authenticate and pay for a
service they consume on their fixed line Internet or interactive TV.
This model usually involves a system controlled by a financial
institution, sometimes collaborating with a mobile operator. There are
two typical cases:
Financial institutions.
Many banks are conducting research designed to turn an individual
mobile unit into a disbursing terminal. Payments involved in the
financial transaction are usually macro-payments, and various methods
can be deployed to ensure the authentication of payment transactions. In
credit card payments, a dual slot phone is usually adopted, while other
approaches include PIN authentication via a SIM toolkit application or
the use of a digital signature based on a public key infrastructure
(PKI) mechanism, which requires 2.5G (or higher) technology.
Reverse-charge/billed SMS.
In reverse-billed premium rate SMS, the CP/M deliver content to mobile
telephone handsets (ICSTIS, n.d.). Customers subscribe to a service and
are charged for the messages they receive. This payment model allows
consumers to use SMS text messages to pay for access to digital
entertainment and content without being identified. In this application,
however, it is the SMS message receiver who is charged, instead of the
sender of the SMS message. There are a considerable number of vendors
who use reverse-charge/billed MSM service payment models.
"Inband" Payment Method
In this method, a single channel is deployed
for the transfer of both content and operation signals, for example for a
chargeable WAP service over GPRS. Two models of this in-band payment
are in common use, namely subscription models and per usage payment
models, with the amount of the payment usually being micro-payments.
In-band transactions include applications such as video streaming of
sports highlights or video messaging.
Proximity
Proximity payments involve the use of wireless
technologies to pay for goods and services over short distances.
Proximity transactions develop the potential of mobile commerce, e.g.,
using a mobile device to pay at a point of sale, vending machine, ticket
machine, market, or for parking. Through short range messaging
protocols such as Bluetooth, infrared, RFID, and contactless chips, the
mobile device can be transformed to a sophisticated terminal that is
able to process both micro and macro payments .
Mobile Payment Standardization
Common Issues of Mobile Payment Standards
Mobile payment enables users to globally
conduct payment transactions without physical contact. Unfortunately,
regional distinctions and market dynamics often impose barriers that
impede its development. A set of standards is required that are shared
by all four of the parties involved, but dominant corporations are
competing for the acceptance of their own standards, which will give
them an advantage in their competition with their rivals. Among the
different standards that are currently being proposed, the common issues
being addressed include:
Security.
Fraud deters usage and damages the trust of consumers and merchants in
the integrity of the payment network. In addition, it adds considerably
to the cost of operation. Therefore, increased security is vital for the
development of mobile payment methods to address these issues. The main
security elements include:
Authentication: This allows the payment service provider to determine that the person using the payment product is the authorized user.
Confidentiality: This ensures that unauthorized parties cannot gain access to sensitive payment data.
Data integrity: This ensures that payment data is not altered.
Non-repudiation: This binds the parties to the transaction so that they cannot later deny that they participated in it.
Interoperability.
This strengthens any global payment system, ensuring that any
participating payment product can be used at any participating merchant
location.
Usability.
According to studies of consumers' consumption behavior, they do not
like to change their established habits and tend to opt for products
that are user-friendly. This observation underlies the requirement for
usability.
Standardization of the Payment Lifecycle
In support of uniform payment standards, the
MPF (Mobile Payment Forum) is working on standardizing the phases in the
mobile payment lifecycle, namely device set-up and personalization,
payment initiation, authentication and payment completion:
Set-up and configuration.
When a mobile device is used to make a purchase, the owner who wants to
get access to the mobile services should be able to set up the payment
mechanism in the mobile environment. Set-up and configuration could take
place over a mobile network or the Internet, or they could be done
physically.
Payment initiation. In this step, payment information is transmitted to the merchant over a network.
Authentication.
The authentication of the user is essential for any payment
transaction. The MPF is considering two-way messaging authentication and
SAT (SIM Alliance/Application Toolkit) authentication applications. The
SAT authentication standardization includes defining a set of minimum
requirements for authenticating, hence the cost of the bandwidth can be
considerably reduced.
Payment completion.
This process takes place after the cardholder's details have been
authenticated and the transaction is authorized. In a normal physical
transaction, this involves the printing of a receipt for the user to
confirm that the money has been transferred. In the mobile environment,
the MPF is currently studying issues concerning the format and storage
of digital receipts, together with the necessary redirection mechanisms.
SET (Secure Electronic Transaction)
Developed by Visa International and MasterCard
International, the Secure Electronic Transaction (SET) protocol (SET
Secure Electronic Transaction Specification, Version 1.0, 1997) is
likely to become the global standard in the domain of electronic
commerce over the Internet. This is a technical standard designed to
provide security for payment transactions among cardholders, merchants,
payment gateways, and certification authorities in wired networks. The
SET mechanism is complex, and thus is mostly used in desktop computers
and servers.
An SET transaction typically involves a
communication between four parties: the customer, the merchant, the
customer's bank, and the merchant's bank. Each of these entities needs
to know certain information in order to perform its part of the
transaction, but none need to know all the details of the transaction.
Neither bank, for instance, needs to know what the customer is buying.
The merchant doesn't need to know the customer's credit card number. He
just needs to know that the customer has enough credit to pay for the
order. The customer doesn't need to know who the merchant banks with.
Assuming that the customer has an SET-enabled browser and that the
transaction provider (bank, store, etc.) has a SET-enabled server, the
process works as follows.
The customer opens a Mastercard or Visa account
with some issuer (a bank) of credit cards and receives a digital
certificate, which represents that customer/card combination in online
purchases. The certificate contains both a public key and an expiration
date.
Merchants
also receive certificates from the credit card issuer. These
certificates include the merchant's public key and the public key of the
merchant's bank.
The customer places an order over a web page by computer, phone or PDA.
The customer's browser requests and receives the merchant's certificate and confirms that the merchant is valid.
The
customer's browser sends the order and payment information (as two
separate components) in a message that also contains the customer's
certificate. The payment information is encrypted with the merchant's
bank's public key and can't be read by the merchant. The order
information is encrypted with the merchant's public key and can't be
read by the bank. Additional information in the message ensures the
payment can only be used with this particular order.
The
merchant verifies the customer by checking the customer's digital
certificate. This may be done by referring the certificate to the bank
or to a third-party verifier.
The
merchant sends a message to the merchant's bank which contains the
customer's payment information, and the merchant's certificate.
The
merchant's bank verifies the identity of the merchant and the identity
of the customer's bank, which is embedded in the payment information.
The
merchant's bank requests a payment authorization from the customer's
bank. The customer's bank sends this (if the transaction is approved)
and the merchant's bank relays this back to the merchant.
The
merchant completes the transaction with the customer, fills the order,
and tells the merchant's bank (who relays this confirmation to the
customer's bank) that this order has been completed.
The customer's bank generates billing information for the customer and settles accounts with the merchant's bank.
Because SET relies on public key encryption to
verify the identities of the customer, merchant and financial
institution, as well as the symmetric encryption of an SSL or S-HTTP
session, its computational demands are significant.
In a mobile commerce system, a WAP client device
normally does not have sufficient processing and memory capability to
utilize SET software. A "thin" SET wallet approach has thus been proposed to adapt the SET protocol for WAP clients. Under
the "thin" SET wallet model, most of the functionality of current "fat"
SET wallets is moved to the wallet server. To support a SET payment, a
WAP client installed with only a "thin" wallet securely connects with a
wallet server, which communicates with other SET entities. When SET
purchase requests arrive from the "thin" wallet, the wallet server takes
over the responsibility of routing requests and managing digital keys
and certificates.
Wireless cellular system operators have an
advantage as they become primary mobile payment system providers,
because their existing service infrastructures already contain mature
subscriber authentication and billing subsystems such as SIM. They can
thus act as middlemen, charging an extra service fee, when transactions
between merchants and users take place using their network systems. The
i-mode model is one of this type.
Another approach is referred to as the
"dual-chip" solution. This uses a Wireless Identity Module (WIM) card
holding cryptographic keys as a second authentication module for the WAP
security service. WIM can be apart of a SIM smart card issued by a
cellular system operator or it can be provided by a third party, such as
a bank or a financial institution. Motorola's Star Tac Dual Slot
handset is capable of reading a third-party WIM card. The mobile payment
standardization currently in use was developed by several
organizations, as follows:
Mobey Forum (n.d.):
Founded by a number of financial institutions and mobile terminal
manufacturers, Mobey Forum's mission is to encourage the use of mobile
technology in financial services.
Mobile Payment Forum (n.d.):
Sponsored by credit card companies, including American Express,
MasterCard International and Visa International, the Mobile Payment
Forum is dedicated to developing a framework for standardized, secure,
and authenticated mobile commerce using payment card accounts.
Mobile electronic Transactions (MeT) Ltd. (n.d.):
Sponsored by key handset manufacturers such as Ericsson, NEC, Nokia,
Panasonic, Siemens and Sony Ericsson, MeT's objective is to ensure
interoperability of mobile transaction solutions. Its work is based on
existing specifications and standards, including WAP.
Mobile Security Risk Management
Whenever there are risks or dangers, it is
advisable to find ways of dealing with that risk. It is possible, of
course, to pretend the risk does not exist and ignore it, but that is
not wise when the potential consequences are great. The three main
categories into which protective measures can be placed are (i) policies
and procedures, (ii) awareness, education and training, and (iii)
technology. Risk management also requires an examination of the
cost/benefit ratio and a decision to be made as to whether or not the
risk justifies the expense. Some protective measures, though desirable,
will not be implemented because of the cost or the cost/benefit ratio.
Policies and Procedures
A security policy is a statement of usage rules
and principles that specifies which activities are allowed and which
are not allowed on that system. Policies will also typically list the
rights of the users, and the rights of the employer, legal notices about
copyrights and system monitoring, and a statement of management's
intent to prosecute misusers. These policies are created and/or approved
by high-level management and are intended to be read and adhered to by
all users. Procedures are specific processes, approved by management,
providing implementations or implementation guidelines that aid in
enforcing the policy. By following procedures, users are forced to
exercise due diligence, which protects the system from unnecessary risks
and careless oversights. However, procedures are followed voluntarily
by users, so they will not offer any protection against a malicious
user. What happens if a PDA containing important private information is
lost or misplaced? A well-established security procedure may be
available to ensure an appropriate response. What types of information
should have been (or NOT have been) on that PDA? Again, a security
procedure could have guide decisions as to what to upload/download
between a PC and PDA.
Awareness, Education, and Training
It is not feasible to write policies and
procedures that cover all future events. Some are impossible to foresee,
others may occur so rarely that they are simply not worth worrying
about. Others may just involve the use of common sense, which it is
assumed that all users will have. Thus, policies and procedures need to
be augmented with some efforts to develop users' knowledge of these
procedures, insight and intuition, so that they are more likely to
respond correctly. Educating users and raising awareness of security
concerns is a responsibility of management.
Technological Tools
Sometimes, a technological solution is
available to address a security concern. If so, it may not be necessary
to trust users to do the right thing because it will be done
automatically by an automated tool. Link-level encryption, for instance,
ensures that all transmissions are encrypted and does not rely on users
to encrypt their own files before transmitting them, nor does it
require the user to safeguard an encryption key. Biometric devices such
as fingerprint scanners can be used to implement authentication with a
higher level of confidence. Special Publication 800-48, Wireless Network Security from the National Institute of Standards and Technology is a useful source of information and guidelines for securing systems with wireless components.
Special Risks Associated with Mobile Security
While most mobile commerce security risks are
shared with non-mobile systems, there are a number of risks which are
particularly associated with handheld systems and mobile commerce.
Special risks that affect mobile handheld systems include:
Wireless devices broadcast signals may be easily intercepted.
Broadcast frequencies can be jammed. This is another technique often used in denial of service attacks.
Handheld devices, with limited processing capability, have modest capabilities for encryption and decryption.
There is no firewall.
Mobile handheld devices are easily misplaced or lost. Physical security is therefore more of a problem.
Limited
storage on handheld devices means that some of a customer's private
information may be stored at a WAP gateway. This makes the gateway an
attractive target for attacks.
Mobile devices, as they become more powerful,
will eventually fall prey to all the same types of malware that attack
desktop systems and servers. This includes viruses, Trojan horses, worms
and denial of service attacks. Some recent examples of such malware are
described below:
Denial of Service attack:
In the summer of 2000, the SMS Flooder sent a massive amount of spam
mail in the form of SMS messages to cell phone targets in Europe. The
effect on affected cell phone users was that they were constantly being
paged. This large number of SMS messages caused a considerable amount of
inconvenience and frustration and effectively became a denial of
service attack.
Computer Worm:
Cabir, reported in June 2004, is a worm that uses Bluetooth
connectivity to infect smart phones running the Symbian OS and Nokia's
Seris 60 software. It has been described as a nonmalicious
"proof-of-concept virus". Cabir replicates itself across Bluetooth
connections and arrives in a smart phone's messaging inbox as a file
named caribe.sis. The phone user has to accept the message and then must
allow the file (from an unknown source) to install itself before the
infection is complete and Cabir can continue to spread itself. The Cabir
worm can reach only mobile phones that support Bluetooth, have
Bluetooth switched on, and are in discoverable mode.
