Crucial to addressing those concerns will be the Wireless Access Protocol (WAP), a key piece of the effort to get traditional Internet access and services down to wireless handsets. WAP, which can be used with existing wireless networks such as GSM and CDMA, allows traditional Web and Internet content to be made accessible to very small wireless handsets.
The WAP Forum, the principal standards body behind WAP, has included a number of security infrastructure provisions in versions 1.1 and 1.2 of the specification. These range from support of digital certificates for WAP gateways to encryption for data traffic.
Remaining issues include the role of a public key infrastructure (PKI). PKIs involve the creation and management of digital certificates, which are crucial to proving identity in the largely anonymous world of the Internet. WAP includes definitions for how digital certificates will work, thereby creating a more secure means of conducting mobile transactions.
WIRELESS SSL The main security component of the WAP specification is the wireless transport layer security (WTLS) protocol, which essentially defines security procedures for wireless Internet transactions. WTLS is based on Transport Layer Security, formerly known as Secure Sockets Layer, or SSL. WTLS provides a multitude of security features, including data integrity, privacy and authentication.
The basic WAP security model, as outlined in Figure 1, involves three major components. The Web server, which can be located at the site of either a content provider or wireless operator, delivers Web pages and enables online transactions. Typically, subscribers would have access to multiple Web servers, depending on the number and type of services.
In secure sessions, the Web server would serve up content encrypted with SSL in the same manner as encrypted content moves from Web servers to traditional wired browsers. The SSL-encrypted traffic goes out over the Internet and hits a WAP gateway, which is generally hosted by the wireless operators. The WAP gateway is becoming known more as a WAP server, because next-generation products can function as both application server and gateway.
The gateway can be viewed as the heart of a WAP solution in general and of WAP-enabled security. Because the WAP handset is limited in terms of memory and battery life, a number of tasks that would exist at the browser level have been moved to the gateway.
The WAP gateway bridges the wired and wireless Internet. In the security model, SSL-encrypted transmissions entering the gateway are transmitted over the wireless network using the WTLS protocol. The gateway essentially translates from SSL to WTLS, a necessary step because SSL was designed for browsers on computers with much more processing power than WAP phones and handsets. WTLS, on the other hand, can handle secure transmissions without the processing overhead usually associated with SSL.
After content has been secured using WTLS, the WAP gateway sends it out over the wireless network to the WAP handset.
Because WAP is independent of the wireless network, developers can create an application just once, which can then be supported across a variety of wireless networks such as GSM, GPRS, CDMA and TDMA. DIGITAL CERTIFICATES
The connection based on SSL between the content server and WAP gateway, and (WTLS) between the gateway and WAP handset, provides a secure pipe for sensitive data.
However, another important aspect of security goes beyond making data unreadable to potential eavesdroppers. The digital certificate helps both content servers and WAP handsets identify themselves and vouch that they belong to the device they claim to. In other words, a digital certificate makes it easier to tell who you’re actually doing business with across a wireless network.
Digital certificates are nothing new in the wired world. Web servers have been using them for several years. A valid certificate lets a user’s browser know it is accessing the server of a particular company. All the verification between browser and server occurs behind the scenes and is largely transparent to the end user.
This concept has been carried over to the world of the wireless Web through WTLS, which also includes specifications for digital certificates, but with a few changes.
Traditional digital certificates used in the wired world are based on the X.509 specification, which defines components such as public key information, identification information of the holder of the certificate, the name of the issuing certificate authority (CA), and a validity period for the certificate. The CA is a trusted third party that signs certificates it issues to individuals or corporations, ensuring that those certificates and the identity of the certificate holders have been vouched for.
However, X.509 has been more of a burden in the WAP world, according to Mahi DeSilva, vice president of engineering at Verisign, a leading CA. “WTLS defines a condensed form of certificate that doesn’t carry some of the baggage that X.509 has had,” he says.
“Not only is bandwidth very scarce, but the spectrum is very small for data, so we want to minimize as much of that bandwidth consumption as possible.” He also says that with X.509, the certificates are encoded and typically require complicated code on the client to deal with it. By not requiring the X.509 format for wireless, device manufacturers can simplify the code on WAP handsets.
WTLS certificates come in two types: for server and for client. The server certificates are becoming more popular for providers of WAP content. Companies such as Baltimore Technologies, Entrust Technologies and Verisign are already making WAP server certificates available to customers. Verisign supports WAP servers from Nokia, Motorola, Ericsson and Phone.com, while Entrust is supporting Nokia today. Baltimore’s customers include Apion, which was acquired by Phone.com in October 1999.
WAP Server Certificates
Server-side certificates, which were defined in WAP 1.1, provide authentication of a WTLS server to a WTLS handset and are used to create an encrypted session between client and server. In this sense, WTLS is very similar to SSL, in which client and server go through a handshake authentication behind the scenes that involves creating a session key to encrypt the transmission and an exchange of certificates.
In addition to the WTLS certificates, also known as mini certificates, WAP 1.1 also supports the use of traditional X.509 certificates.
The next version of WAP, 1.2, includes a definition of client-side certificates that can be used to authenticate a WTLS client to a WTLS server. As with server certificates, the client ones can be either in a mini certificate or X.509 format.
“In the wired world, support for client certificates in browsers has been there for a couple of years, but the problem is the user interface is really horrible,” DeSilva says. “From a user perspective, it hasn’t been treated as a first-class feature in a browser.”
DeSilva adds that terms like private key and other security lingo can make naïve users very nervous, so they are more likely not to bother with these security measures. Verisign is working with device manufacturers to make it simple for WAP handsets to get a digital certificate with just a few clicks. DeSilva says that although WAP 1.2 defines how client certificates would be used in secure transactions, version 1.3 of the spec will have a more concrete version of how client certificates work.
Even when WAP servers and clients are using digital certificate technology, another concern involves interoperability among certificates issued by different CAs. On the wired side, both server and client certificates can be issued by trusted third parties, or internally by a corporate-run CA. The challenge is to make sure that wireless digital certificates, regardless of issuing authority, will work in any type of implementation. For example, a WAP handset holding a certificate from one CA should be able to authenticate to a server with a certificate from another CA.
So far, industry watchers don’t see a major issue with digital certificate interoperability. “The gateway standard is open and allows you to extend support for CAs,” says Roger Snyder, senior product marketing manager at Phone.com, which manufactures WAP gateway software and other products for wireless networks. “In our server, we have an extensible model so operators can add in as many CAs as they want.” Snyder adds that Phone.com’s UP.Link WAP server comes preloaded with support for digital certificates from RSA Security and Verisign, but it can also support corporate as well as other third-party CAs.
Snyder adds that several CAs have joined the WAP Forum, and they and server manufacturers are working to extend existing certificate mechanisms to the wireless world.
AUTHENTICATION AND BILLING
A major concern with anything going out over a wireless network, especially with secure content, is making sure subscribers are able to validate themselves to the network.
For traditional wireless voice, users have different ways to authenticate themselves to the network, depending on what their provider requires. For most, it’s enough to type in a code to the handset keypad, which then unlocks the phone. Once the phone is unlocked, any type of phone call can be made. In some cases, a PIN is required.
Authentication schemes for wireless data likely will incorporate existing models, but they will also move beyond it. “The nice thing about wireless networks is they already have a mechanism to authenticate handsets to the network worked out,” Snyder says. “All the things an operator uses to protect against fraud on voice networks apply equally to the data side.”
Snyder says that in most cases, subscribers will have to go through voice authentication before they can access any data. He also adds that on CDMA, TDMA and GSM networks sophisticated algorithms authenticate the handset to the network, which ensures that before a data call begins the network knows who the phone belongs to.
Verisign’s DeSilva adds that the wired world is very anonymous, and users at any Internet kiosk in an airport or café can log into accounts without the content provider having a high assurance that users are really who they say they are. “In the wireless world, it’s different,” he says. “Each handset is fairly strongly authenticated to the network, and there are new possibilities of how you can authenticate customers.” he says. These methods may include provisioning a digital certificate at the time a WAP-enabled phone is purchased. “They [wireless subscribers] don’t even have to know there’s a certificate there, just that they have to do something to get on the network,” DeSilva adds. He also says that using digital signatures—a means of providing nonrepudiation—will give subscribers a much more authenticated way to get to content and conduct transactions.
The spread of WAP-based content could change a number of factors on the authentication, authorization and accounting (AAA) front, says Jeff Gordon, vice president of Atlys/IP development at Convergys Information Management Group. “When customers come in through a WAP connection, they hit a carrier server that connects them to a premium content server,” he says. “That server will want to ensure the customer is a valid user, and the way they’ll do that is through their AAA infrastructure. They’ll see explicitly who has the right to use what.” Gordon adds that today authentication methods are very diverse, but eventually there will be a more standardized mechanism.
From a billing perspective, WAP and its security model will make it easier for customer self-care, an application that will require users to prove they have the right to access their billing information. “From a billing system point of view, once you have SSL and WTLS providing a secure connection, you still have a lot to do because you have to recognize that people are still accessing very sensitive information,” says Gordon. He says that Convergys is working on a self-care application that allows customers to view billing information and make payments through their Web server. The server uses a combination of secure HTTP and WML, the format for displaying content on WAP-enabled devices.
Customer information is kept behind a firewall for additional protection. Another measure to ensure that only authorized users reach certain WAP content is to perform authentication at the application layer, according to Gordon. “We can rely on the network infrastructure, but neither we nor our customers would be completely comfortable with that,” he says.
Authentication for data will likely involve more complicated models, because with voice if authorization has expired it’s fairly simple to cut off the call, says Nasir Sheikh, executive vice president of business development at Usha Communications Technology. “If a data service like weather information is being sponsored by someone, you wouldn’t need to authenticate to receive that; but if you have a stock quote service where the first 20 quotes are free and then are charged on a sliding scale after that, the application needs to be monitored,” he says. Sheikh imagines a separate authentication scheme for each application, which would also have its own pricing or packaging model.
However, separate authentication processes for each application would defeat the purpose of trying to give users a seamless experience. Sheikh believes the WAP portal, which wireless carriers will likely operate initially, will be the natural place to keep track of authentication. However, he adds, the business models for how to accomplish this have yet to be addressed.
WIRELESS OPERATORS AND CONTENT PROVIDERS
With traditional wireless voice, an operator does not have to turn to a third party to provide services to the customer. However, wireless data will require the forging of partnerships between wireless carriers and content providers, because neither entity will be willing, or most likely able, to go it alone.
“Operators and content providers are trying to find the model that will work best for them; it’s kind of like the Web was five years ago, when people were trying to figure out how advertising would work,” Snyder says.
“Carriers may develop a portal and arrange with content providers so they can provide easy access to the content their subscribers will need,” according to Gordon. But because subscribers will probably first hit an operator’s WAP server and then a third-party content provider’s origin server, the billing model could get complicated. Also, if some of this traffic is secure and encrypted, rating and billing of packets could prove difficult. (For more on billing for encrypted data, see sidebar “Billing for Secure Traffic.”)
“WAP will have more stringent requirements on rating and billing than any other application,” says Usha’s Sheikh. He adds that mediation platforms will likely connect to several devices, including origin servers, WAP gateways and GPRS charging gateways. “You’re receiving CDRs in real time and aggregating them. Then the billing system is packaging and discounting in real time. And when transactions are complete, the end user will receive notification that they have incurred some charges,” he says. “You can see the strain it’s putting on the rating engine.”
Sheikh says some simplification will be necessary, and this may include making some services free and bundling others. Also, rather than mediation platforms connecting to many different devices, there may be some gateway aggregation of usage records.
In addition, wireless operators and content providers will have to work closely to make WAP content available and devise a settlement system so everyone gets their piece of the action.
Sheikh adds that the time frame for settlements in the past has been monthly, but that will likely change in a world of real-time rating and billing. He also believes clearinghouses may be established to deal with WAP traffic, or existing IP clearinghouses may also handle it.
Standards such as IPDR will more than likely play an important role in collecting WAP usage information, packaging information for rating and billing, and settling accounts.
PKI AND FUTURE GOALS
The security model for WAP, as defined in the current specification, provides for a number of mechanisms such as digital certificates and encryption of links between handsets and servers. But there are still more significant developments on the horizon.
Today, the use of a PKI to support WAP content is just beginning to emerge. A PKI is an architecture that supports the use of public keys and digital certificates. It also includes certificate and key management, as well as the all-important ability to revoke keys and certificates after they have expired or when a party is no longer trusted.
Today, the WAP spec really only addresses encryption and certificates, but not the larger infrastructure surrounding that. “There’s no need for a PKI today, but we are evolving from the existing model that is robust enough for CA management into a full PKI solution,” says Snyder. He doesn’t think the burden of creating a PKI will fall to wireless operators, but rather to the security companies in the WAP Forum—which includes Baltimore Technologies, Entrust Technologies, RSA Security, Verisign and Xcert International. “I think gateway manufacturers like us will be involved in partnerships with the CA vendors,” Snyder says.
“The computing industry has embraced PKI as the default means of having trusted transactions, particularly between unknown parties,” Verisign’s DeSilva says. “The large telcos get it and see the need for this stuff, but we think there will be more and more trust assertion, from handset to gateway or gateway to upstream infrastructure, that will be PKI-based.”
Probably the most significant use of a PKI for mobile commerce is the Jalda secure Internet payment method that was created by EHPT. Jalda can be used with PCs, mobile phones, or any other type of client with Internet access. This payment method makes use of digital certificates and a PIN or password, so the credential can be used to prove identity anywhere.
Another forthcoming development in the WAP standard is the idea of end-to-end security, meaning a secure, trusted link from subscriber all the way to content server. Today, the secure links are from the subscriber to the WAP gateway or server, and from the gateway to the origin or content server. “The model today requires trust with the operator’s gateway, and there are content providers that have that degree of trust with an operator and have deployed home banking and other applications,” Snyder says. “But some will want to be sure there is encryption from server to handset, and for that the WAP Forum is working on a standard.”
The initial work within the WAP Forum has concerned the network infrastructure surrounding this wireless data format. The next key areas under discussion will involve even tighter security and authentication measures. Through it all, billing and mediation vendors will have to strike up relationships not just with the wireless carriers they already count among their customers, but also with content providers to ensure that WAP usage information can be collected and billed for even within a tight security model.
BILLING FOR SECURE TRAFFIC
The security provisions of the WAP standard will enable users to safely transmit sensitive data and to conduct mobile commerce transactions over wireless networks. But if WAP content is traversing a network in such a secure state, how can that traffic be identified, rated and billed for by mediation and billing systems?
A likely method for capturing usage-based information on secure traffic would involve keeping track of the URLs a wireless handset is accessing. “From a traditional network perspective, you can rate the session because you know the subscriber contacted a certain IP address,” according to Convergys’ Jeff Gordon. This IP address or URL request should be enough to tell the wireless operator what sort of transaction is taking place.
“Using the URL, the operator can tell a customer went to a finance-related Web site, but they won’t know what exactly they are doing there,” says Phone.com’s Roger Snyder. “They get a degree of information to track usage and activity, but not enough to get financial details.”
In order to obtain enough information to be able to rate and bill a transaction, tight integration will likely be needed with mediation platforms, says Usha’s Nasir Sheikh. “The mediation system can tap in directly to the content provider and look for header information that will identify the nature of the content,” he says.
The relationship between a mediation device and the content provider’s Web server can also extend to the provider’s authorization, authentication and accounting (AAA) server, Gordon says. “In addition to mediation talking to a wireless billing infrastructure, they can monitor IP traffic directly from the content provider, such as getting billable application-level parameters from a banking server,” he says.
Secure traffic should remain just that—but that won’t preclude providers from seeing into the type of traffic being sent and received and then appropriately billing for it.
