The growth of mobile commerce follows the increasingly popular ownership and use of mobile personal, programmable communication devices, including mobile phones and PDAs. These devices are effective for authorizing and managing payment and banking transactions, offering security and convenience advantages compared to online payment via PCs. Some of these advantages are available in existing devices, others require modest, inexpensive enhancements likely to be available in new devices in the next few years. The use of secure and convenient mobile personal devices could revolutionize the payment, banking, and investment industries worldwide. Here, I discuss some of the challenges and opportunities involved in their use for making secure payments and authorizing banking transactions.
Security and convenience are the two main motivations for using these devices for transactions. The security is revolutionary. Existing means of electronic authorizations, including ATM transactions and card-not-present credit/debit card transactions, as well as online banking, are based on account-holder authentication by the payment system. But it can fail in multiple ways, including through the compromise of the bank’s computers and, in online banking, of the user’s computer, as well. Computers are generally vulnerable to compromise, especially the user’s computer, which typically has minimal security mechanisms and processes. However, existing systems do not always distinguish among fraud by the user, compromise of the user’s computer, and compromise of the bank’s computer. Assigning responsibility for damages resulting from fraud and disputes is therefore done through administrative and legal means rather than through technical means. In most countries, credit card purchasing, ATM withdrawals, and electronically generated money transfers must be cancelled if the user claims not to have authorized them (and the bank cannot prove the user is cheating). Online brokerage and banking operations are normally irreversible. Responsibility is not necessarily allocated fairly, and non-corrupted, genuinely innocent parties may find themselves responsible for damages due to another party’s fraudulent activity or security breach. Moreover, when using online banking and brokerage services, users are vulnerable to attacks on their (insecure) computers, as are the bank’s computers. Note that using a smart card connected to the PC does not ensure security, as a corrupted PC (possibly infected by a virus) may send incorrect information to the smart card; a secure transaction device needs its own I/O interface to the user [8]. The lack of a technical solution for preventing and resolving fraud creates substantial risk and expense for users, merchants, and operators (banks) alike.
Mobile personal devices, usually with a built-in display and keyboard, are well-positioned to provide a technical solution for reducing fraud and allowing the fair allocation of responsibility for damages from fraud. Some amount of security is already part of the authentication mechanism of existing cell phones as a way to prevent call theft. Moreover, it is relatively easy and inexpensive for device manufacturers to incorporate additional mechanisms to ensure secure transaction authorization. These mechanisms help prevent most fraud and allocate responsibility fairly for any remaining fraud. For users, their value far outweighs their relatively modest cost.
Convenience is another reason people use mobile personal devices for transactions. Convenience can result from using their communication capabilities when paying for goods and services, whether on foot or in cars, planes, or trains, and authorizing transactions at remote servers of banks, brokerages, and merchants.
A device’s user interface can also improve convenience; for example, the user can view balances and logs of transactions and retrieve receipts of payments. It also makes it easy for a single mobile device to support several applications, including banking, investment, and retail payments, using multiple charge, micropayment (cash), and loyalty accounts, all supported by a uniform user interface and consolidated management. To support the many possible scenarios and applications, these devices should incorporate modular authorization architectures.
Transactions Architecture
Figure 1 outlines a modular architecture for secure transactions using these devices. Components include at least the user, the device, and a mobile transaction provider, which may be a cellular operator, a bank, or a combination of operator and bank. In a payment transaction, a merchant (a provider of services and/or goods) is also included; however, because the merchant may work with a different transaction provider, the two providers have to be able to interoperate. The arrows represent long-term relationships; the broken arrow represents a transaction-specific relationship.
Secure transactions consist of three independent processes:
- Identification. The device identifies the user through physical possession (as with regular cell phones), passwords, or biometrics (such as voice recognition);
- Authentication. The mobile provider authenticates the transaction request from the device via either subscriber identification (as with existing phones) or cryptographic mechanisms (such as digital signatures or secure protocols, like the Wireless Transport Layer Security Specification) [10]; and
- Secure performance. The transaction is performed by the mobile transaction provider, possibly with the help of the merchant and/or other transaction provider(s) and may involve secure payment protocols (such as Internet Keyed Payments/Secure Electronic Transactions, or iKP/SET) [1, 5]; the mobile transaction provider is independent of the communication protocol in the mobile device. For additional modularity, it may use mobile gateway(s) to support multiple communication and authorization mechanisms.
This modular design provides inexpensive and flexible support for secure transactions.
Existing systems do not always distinguish among fraud by the user, compromise of the user’s computer, and compromise of the bank’s computer.
Transaction Request Mechanisms
Mobile personal devices should incorporate mechanisms to securely authenticate transaction requests that can be used by (preferably) multiple transactions and scenarios. To allocate responsibility, transaction requests should be digitally signed by the device using a private key (not known to the providers) kept in the device. The user does not have to obtain a public-key certificate from a trusted certificate authority; it suffices that the agreement between the user and the provider states the public key and the algorithm. To reduce hardware costs, designers may prefer public-key signature algorithms (such as the Digital Signature Algorithm, or DSA [7]), so most of the computations are done offline, and online signing is efficient.
The device displays the transaction details to the user and asks his or her consent for each transaction request. The device should ensure the user is aware of the entire request, possibly by limiting the request format; for example, payment transactions may display the amount and other details (such as merchant and product identification).
For flexibility, the device might allow the signing of markup documents using markup language (such as a subset of HTML [3]) with fixed, well-defined rendering. As a further precaution against misleading documents, the device should present to the user and sign upon approval only markup approved or provided by an authority or provider trusted by the user, that is, accompanied by an appropriate signature (and, optionally, by the signer’s certificate chain); this allows secure inclusion of identifications and certifications in textual or graphical (trademark) form.
Validating signatures can be computationally intensive (with DSA even more than with the RSA signature-only algorithm). However, most applications need few document templates; a single signed template can be used for many transactions with unsigned values for parameters (such as date, amount, and payee) that differ from transaction to transaction; by caching the (validated) templates, the device can save on both communication and computation overhead. Separating the parameters from the template also simplifies the automated processing of signed transaction requests once they reach the transaction provider. The device signs both the markup and the parameters; to prove the identity of the template approver, this signature may also be included in the data signed by the device (see Figure 2). (Extensions, including those for validating the fairness of lotteries and gambling services, are beyond the scope of this article.)
The security of this design depends on the secure operation of the mobile personal device, including its user identification. Some current mobile devices, including phones, use only simple, preprogrammed processors, and therefore can be trusted to operate securely. However, some devices support downloaded, general-purpose applications and may, like computers, be vulnerable, as with viruses.
Secure transaction authorization may, therefore, involve a secure co-processor, used only to authorize transactions (and possibly to view confidential data). There should be visible indication when the display and keyboard are controlled (only) by the secure co-processor, allowing the user to securely identify (such as by password) and authorize transactions. The co-processor is invoked by the main processor to authorize transactions, providing the raw request in shared memory; if authorized, the co-processor returns the signed transaction request in the shared memory.
Applications and Scenarios
The modular secure transaction architecture using mobile personal devices in Figure 1 can be used for multiple applications and scenarios. The simplest involves only the user, the device, and a single transactions provider (such as a bank, brokerage, or insurance company). The user identifies to the mobile device, possibly through secure identification mechanisms (such as a PIN, voice identification, or fingerprint); the device then authorizes a transaction to the provider (such as money transfers and investments). Authorization is preferably through some secure public-key signature process, allowing precise allocation of responsibility for fraud (disputed transactions). However, less secure forms of authorization (such as relying on subscriber identification and/or encrypted passwords) may suffice for some applications, as in e-banking and mobile commerce solutions.
More complex payment transactions typically involve at least one additional party: the merchant. In the simplest case, the merchant receives payment from some arbitrary, external payment/transaction provider (such as a bank or credit card company); the mobile transaction provider authorizes the transaction.
An important payment application is using charge cards to pay remote merchants for, say, goods bought online or on the telephone. Since the merchant and the consumer are in separate locations, the merchant cannot compare the customer’s signature to the signature on the charge card. A personal mobile device (such as a cell phone) is an alternative means of validating the customer’s consent to the transaction via authenticated communication with the mobile transaction provider. The communication may be initiated by the consumer using the mobile device or by the merchant communicating with mobile transaction providers; for example, in the PayBox system, a merchant (such as a Web site) contacts PayBox, which operates as a mobile transaction provider, and PayBox then contacts the cell phone of the consumer, relying on subscriber identification to trust the reply (approving or rejecting payment). Payment is not guaranteed, since the consumer may dispute the identification. By using secure signature from the consumer’s device, instead of subscriber identification, the payment provider or external arbiter can allocate responsibility for fraud, as well as resolve disputes and guarantee payment.
In some scenarios, mobile devices play an additional role beyond authorizing the transaction. Devices used for browsing the Web represent a natural means for paying for goods and services bought through merchants’ Web sites. Similarly, mobile devices can initiate location-dependent payments. Figure 3 outlines how a mobile device can be used to pay a parking meter. Imagine the user instructs the device to contact the parking merchant (flow 1). The device then sends its location via the provider to the merchant, initiating the parking transaction (flow 2). The merchant returns the offer; the provider often converts (transcodes) from, say, HTML to binary Wireless Markup Language (WML) the offer to fit the particular mobile device. The offer may contain details relevant to the purchase (such as the “per-fee link syntax” in HTML [6]). The provider also creates markup to display the offer to the user and secure the user’s authorization of the transaction request; for the sake of efficiency, this step may be combined with the conversion (transcoding) process.
Using a mobile device with a mechanism for secure transaction requests, the provider sends the offer (flow 3) in signed markup. The device (usually using its secure co-processor) displays the offer to the user, receives approval, and returns (flow 6) a signed transaction request, as in Figure 2.
Employing mobile devices (such as phones) without mechanisms for secure transaction requests, the authorization function has to rely on the security of the communication between the device and the provider. The provider incorporates the offer details (such as amount) into the display markup sent to the device and shown to the user; if the user’s response, sent to the provider, is positive (say the user clicks on the link identifying the product and price), the provider views it as transaction authorization. This process requires the provider to link between the offer sent to the mobile device (flow 3) and the payment transaction request received from the mobile device (flow 6). To avoid maintaining state in the provider, the payment request may contain the state information, possibly in a cookie or as parameters of the URL. To prevent forgery or replay, the state includes a Message Authentication Code (MAC) using a key known only to the provider and computed over the state and time.
Upon receiving an authenticated payment transaction request (flow 6), the provider confirms payment to the merchant (flow 7) by sending a signed or authenticated message. The merchant sends a receipt confirming payment was received; if the meter is connected to the merchant’s server, it may be sent directly to the meter (flow 8′). More often, the meter has minimal communication capabilities (such as infra-red), and the receipt is sent via the provider and device (flows 8, 9, 11); the user may even have to manually type the receipt into the meter using a keypad. The receipt may have multiple formats as well; the parking meter itself may use a concise receipt format for efficient communication and processing. Moreover, to allow a low-cost parking meter with limited computational resources to validate the receipt, the receipt sent to the meter (flow 11 or 8′) uses an efficient MAC with a shared key between the meter and the merchant’s server.
Electronic Receipts and Tickets
Additional applications involving this modular transaction architecture, as in Figure 1, can also provide and use secure electronic receipts, or e-receipts, or a proof of payment the consumer presents to a third party or device. Applications include:
- Presenting the e-receipt to a validating/dispensing device to prove payment and receive service or merchandise; the validation device (such as the parking meter in Figure 3) need not communicate directly with the payment transaction provider or merchant’s server, so long as it is able to validate the e-receipt;
- Presenting the e-receipt to a third party (such as the Internal Revenue Service for tax purposes or an employer for expense reimbursement);
- Providing “proof of purchase” for warranty service, returns, exchanges, and rebates; and
- Using the e-receipt as an e-ticket, the mobile device holds the receipt (the ticket), presenting it upon inspection at, say, an airport for claiming tickets.
In each of these applications, except the first, the e-receipt should be a digital signature from the payment transaction provider or the merchant, thus allowing validation at arbitrary times by any party.
Payments via Mobile Transaction Provider
The mobile transaction provider may also be involved in the actual payment to the merchant. (Charging by mobile operators for communication and value-added services is a special case.) In today’s mobile phones, authorization is via subscriber identification mechanisms, which do not provide non-repudiation. However, in the future, mobile consumers might also use a secure mobile signing device, as in Figure 2, to avoid disputes. This device may allow high-value transactions, as well as paying mobile operators who are not completely trusted (such as when roaming). Mobile communication mechanisms (such as the Global System for Mobile communication, or GSM) allow the foreign (visited) network to authenticate the user with information from the home network. Charging requires prior agreements between the visited and the home networks. Designers of the Universal Mobile Telecommunications System (UMTS) recognized the difficulty of establishing agreements in advance among visited networks and all home networks [4]; thus, UMTS includes mechanisms for dynamic negotiation and setup of roaming agreements between a visited network and a home network [4]. Roaming agreements seek to establish fees and ensure operator trustworthiness. Operators are trusted to deliver payments in time; foreign (remote) operators are also trusted to not overcharge visiting customers.
A secure signing mobile device can prevent fraud (overcharging) by foreign network providers, thereby allowing more automated and variable roaming agreements. Operators can also use the Final Payments protocol discussed in [2] to extend pairwise trust relationships into global trust relationships, allowing automated, secure, low-cost universal roaming.
Other payment scenarios involve mobile transaction providers participating in the payment transaction itself, not just in its authorization. One motivation is to establish new payment networks, possibly involving mobile operators and financial institutions as providers of mobile payment services. Motivations for establishing new payment networks include the exploitation of business opportunities inherent in the billing, customer-service, and technical relationships among mobile users (and devices) and mobile operators. Another is support for low-value payments (micropayments) and final (irreversible) payments, each possibly yielding additional mobile communication services. Micropayments and final payments using mobile devices may enable the purchase of content and services delivered via the network, as well as person-to-person payments and money transfers; the latter represents a substantial opportunity, especially in light of the millions of overseas employees worldwide. Moreover, due to their ability to allocate responsibility for fraud, these new payment networks may lower the cost of transactions (as a percentage of the transaction) for large-value payments and money transfers.
A major challenge for any new payment system is how to achieve a critical mass of merchants, buyers, and transactions needed to justify investment by each of them and ensure a proper level of acceptability; for example, a customer of any mobile provider should be able to buy from any merchant that maintains accounts with most payment transaction providers. One solution for payment transaction providers is to use the Final Payments protocol, allowing interoperability among any provider connected by the transitive closure of all pairwise, provider-to-provider trust and interoperability agreements. For instance, interoperability among mobile payment providers is a feature cited by Fundamo, Inc. (www.fundamo.com) in its payment systems product.
In other cases, the mobile transaction provider is part of an existing payment network, as in a credit card network. The involvement of the mobile provider in a credit card transaction could be as simple as transmission via the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocol of credit card details or as complex as a purchase via the iKP/SET protocols [1, 5]. In either case, the mobile provider acts on behalf of the user as a wallet server, as it is located along the route between mobile device and merchant. The mobile transaction provider may implement a variety of payment protocols, ranging from the complex (such as iKP/SET) to the simple (such as SSL/TLS transmission of credit card numbers). The mobile provider may securely inform the credit-card-issuing bank of any pending transaction, allowing the issuer to reject fraudulent transactions; a one-time or limited (to payments via mobile provider) card number may be used for added security.
Conclusion
Mobile personal devices are beginning to be used to perform secure banking, payment, and other transactions. Cell phones, PDAs, and other mobile personal devices are a convenient means for authorizing transactions. In the future, they are likely to incorporate low-cost enhancements providing secure, signed transaction requests, providing third-party verifiable proof of the consumer’s agreement to each transaction. This support will be flexible enough to support multiple applications, scenarios, and providers. New payment networks are likely to take advantage of the new capabilities, offering such services as micropayments and final payments previously impossible or impractical. Mobile personal devices will play an increasingly important role in payments, banking, investing, and other transaction-based and security-sensitive applications.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment