Home: www.packetnexus.com
Tutorial: Wireless Security January 22, 2001 By Mike Fratto While WAP (Wireless Application Protocol) applications are all the rage in Europe and NTT's DoCoMo is storming through Japan, the United States is just beginning to see WAP devices emerge. As transaction-based Internet access applications, such as checking stock quotes and banking and buying via cell phones or handheld devices, takes off, the need for secure wireless connectivity is gaining ground. Wireless security is not much different from wired security. You want several things from security, wired or not: authenticate whom you are talking to, secure the data as it travels from the handheld device to the destination host, and ensure that the traffic hasn't been altered en route. Not unlike what Amazon.com, E-Trade or a VPN gateway does in the wired world. 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