Wireless Transport Layer Security

Wireless Transport Layer Security (WTLS) is a security protocol, part of the Wireless Application Protocol (WAP) stack.^[1] It sits between the WTP and WDP layers in the WAP communications stack.^[2]

Overview

WTLS is derived from TLS. WTLS uses similar semantics adapted for a low bandwidth mobile device.^[2] The main changes are:

Compressed data structures — Where possible packet sizes are reduced by using bit-fields, discarding redundancy and truncating some cryptographic elements.
New certificate format — WTLS defines a compressed certificate format. This broadly follows the X.509 v3 certificate structure, but uses smaller data structures.
Packet based design — TLS is designed for use over a data stream. WTLS adapts that design to be more appropriate on a packet based network. A significant amount of the design is based on a requirement that it be possible to use a packet network such as SMS as a data transport.

WTLS has been superseded in the WAP Wireless Application Protocol 2.0 standard by the End-to-end Transport Layer Security Specification.

Security

WTLS uses cryptographic algorithms and in common with TLS allows negotiation of cryptographic suites between client and server.

Algorithms

Due to the additional power and bandwidth requirements imposed by wireless devices, only a subset of algorithms supported by TLS are viable.^[3] An incomplete list:

Key Exchange and Signature
- RSA
- Elliptic Curve Cryptography (ECC)
Symmetric Encryption
- DES
- Triple DES
- RC5
Message Digest
- MD5
- SHA1

Security criticisms

Encryption/Decryption at the gateway — in the WAP architecture the content is typically stored on the server as uncompressed WML (an XML DTD). That content is retrieved by the gateway using HTTP and compressed into WBXML, in order to perform that compression the gateway must be able to handle the WML in cleartext, so even if there is encryption between the client and the gateway (using WTLS) and between the gateway and the originating server (using HTTPS) the gateway acts as a man-in-the-middle. This gateway architecture serves a number of purposes: transcoding between HTML and WML; content providers need not implement WBXML compression; removes reliance on DNS; enables a walled garden
Digest truncation — HMAC message digests are truncated to reduce transmission overhead, this reduces the theoretical effectiveness of the HMAC potentially reducing the data integrity protection.
Inadequate review — WTLS is significantly different from TLS, it is not clear that the changes made to WTLS have not in some way weakened the security. The use of a new certificate format is an example of this. The format defined in the WTLS specification may not be appropriate for all the uses to which a certificate may be used.
Client Implementation – As there are no official specifications which WTLS implementations must adhere to, many may use insecure cryptographic algorithms or key generation processes. In some client software, WTLS may even be disabled.

Interoperability

As mentioned above the client and server negotiate the cryptographic suite. This happens when the session is started, briefly the client sends a list of supported algorithms and the server chooses a suite, or refuses the connection. The standard does not mandate support of any algorithm. An endpoint (either client or server) that needs to be interoperable with any other endpoint may need to implement every algorithm (including some covered by intellectual property rights).

References

^ Bakalov, Rudy (September 2000). "Introduction to WAP's Wireless Transport Layer Security". Information Security Technical Report. 5 (3). Elsevier: 15–22. doi:10.1016/S1363-4127(00)03003-X.
^ ^a ^b Nichols, Randall K.; Lekkas, Panos C. (2002). "Wireless Transport Layer Security (WTLS)". Wireless Security: Models, Threats, and Solutions. McGraw Hill Professional. ISBN 978-0-07-138038-6.
^ Sklavos, N.; Kitsos, P.; Papadopoulos, K.; Koufopavlou, O. (April 2006). "Design, Architecture and Performance Evaluation of the Wireless Transport Layer Security". The Journal of Supercomputing. 36 (1). Springer: 33–50. doi:10.1007/s11227-006-3549-4.