If requested by an application, a security service, the wireless transport layer security (WTLS), can be integrated into the WAP architecture on top of WDP as specified in (WAP Forum, 2000c). WTLS can provide different levels of security (for privacy, data integrity, and authentication) and has been optimized for low bandwidth, high-delay bearer networks. WTLS takes into account the low processing power and very limited memory capacity of the mobile devices for cryptographic algorithms. WTLS supports datagram and connection-oriented transport layer protocols. New compared to, e.g. GSM, is the security relation between two peers and not only between the mobile device and the base station . WTLS took over many features and mechanisms from TLS (formerly SSL, secure sockets layer, but it has an optimized handshaking between the peers.

Before data can be exchanged via WTLS, a secure session has to be established. This session establishment consists of several steps: Figure illustrates the sequence of service primitives needed for a so-called ‗full handshake‘ (several optimizations are possible).

 The originator and the peer of the secure session can both interrupt session establishment any time, e.g., if the parameters proposed are not acceptable.

 The first step is to initiate the session with the SEC-Create primitive. Parameters are source address (SA), source port (SP) of the originator, destination address (DA), destination port (DP) of the peer. The originator proposes a key exchange suite (KES) (e.g., RSA, DH, ECC, a cipher suite (CS) (e.g., DES, IDEA, and a compression method (CM) (currently not further specified). The peer answers with parameters for the sequence number mode (SNM), the key refresh cycle (KR) (i.e., how often keys are refreshed within this secure session), the session identifier (SID) (which is unique with each peer), and the selected key exchange suite (KES‘), cipher suite (CS‘), compression method (CM‘). The peer also issues a SEC-Exchange primitive. This indicates that the peer wishes to perform public-key authentication with the client, i.e., the peer requests a client certificate (CC) from the originator.

The first step of the secure session creation, the negotiation of the security parameters and suites, is indicated on the originator‘s side, followed by the request for a certificate. The originator answers with its certificate and issues a SEC-Commit.req primitive. This primitive indicates that the handshake is completed for the originator‘s side and that the originator now wants to switch into the newly negotiated connection state. The certificate is delivered to the peer side and the SEC-Commit is indicated. The WTLS layer of the peer sends back a confirmation to the originator. This concludes the full handshake for secure session setup.

After setting up a secure connection between two peers, user data can be exchanged. This is done using the simple SEC-Unit data primitive as shown in Figure 10.13. SEC-Unit data has exactly the same function as T-D Unit data on the WDP layer, namely it transfers a datagram between a sender and a receiver. This data transfer is still unreliable, but is now secure. This shows that WTLS can be easily plugged into the protocol stack on top of WDP. The higher layers simply use SEC-Unit data instead of T-D Unit data. The parameters are the same here: source address (SA), source port (SP), destination address (DA), destination port (DP), and user data (UD).

This section will not discuss the security-related features of WTLS or the pros and cons of different encryption algorithms. The reader is referred to the specification and excellent cryptography literature. Although WTLS allows for different encryption mechanisms with different key lengths, it is quite clear that due to computing power on the handheld devices the encryption provided cannot be very strong. If applications require stronger security, it is up to an application or a user to apply stronger encryption on top of the whole protocol stack and use WTLS as a basic security level only. Many programs are available for this purpose. It is important to note that the security association in WTLS exists between the mobile WAP-enabled devices and a WAP server or WAP gateway only. If an application accesses another server via the gateway, additional mechanisms are needed for end-to-end security. If for example a user accesses his or her bank account using WAP, the WTLS security association typically ends at the

WAP gateway inside the network operator‘s domain. The bank and user will want to apply additional security mechanisms in this scenario.

 Future work in the WTLS layer comprises consistent support for application level security (e.g. digital signatures) and different implementation classes with different capabilities to select from.