However, wireless has some unique difficulties, such as limited bandwidth, high latency and unstable connections. Several options just around the corner address these issues. We will be focusing on two approaches: Wireless Transport Layer Security (WTLS) -- an SSL-like security protocol--and connection-oriented security communication using established protocols, such as IPsec and SSH.

Understanding WTLS

WTLS functions similar to SSL (Secure Sockets Layer), which is alternatively known as Transport Layer Security (TLS). WTLS provides for client or server authentication and allows for encryption based on negotiated parameters between the handheld device and the WAP gateway. WTLS's key exchange protocol is uniquely suited for wireless applications. Vendors can implement any of three classes of authentication types.

Class 1 (anonymous authentication) has limited use -- mainly for testing purposes -- because end users have no way of determining to whom they are talking. The client forms an encrypted connection with an unknown server. Class 2 (server authentication) probably will be the most common model used. As with SSL, once clients are assured they are talking securely to the correct server, they can authenticate using alternative means such as user name/password. Bear in mind that WTLS certificates are not the same as X.509 certificates, and they can't be used interchangeably. Class 3 (server- and client-authentication) is possibly the strongest class, as the server and the client authenticate each other's WTLS certificate.

Client certificates required for Class 3 authentication pose special management problems. Not only must the key pairs be generated on the mobile device (or generated in bulk and securely loaded onto the mobile devices), but the client certificate has to be safeguarded and managed until the certificate expires. Client certificates need not be retained on the handheld device. Rather, during negotiation, the client may refer the WTLS gateway to a directory to retrieve the client certificate from a directory. That saves the bandwidth needed to send the client certificate over the air and may improve negotiation performance; however, the WAP gateway needs to trust the directory the client refers to in order to have any assurance of authentication. The directory that holds user certificates also must be available at all times, or it won't be able to retrieve the certificate when requested. The key pair associated with the client certificate resides only on the client.

Bear in mind that the WTLS specification does specify cryptographic algorithms that may be supported by WAP devices, but doesn't require any for basic functionality. For example, the WTLS specification provides support for the RSA, Diffie-Hellman and Elliptic Curve Diffie-Hellman key exchanges, but in practice, most vendors are focusing support on RSA because of its widespread use. Similarly, bulk encryption ciphers such as RC5, DES, 3DES and IDEA are specified; however, DES and 3DES promise to be the most widely used because of existing implementations.

One of the concerns with cryptography regards export of certain key lengths to other countries. The WAP Forum is sensitive to this issue, and the WTLS draft supports various key lengths used with the bulk encryption algorithms, so that the security parameters can be negotiated according to geographic need rather than server support.

Unlike SSL, WTLS does not provide for end-to-end security. End-to-end security means the client and server have a secure session, and no other servers intervene. When your Web browser sets up an SSL session with Web server, the browser and Web server are talking directly; you know that when you send your credit-card number over SSL, in effect, only the receiving Web server will be able to receive it.

WTLS is not SSL, so it can't directly communicate with SSL-enabled Web servers. An IETF draft in the Transport Layer Security working group (draft ietf tls wireless 00.txt) aims at adding WTLS extensions to the TLS, and we most likely will see some of the WTLS specifications concerning negotiation and certificate format migrate toward TLS and X.509 just to simplify the protocol specs. The WAP gateway, which translates data packets from the WAP transport protocol (WDP or UDP) to TCP/HTTP, terminates WTLS sessions and initiates SSL sessions to the destination. It is here, at the WTLS gateway, that the potential problem exists. Between the time the data is decrypted and "decapsulated" from WTLS and WAP and re-encapsulated and re-encrypted in SSL, the protected data is exposed--albeit for only about a few hundred milliseconds. For most applications and users, this shouldn't be a big deal. If someone breaks into your WAP/WTLS gateway, you have bigger problems to deal with.

Two options are becoming available for end-to-end WTLS security. The first is WTLS tunneling, which tunnels WTLS traffic through a service provider's network to a remote WAP gateway. WTLS proxy, meanwhile, proxies WTLS connections through the carrier's WAP gateway. Neither solution is widely deployed and each will require partnerships with carriers and phone manufacturers to implement.