Dr. Dobb's | Ensuring Strong Security for Mobile Transactions

Ensuring Strong Security for Mobile Transactions

The use elliptic curve cryptography (ECC) can help create inherently secure mobile devices that have the capability and interoperability to participate in contactless transactions.

December 04, 2006
URL:http://drdobbs.com/security/ensuring-strong-security-for-mobile-tran/196601403

Not too far into the future, it will seem quaint and probably slightly bizarre that there was ever a time when phones could not take and send pictures, download text messages, browse the Internet, play music, and be toted around conveniently in a purse or pocket. Given the most recent trends in phone functionality, children born today may also find it strange that people ever carried bank cards, or credit cards, or wallets. This is because mobile handsets are being looked to increasingly act as transactional mechanisms: devices that can be used effortlessly as forms of personal identification or as tools for buying goods and services. Yet before we quite reach that point of complete convergence, there is the tricky business of security to contend with.

It's tricky for two reasons. One, because the requirement for security—and the stringency of that security—is going to intensify as devices are used to store and exchange ever-more sensitive information. And two, because the whole promise of wireless transactions is convenience. Even as expectations of functionality and security reach new heights, users will expect their devices to operate faster and more effortlessly than ever before.

These two seemingly contrary sets of demands pose a major challenge to device manufacturers whose products are already constrained in terms of bandwidth, power and processing capability. Yet with security-minded designs based on efficient, well-established methods and using compact algorithms like ECC (elliptic curve cryptography), the challenge can be met.

At the point of purchase
Pilot tests in Japan and Europe have shown that the transactional possibilities of mobile devices are virtually unrestricted. Contactless payment, public transportation ticketing and event ticketing have been singled out as key areas for what are sometimes referred to as "mobile proximity transactions". The recent LocPay project led jointly by Visa, Nokia and financial-services company Nordea provides a straightforward example. Over several months in 2003 and 2004, the companies and a number of Finnish retail partners experimented with a contactless point-of-sale payment system. Merchants ranging from restaurants and sporting-goods vendors to travel agencies, video stores and hair salons were outfitted with point-of-sale RFID readers. These were configured to interact with RFID transceiver-equipped Nokia phones given out to 150 Nordea Visa Electron cardholders. Rather than swipe their magnetic-stripe Visa cards, users passed their phones over the reader to trigger payment processing. The Mobile electronic Transactions Forum, aka MeT, has identified a number of requirements for the successful implementation of mobile-transaction systems, from usability and low power consumption to clear definition of the payment architecture. But topping the list, not surprisingly, are security and privacy.

The threats
In a recent paper titled Mobile Terminal Security, co-authors from Gemplus Innovation in France and Dublin City University in Ireland describe the vulnerabilities of mobile devices as follows:

[These devices] need essentially the same types of security measures as enterprise networks—access control, user authentication, data encryption, a firewall, intrusion prevention and protection from malicious code. [Yet] handheld devices and smart phones are often used precisely where they're most vulnerable—in public places, lobbies, taxis, airplanes—where risks include loss; probing or downloading of data by unauthorized persons; and frequently, theft and analysis of the device itself. Hence, in addition to logical security measures, mobile devices must [include] protective mechanisms against physical attacks.

Mobile devices are at risk both for the information they store and also for the information they transmit. PIN numbers, corporate passwords, bank account and credit card numbers are all at risk of theft if a device holding them is lost, stolen, hacked into or intercepted. The different connectivity approaches are attended by different degrees of risk. GSM, for example, provides one-way authentication—to the network but not from the network—which could allow someone to pose as the network and interact maliciously with the device. As well, GSM is not secured against active attacks.

Short-range standards such as Bluetooth make it possible for users to synchronize their wireless devices locally, but Bluetooth's PIN-based security mechanism has been shown to lack sufficient robustness for sensitive transactions of the sort being considered here. For its part, MeT recommends the use of near field communication (NFC) for mobile-device transactions. NFC is a standards-based, very short-range connectivity technology. Operating at around 13.56 MHz over just a few centimeters, it supports contactless identification and interconnection and conforms to ISO, ECMA, and ETSI standards.

Even so, given the need to protect both the data stored on the device and data in transmission, the most prudent approach is to embed security within the architecture of the device itself. As the authors of Mobile Terminal Security put it: "System architects should keep in mind that threats should be dealt with at the design level, the implementation level and the application use level." This has to be done in an interoperable way, transparent to the user and without having a negative effect on the performance of the device overall.

Back to basics
While it is a complicated challenge to balance stringent security needs with convenient, real-world usability, the good news is that the fundamentals of security—established practices used today in secure systems of all kinds still apply. In other words, there's no need to reinvent the wheel.

Transaction-based systems require three main features:

Strong authentication. The system must be absolutely certain of who is participating in a given transaction.

Non-repudiation. When a transaction is completed, there must be no way for either party to deny that it was executed willingly. This has historically been achieved through signed contracts or credit-card slips (where the signature on the slip prevents the purchaser from denying having made the purchase). In the digital world, the same method is employed via digital signatures.

Confidentiality. Personal data on a device should be protected from casual access and data moving between devices during a transaction must be encrypted to avoid leaking private or transactional information.

Example of a secured transaction using a mobile phone

Privacy protection is of paramount importance to many users of electronic transaction systems, in part because the possibilities for abuses of the system are fairly obvious. Examples include the unauthorized collection of personal data from a badly secured device; tracking a person's movements by charting the location of his or her phone; eavesdropping on transactions; and interfering to make a service unreliable.

Building in strong capability
The security characteristics of a transactional system must be considered from two angles. First, data must be secured on the device itself. If ID information and keying material is poorly protected, the system itself is insecure from the start. Second, data must be secured during the transaction and after it is completed. For device protection, especially in constrained devices such as cell phones and PDAs, the preferable security architecture has a cryptographic engine at its core, supported by a common set of application programming interfaces suited to a wide range of requirements. The versatility of such APIs allows developers to embed interoperable security protocols quickly and easily. Together, the engine and the APIs make up what's known as the cryptographic service provider, or CSP.

Building in a CSP based on software and a hardware Root of Trust provides the protection required for secure transactions.

Some developers are keen on the idea of using a completely software-based CSP, but in reality there is a significant performance advantage to including both hardware and software elements. The use of hardware strengthens security overall, via:

True hardware-based random-number generation. Nearly all modern cryptographic security is based on randomness. This depends on a supply of truly random bits that can be created only through specialized hardware. (Software is out of the question, as it can only condition a string of data through programmed methods, meaning the result is in some way predictable.)

Hardware acceleration of cryptographic algorithms—for symmetric (DES, 3-DES, AES), asymmetric (ECC, Diffie-Hellman, RSA), and supporting algorithms (SHA-1, SHA-2). Acceleration provides the capability to operate stronger security algorithms with less delay and less power consumption. This encourages system and protocol designers to make use of strong security. Here, overbuilding for the future is nearly always worth the effort and investment: as mobile transactions become more common, security will be increasingly critical. Devices that have a small bit of additional capability to provide efficient, secure operation will have a competitive advantage.

A secure bootloader for device-code integrity including code signing. This provides a 'trusted' core for the device from which other software operations can be validated.

A secure execution mode enabling secure key storage and runtime authentication. Because protecting the keys is the root of a secure system, providing secure key storage is critical to trusting devices. Further, while the use of keys allows an attacker the opportunity to collect information on them, if the keys are used only in a secured hardware block, this point of attack can be made inaccessible.
For mobile devices, both the hardware and software aspects of the CSP must have small footprints. The CSP can't monopolize the resources of the device and must leave room for other programming elements; after all, the device exists to provide services.

On the software side, code size can be minimized through design. A CSP should:

Allow developers to compile out unused algorithms that minimize the code base, which has the benefit of providing only the operations that are necessary.

Be flexible—configurable in ways that support faster processing, lower power consumption and more efficient bandwidth utilization.

Conform to reigning standards. This often doesn't yield a smaller footprint, but does enable the device to operate in the physical world.

Designing security that fits
The choice of cryptographic algorithms and protocol schemes—on which all security operations such as key exchange, digital signatures, and encryption are based—plays a big role in how security is implemented. Efficient design stems from the use of modern algorithms and schemes. Commercial and government specifications (and uptake of those specifications) have made the Advanced Encryption Standard (AES) the preferred algorithm for symmetric cryptography. Using AES as the symmetric cipher provides an efficient, small-footprint form of encryption, to provide confidentiality on a device and during a transaction.

Most of the security work in transactional systems, however, is done through asymmetric methods. As mentioned earlier, a connection between a device and reader or between two devices requires both authentication and a secure exchange of keys, creating a trusted path. Once this secure path is created, the transaction itself is validated and sealed for posterity through digital signatures created by the devices. Elliptic curve cryptography (ECC) provides modern asymmetric security, matching the strength of AES, and for many reasons is ideally suited to use in constrained devices.

ECC has been adopted within several industry standards including ANSI, IEEE, IETF and FIPS. (FIPS ensures that algorithm implementations and crypto modules can be trusted to provide a specific level of security. It has been mandatory in the U.S. government market since 2002; products must comply with FIPS to be approved, bought and implemented.) As well, the U.S. National Security Agency (NSA) has licensed ECC to meet its Suite B secure communication requirements. There are a number of reasons for ECC's growing popularity. It provides the most security per bit of any asymmetrical (aka public-key) algorithm. It can be computed faster than any other while using fewer resources. This is especially important for constrained devices and the applications running in them. Scalability and future-readiness are also factors. To deliver a cryptographic strength equivalent to 128-bit AES—protection that experts today estimate will suffice to at least 2031—ECC requires a key size of just 256 bits, while other public-key algorithms would require keys many times larger.

Comparison of ECC versus other encryption schemes.

Compact and versatile, ECC allows developers to create inherently secure devices that have the capability and interoperability to participate in contactless transactions. With fast key exchange protocols and size- and space-efficient digital signatures, ECC-based operations form the building blocks for secure transactions. Using these building blocks as part of a CSP on top of a secure hardware base results in a device that meets present and future security needs. Building the proper security into devices based on industry-leading techniques requires more than AES. Devices must be built from their core with security in mind, and must provide the capability to make secure protocols work efficiently. Security must become ingrained within the device. This inherent security will become increasingly critical as transactional uses of mobile devices become more common. Inadequately secured mobile devices are not only at risk themselves, but can also serve as instruments in deeper security breaches of the networks they are connecting to. They cannot afford to be the weak links in the chain.