News | January 3, 2001

Sealing the Gap in WAP

Adding the Internet to wireless phones enables carriers to offer more features, but carriers also can count on a whole new crop of security problems.

By Betsy Harter

Table of contents
Cause for concern
The WAP gaps
Gateway problem
Filling the gap
Size issue
About the author

Security has been an issue in the wireless industry since cellular's inception. On the voice side, carriers have had to deal with tumbling, cloning, and subscription fraud. Unfortunately, adding data services and wireless Internet access brings a whole new set of security issues.

Cause for concern (Back to top)
It wasn't until the last year or so that people finally became comfortable giving out credit card and other personal information over the Internet. Consumers have every reason to be wary of the Web. Cybercriminals have electronically penetrated almost every one of the 500 largest U.S. corporations, not to mention government entities such as the Pentagon. Cybercrime is not limited to the United States—telecommunications experts estimate that computer crime is responsible for $15 billion in losses worldwide. Now that valuable personal information, including financial and medical data, is traveling over airwaves, consumers and wireless carriers are more concerned about security than ever before.

The WAP gaps (Back to top)
Verne Meredith, Diversinet vice president of sales & marketing, said WAP—the protocol which most wireless carriers use to offer wireless Internet services—has several security holes.

"We strongly believe that any secure digital wireless application needs to be the mirror image of the security model in the brick-and-mortar world," he said. "The WAP 1.2 security standard in its current state has significant shortfalls."

Meredith said there are five pillars to security in the brick-and-mortar world that the wireless world needs to emulate. For example, if a person goes to a bank to withdraw money, the bank first verifies the person's identity, known as authentication in the digital world. Next, the bank verifies what the customer is allowed to do, or authorization. Third, the bank creates a space between a customer doing a transaction and other customers, known by digital companies as encryption. Fourth, the teller counts out a customer's money in front of him to ensure he receives what he requested, called data integrity by digital companies. Last, the customer gets a receipt, known in digital transactions as proof of contract, or non-repudiation.

Although these five pillars exist in the wired Internet, WAP 1.2 is missing the authentication, authorization and proof-of-contract elements, Meredith said. In addition, WAP doesn't mention application level security, which means if a bank wants to secure its application for customers and manage the security behind its firewall, it can't do it using WAP because the intelligence is at the transport layer rather than the application layer, Meredith explained.

Gateway problem (Back to top)
Another gap in WAP is known as the gateway problem. Kevin Ellis, Openwave senior product manager for the company's Secure Enterprise Proxy, explained that data sent from a handset is encrypted and sent to the gateway at the wireless carrier's network via a secure protocol called Wireless Transport Layer Security (WTLS). From the gateway to the Web server, the data is sent either by a leased line, a virtual private network, or via the Secure Socket Layer (SSL) protocol, also known as Transport Layer Security (TLS). Right now, WTLS and SSL are not compatible, so the data being sent via WTLS is decrypted at the gateway, then re-encrypted before it is sent through SSL.

"That translation actually happens in the carrier's gateway, and while that is happening the data is in the clear," Ellis said. "If you are doing a financial transaction, you don't want your account numbers or passwords in the clear in the operator's infrastructure."

Dave Madden, Chrysalis-ITS director of business development, said in this situation, someone with a sniffer could steal data from a carrier's site after it had been decrypted.

Filling the gap (Back to top)
The industry is working to solve the gateway problem in several ways. Albert David, SSH director of technical services and operations, said the industry is working on establishing a TLS-WTLS session that will take data from the handset, to the gateway, to the Web server without decrypting the data.

WAP 1.3 also will solve several of the gaps, Meredith added. The standard creates a Wireless Public Key Infrastructure (WPKI), which is a client security agent that sits on the phone, as well as digital signatures. Ellis added that WAP 1.3 includes dynamic proxy navigation, which is a redirection method that allows an end-to-end connection between the handset and the corporation with no decryption in between.

Although WAP 1.3 will not be ratified until first or second quarter 2001, Openwave already has created what it believes will be a WAP 1.3-compliant product to help create end-to-end encryption. Openwave's Secure Enterprise Proxy will start shipping in 1Q01. The Secure Enterprise Proxy places a WAP proxy at the corporation to which a customer is connecting.

"So, if a bank had a Secure Enterprise Proxy, once it installed the proxy, the subscriber would be able to make a direct WTLS end-to-end connection from the phone all the way to the bank, and there would not be this translation in between," Ellis said. "When you couple that with client and server certificates, you can offer privacy and integrity through WTLS encryption, authenticity through server and client certificates, and non-repudiation by using the client certificate on site."

Guy Singh, Baltimore Technologies product marketing manager for Telepathy, said that in this model, both the carrier and the content provider have WAP gateways. The initial connection is made to the carrier's WAP gateway, and when a user needs to connect to a content provider's secure area, the WTLS connection is handed off via the Wireless Port Proxy (WPP) protocol to the content provider's WAP gateway.

"But this solution requires new versions of microbrowsers on handsets that can understand this new protocol, carriers to upgrade to a gateway that will support this, and content providers to host such a proxy," Singh said. "A level of interoperability is introduced, and new technology needs to be rolled out."

Amit Kapoor, Certicom director of product development, said the gateway problem can be solved in other ways. One is for the encryption protocol to end directly on the application server, so the gateway would no longer do the translation. The other is called a gateway security model. In this model, when a customer sends data from a wireless device, the ASP would be able to look at a portion of the transaction, and the bank would be able to see part of the transaction. The ASP would know how to bill the user, and the bank rests assured that the ASP did not see the user's banking information.

"Multiple parties will sit between the consumer and the content provider—it could be an operator or an ISP. Each will require the ability to look at a portion of the data," Kapoor said. He said the WAP Forum is evaluating both standards. "We think the first solution is a short-term solution, and the second is a better, more long-term solution."

Robert Grapes, Entrust market strategist, global wireless solutions, added that some companies have developed SIM application toolkits, which support current generation GSM phones. The toolkits permit custom proprietary solutions to host client certification information on the device or terminal so that users can do client-authenticated connections today while the industry is waiting for WAP 1.3 terminals to become available.

"The risk there is that as the subscriber base slips into WAP-capable phones, users will demand WAP services," he said. "The risk is that you invest money in short-lived solutions."

In another move to improve wireless data security, Openwave also recently agreed to embed "root keys," or electronic authentication functionality, from Baltimore Technologies, Certicom, and Diversinet in the Openwave UP.Browser WAP microbrowser. Because the Openwave UP.Browser microbrowser will contain embedded root keys from many security providers, handset manufacturers are provided with multi-vendor support. Likewise, carriers that license the Openwave UP.Link server and enterprises that license the Secure Enterprise Proxy can purchase WTLS server certificates from the e-security provider of their choice, offering users server authentication.

"Embedding root keys into mobile devices allows server certificates to work for the first time in a mobile environment, so the mobile user will be able to authenticate the server that they are connected to," Ellis said. "Before, the handset was connected to the operator's gateway, and the handset could not see past that. It could not be sure that the site it connected to was the site it meant to connect to, because there was no way to deliver a client certificate."

Size issue (Back to top)
SSH's David said another security issue with WAP is that companies can't use standard Web security certificates, known as X.509 certificates, in wireless applications because they are too big. Standard certificates run anywhere from 1K to 10K, which does not sound like much. However, wireless phones have slow processors, and when elements such as online security applications from banks or financial institutions, cryptographic pieces, and security engines are added, size becomes a big problem.

"If you look at the codes used to run something like Entrust PKI, you are talking megabytes of code," David said.

One way the industry has worked to solve the certificate size issue is to create a WTLS certificate, which basically is a scaled-down X.509 certificate with the optional fields removed. The WTLS certificate is about half the size of a standard X.509 certificate.

"It is still a big certificate, though. There is not an elegant solution at this point," David said. "The WAP Forum is looking at it."

Entrust's Grapes added that because client certificates are processed by servers, an efficient way to solve the size problem is to keep the certificate on the network so that size is no longer an issue.

"You put the certificate on the network somewhere, and it gets passed back to a terminal as a URL of where it is located," he said. "When you sign a transaction, the object passes along a URL that says where the certificate is stored, so the server gets the certificate and validates it, and is it is not chewing up memory space."

Certicom has been working to solve the issue through Elliptic Curve Cryptosystems (ECC). ECC permits reductions in key and certificate size that translate to smaller memory requirements, Kapoor explained. With ECC, the time needed to generate a key pair is so short that even a device with very limited computing power can generate the key pair. This means that the card personalization process can be streamlined for applications in which non-repudiation is important.

About the author (Back to top)
Betsy Harter is a freelance writer based in Athens, GA. She can be reached at betsyharter@aol.com.

Newsletter Signup
Newsletter Signup
Get the latest industry news, insights, and analysis delivered to your inbox.
Join your peers