Wireless Transport Layer Security
WAP security protocol
- 2 min read
- 3 chapters
Related on Lably
Through HTTP
Overview
WTLS is derived from TLS. WTLS uses similar semantics adapted for a low bandwidth mobile device. 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.
Sign in to keep reading
2 more chapters are free with a Lably account.
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. An incomplete list:
- Key Exchange and Signature
- Symmetric Encryption
- DES
- Triple DES
- RC5
- Message Digest
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).