Vulnerable transactions

Feature November 2000

Vulnerable transactions
Wireless devices will be hard pressed to support secure ecommerce.
Nicholas Cravotta, Contributing Editor

If you've never purchased anything over the Web, face it: you are culturally challenged. Put this magazine down and go buy something right now. There's really no need to worry about a hacker intercepting your credit card number, because most of today's basic Internet transactions are fairly secure.

But that only applies to desktop computers. Over the years, we've developed reasonable security measures to protect PC-based transactions. However, as we hurtle toward pervasive Internet access on cell phones and other wireless devices, we're entering as-yet-unsecured territory.

Before we explore that territory further, a fundamental concept. I said above that today's basic transactions are "fairly secure," words carefully chosen in deference to a fundamental security precept: security is a business decision, balancing value and risk. For example, you wouldn't spend $100,000 on a car alarm. You might, however, spend $100,000 to protect valuable company secrets. So keep in mind that we're not talking about absolute security, only sufficient and reasonable security. As we'll see, even that might be hard to come by in the wireless space.

Limping through wonderland

If you're a power user, it's quite possible you can already do limited Internet shopping over your cell phone. You can also chose from more than 1 million pages to view on your tiny cell-phone or pager screen. For most of us, however, wireless surfing is still a Dick Tracy technology. Companies are still trying to figure out how to get rich content to wireless devices and enable secure wireless transactions.

One reason—the wireless world is dramatically different from the wired one. Your PC has an incredibly powerful processor, significant bandwidth to the network, and virtually limitless memory. A wireless phone, on the other hand, has the equivalent of an 8- or 16-bit processor, bandwidth on the order of 9600 bits/sec, and severely limited memory.

“There are great opportunities, now, for e-commerce. The WAP standards provide more than enough security, if used properly.”
Timothy Wright, Vodafone

These constraints affect security in several important ways. By definition, encryption is hard (if it were easy, then breaking keys would be easy). Certain standard encryption schemes are simply too difficult to implement on a constrained wireless device. Taking several seconds or even minutes to generate a key for a transaction just isn't feasible (read: acceptable to users). Limited bandwidth causes problems because 9600 bits/sec is hardly sufficient to handle all the packet overhead and complex handshaking required by the Internet's fundamental protocol, TCP/IP. Wireless connections are fragile and can terminate as fast as you can establish them. Finally, the very portability that makes wireless devices so attractive also makes them vulnerable (see sidebar, "Mobility's downside").

In short, wireless devices are like small children trying to play with the big kids; they just can't keep up. However, with small children you can sometimes change the rules of a game until they're old enough to play as adults. The same is true for wireless devices. Over the next few years, especially with the arrival of 3G wireless networks (see "3 wishes"), wireless devices will evolve into high-horsepower, high-bandwidth devices that will be able to play by the rules of the mature wired world. But no one wants to wait a few years for technology to catch up. We want wireless ecommerce now.

Less is less

Again, remember that security is a relative term, one that's entirely dependent upon the value of the information being protected. Although mobile devices today don't have the resources to implement full encryption without making the process either inconvenient or impossible for users, some transactions don't need so much protection. An online purchase for $20 certainly doesn't need as much protection as a stock transaction valued at $20,000. We don't want to see the $20 transaction compromised, of course, but we also don't want to wait 2 minutes for it to process. Users want a positive experience, which usually means a simple transaction, a decent interface, and instant response.

So you can scale back the amount of security processing to match the value of the transaction. For example, a security technology called PASS (polynomial authentication and signature scheme) uses a private polynomial and a public set of values generated from that polynomial to authenticate users. Full verification requires that every PASS value be generated by the polynomial. For constrained environments, however, the device could check only a subset of the values, thereby accelerating the process. This reduces overall security, but might be adequate for less-valuable transactions. For critical transactions, a higher level of security (and thus increased processing time) would be worth the wait.

It's also important to note that other aspects of the overall ecommerce system protect the user. For example, some credit card companies routinely track transactions. If your card is used to buy gasoline three times in 10 minutes, or gets used in several different states on the same day, the company can surmise that your card number has been stolen and suspend its use.

Key concept

In the wired world, PKI (public key infrastructure) forms the foundation for secure ecommerce. In brief, PKI uses a system of public keys, private keys, and digital certificates to assure the parties in a transaction that:

each party is who they claim to be (authentication),
the transaction hasn't been "overheard" or tampered with (integrity), and
neither party can later deny that the transaction took place (non-repudiation).

There are several levels of authentication. For data with little value, anonymous authentication provides sufficient protection. Low-value data can be defined as data in which you can assume no hacker has an interest. Examples include movie times or weather conditions—data that anyone can access freely. Most data passed over the Internet falls into this category.

The next level is one-way or server authentication, which verifies that the source of the data is reliable. A military ship, for example, needs to be sure that its orders are truly coming from headquarters. In an online purchase, you want to make sure that the server to which you're sending your credit card number is the one you think it is. The receiving server, however, doesn't need to verify your identity because you possess "secret" information—the credit card number. This class of authentication represents today's typical online transaction.

The highest class of authentication, and the one that requires the most processing and memory, is two-way or client/server authentication. When you purchase $20,000 worth of stock, the brokerage house would like to be able to confirm that it was indeed you who authorized the purchase. This concept is called non-repudiation. Without such authentication, the brokerage cannot prove that you made the purchase if you later try to deny it, perhaps in a lawsuit. Given the recent passage of the E-Sign bill—which makes digital signatures just as binding as paper signatures—non-repudiation is more or less a must-have for ecommerce.

Crossing the gap

But here's the rub for the wireless world: PKI is hard to engineer. While cell phones may have a great deal of ROM and flash memory, they typically only have about 16 kbytes of protected memory, housed in a SIM card. Security applications must run in this protected area to prevent hackers from accessing keys. How far does 16 kbytes go? Figure 3 kbytes for the phone's identity and personal management, reserve 3 kbytes for a cryptographic engine, and set aside 7 kbytes for a banking application. That leaves 3 kbytes for PKI. To put that in perspective, the PKI client from one vendor, Entrust, runs into the megabytes.

Thus, in order to fit within the constrained wireless environment, we need to scale back somewhere. Certainly we could scale back on PKI, but to implement anything less than two-way authentication means you lose non-repudiation.

WAP addresses wireless constraints by stripping security protocols down to the essentials.

Many people point to WAP (wireless application protocol) as a standard that could help. In simple terms, WAP is the wireless equivalent of TCP/IP. Where the wired world has HTML, Javascript, and SSL (secure sockets layer), WAP has WML (wireless markup language), WML script, and WTLS (wireless transport layer security).

WAP addresses wireless constraints by stripping security protocols down to the essentials. A WAP gateway serves as the intermediary between a wireless device and the Internet at large. The wireless device transacts with the WAP gateway using WAP, and the WAP gateway converts the transaction into standard TCP/IP for transport over the wired network. This scheme cuts back on bandwidth and processing requirements for the wireless device. Unfortunately, with savings always come tradeoffs.

The most serious fault of WAP has been dubbed "the gap in WAP." In order to act as proxy for the wireless device, the WAP gateway must decrypt WTLS-encrypted data from the wireless device and encrypt them using SSL. Thus, the WAP gateway can "see" and potentially compromise any secure data passing through it (see Figure 1).

The WAP gateway can reside anywhere in the network. However, given the expense of maintaining such a gateway, it is unlikely that a company like E-Trade, for example, would house the gateway within the protected confines of its own network. The most likely home is the wireless service provider. The question then becomes, how well do you trust your proxy agent?

Trust carries paramount importance, because security isn't simply about encryption algorithms. It's a systemwide issue. For example, you may have a secret key that you use to encrypt all of your E-Trade transactions. You store the key safely on your cell phone. But if you loan your phone to a friend, you're effectively trusting your friend with your secret key as well.

In general, the best secrets are those no one knows. If there's a way for you to see the secret keys stored on your phone, then hackers can see them too. However, if you can never view those keys, just use them, then potential hackers face a much more difficult task. The most secure systems rely on trust as little as possible.

The gap in WAP is a problem because the two most likely markets for secure wireless access are ecommerce applications, such as banking and brokering, and wireless VPN (virtual private network) links, which would let wireless devices access secure corporate networks. For both of these applications, the need to trust the WAP gateway is intolerable, considering the value of data that is likely to be passed.

One way to cross the gap is to encrypt data at the application level. For example, a banking application could encrypt sensitive data before handing it off to the WAP engine, which would then encrypt it again. However, this application-level encryption complicates the overall problem. In fact, the data may even have several more levels of encryption applied to it before it ever reaches its destination. Each level of encryption increases processing costs and reduces bandwidth efficiency through increased overhead (see sidebar, "Compulsory evolution").

Such challenges don't necessarily make WAP an unworkable solution. "There are great opportunities, now, for e-commerce," says Timothy Wright, principal engineer at Vodafone and chairman of the WAP Security Group. "If you use the WAP standards, they provide more than enough security, if used properly."

Wright maintains that the gateway-gap issue is significant but not at all insurmountable. "Today banks let you do phone banking, which is end-to-end plaintext," he notes. "They put in various checks and balances so that the system as a whole is not insecure." His advice concerning the use of operator/third-party gateways is to audit the gateways for yourself. "We believe WAP is perfectly secure enough for e-commerce," he says. "Most breaches don't occur because an algorithm is broken, but because someone implemented the security incorrectly. Security is a subtle business and requires expertise."

In reality, both security and the wireless market are moving targets. WAP won't necessarily disappear once the constraints that make it so necessary today fade away. WAP will evolve, converging towards standard Internet protocols. This evolution, however, must be kept under control and directed. It does little good to create a whole new infrastructure for the wireless market that only a few years from now will impede progress because it has become a cumbersome legacy.

Already the WAP standard has seen changes. The WAP Forum has begun discussions on new initiatives to address the changing wireless landscape. Scheduled for approval by next June, one initiative covers end-to-end transport-layer encryption to address the gap in WAP. It will describe the suite of technologies a handset should support and specifies using TLS (transport layer security), a technology similar to SSL. TLS is attractive because unlike SSL, its use doesn't incur a licensing fee from Netscape (which developed both technologies). The initiative aims to make it so that any wireless client can interact with any compliant TLS server. Some translation will be necessary to convert from TLS to SSL, but that translation won't require decryption of secure data.

Unfortunately, the initiative also assumes a 3G or GPRS (general packet radio services) platform. In other words, it wouldn't come into play until networks exist that would already overcome many of today's wireless constraints.

Is it worth committing to WAP for the next few years, or would it be better to wait for advancing technology to erase the bandwidth and processing limitations that make wireless security a challenge? Wireless ecommerce is ready to explode. Industry analyst Andrew Seybold says that more than 150 million mobile phones will be Internet-ready by 2003. Strategy Analytics puts the number at a still-impressive 134 million, and IGI Consulting forecasts 330 million units.

Many companies seem to think the investment is worth securing customers today.

Compulsory evolution

Let's start with a common misconception. You may have heard that a particular algorithm will take X million years to crack, and that this makes the algorithm secure. If you started cracking an encrypted message now, it might actually take you those millions of years. But technology moves quickly. For example, Moore's law alone—that processors will double in performance every 18 months—means you'll be able to crack the algorithm in half the time if you wait just 18 months. Additionally, other factors—such as advances in IC process technologies, multiprocessor and parallel processing models, and new specialized engines or architectures—also contribute to cracking efforts. Thus, the strength of an algorithm, usually measured by its key size, drops several bits each year.

This means that standards, especially those covering wireless encryption, will change. An encryption algorithm deployed today may become obsolete in a few months. For example, researchers may discover vulnerabilities in an algorithm after it has been widely deployed. More likely, however, a new service will hit the market that uses the latest and greatest algorithm. Even if a device relies on a standard and stable encryption algorithm, it may need occasional updating.

Reprogrammability, therefore, is an essential characteristic for wireless device survival. For example, RSA public key encryption plays a critical role in PKI key exchange. However, other kinds of encryption—one serious contender is known as ECC (elliptic curve cryptography)—could easily fit the bill. While the whole industry may not shift over to another technology like ECC, we'll most certainly see different companies employing different alternatives. For example, two different banks may employ application-level encryption using different algorithms. Without the ability to support different kinds of encryption through reprogrammability, suddenly one's choice of bank and brokerage becomes an important consideration when deciding which wireless device to purchase.

A reprogrammable or reconfigurable engine allows a device to download (securely, of course) a new algorithm when it becomes available. Some devices will no doubt employ a hybrid approach; standard and common algorithms could be implemented in an inexpensive chip built into the device, while a programmable engine would support future encryption standards.

Reprogrammability also plays an important part in maximizing resource reuse, which in turn keeps costs down. Having to support several layers and types of encryption in hardware would require larger chips, which translates into higher cost, more power consumption, and the need for more board space—all anathema to producing wireless devices that meet consumer price points. A programmable encryption engine allows a device to reuse the same engine for several algorithms rather than requiring a separate engine for each algorithm.

Mobility’s downside

Security weaknesses don't exist solely at the encryption or key-exchange level. Attacks can focus on the physical device itself. Instead of requiring millions of years to break a sophisticated key, such an attack can compromise security in as little as a few seconds.

Consider a couple of analogies. It's a well-known fact that bank vaults are allergic to dynamite. And with a towing chain and a four-wheel-drive SUV, you could drag an ATM to your garage and break it open in private. But such extreme attacks are rare. Being difficult to steal is an admirable security trait. Even PCs enjoy some protection by virtue of their location within a home or place of business.

Stealing a mobile device, however, is as simple as reaching into a purse or briefcase. Once a thief has the device, he or she can crack the device's keys at his or her leisure, choosing from among several methods of attack (see the sidebar, "Attack modes").

What's more, mere possession of a device sometimes offers easy access to the keys stored on that device. For example, my PC takes care of exchanging my password with my email server. Thus, anyone who has access to my computer has access to my otherwise secure email account. Mobile devices usually require a password to let you access the keys stored on the device. Therefore, the overall security of the device depends not on the strength of the encryption algorithms but on that humble password. Break the password (perhaps a whopping four digits) and you get access to all those million-years-to-break keys.

Attack modes

Physical attacks range from active attacks, such as electrically probing a system, to passive attacks, such as power and timing analysis.

Active attacks typically leave evidence of the attack, regardless of whether the attack is successful or not. For example, dynamiting a bank vault will definitely leave evidence of the attack. It will also attract notice during the attack. Passive attacks are much more difficult to protect against. The device under attack doesn't have to be modified in any way, and the device has no way of knowing that an attack is underway. Additionally, a thief can return a stolen and passively cracked device before it is missed, with the security compromise undetected.

Let's look at two examples of passive attacks: differential power analysis (DPA) and timing attacks. Silicon chips are made up of potentially millions of resisters that draw a characteristic current from the power supply. To some degree, there is a correlation between power usage and the data the chip is working with. You can actually sense individual gates opening and closing. Thus, in the case of executing an encryption function, monitoring power consumption can give a hacker insight into the supposedly secret keys stored on the chip. Timing attacks sense secret information leaks in a similar way. The amount of time it takes to execute an algorithm varies depending upon the secret key.

How realistic are these attacks? Both DPA and timing attacks are considered "sound," meaning that it is theoretically possible for an attacker to deduce all bits of a secret key. However, a sound attack may not be practical. Again, it all comes down to the value of the data being protected.

Serious work is underway to protect against these attacks. For example, advances are being made in techniques to decorrellate the power supply from the encryption chip, meaning that tapping into the power supply will no longer leak information. Especially important is the ability of the encryption subsystem to be able to destroy secret data when it detects an attack. For example, take "microsurgery," a physical attack on the chip itself. In such a catastrophic situation, the device must be able to guarantee reliable power to enable the chip to overwrite itself.

Another path open to attackers is to use a device in a manner never intended by the manufacturer. No one expects a cell phone to operate at very hot temperatures, so these devices are rarely tested outside normal limits. However, if you run a device at too high a temperature with too low a voltage, the device may act unpredictably, possibly exposing its secrets. To protect itself, the device must detect such conditions (environmental failure) and act appropriately (such as destroying sensitive data or shutting down completely).

Need you implement defenses against all these attacks? Microsurgery, for example, is costly and time-consuming. The only time it's worth using is when the data being protected has great value. It is rarely used to extract individual keys. An attacker needs a much bigger payoff, say thousands of keys, to make this attack worthwhile.

Finally, there's also the issue of how long an attacker needs access to the information in order to profit from it. As soon as you report your cell phone missing, all of its associated keys can be revoked. Again, security is a balance between value and risk.

Author information

Contributing Editor Nicholas Cravotta covers communications as a technical editor for EDN. When he isn’t teaching at UC Berkeley or writing humor, he can be seen laughing with his 16-month old son.