Security in the WTLS

30.11.1999

Sami Jormalainen
Jouni Laine
Computer Science and Engineering
Helsinki University of Technology
Sami.Jormalainen@lpg.fi
Jouni.Laine@hut.fi

Abstract

Contents

1. Introduction

2. Data Communication Security

3. Wireless Transport Layer Security

4. Evaluation of the WTLS

5. Conclusions

References

Further Information

1. Introduction

The rapidly growing wireless market increases demand on the value added mobile services. The Wireless Application Protocol is developed to fulfill these needs. The WAP defines a set of protocols in transport, security, transaction, session, and application layers to enable a creation of advanced mobile services. Being developed by international organisation called WAP Forum, it also makes possible the mobile subscriber to take an advantage of the WAP services all around the world regardless of the local mobile network technology. The WAP is independent of the bearer services.

The Wireless Transport Layer Security protocol is the security layer of the WAP. Its primary goal is to provide privacy, data integrity, and authentication for WAP applications. The security is needed in order to safely connect to the services, such as online banking and e-commerce. The client and the server must be authenticated and the connection has to be encrypted. Man-in-the-middle attacks should also be prevented so that the data can not be modified during the transfer. The subscriber wants to be sure that the service being used is really the one it claims to be. In some cases, the service also wants to use a strong authentication with certificates. Altough the traffic in the air is encrypted in several mobile networks, the complete end-to-end security is not provided by the mobile network. That is the reason why the WTLS is needed.

The WTLS provides the transport service interface for the upper level layer. This interface is similar to the transport service interface below the WTLS. The WTLS is based on the well known TLS v1.0 security layer used in Internet. The number of modifications and changes were needed because of the nature of wireless networks. The wireless networks require support for both datagram and connection oriented transport layer protocols. The mobile equipment sets requirements for the algorithms because of the limited processing power and memory. In addition, the low bandwidth must be dealt with and the restrictions on exporting and using cryptography must be considered.

The WTLS incorporates new features such as datagram support, optimised packet size and handshake, and dynamic key refreshing. It has been optimised for low-bandwidth bearer networks with relatively long latency. Fast algorithms are chosen into the algorithm suite. The mobile equipment like cellular phone can be constructed to support only a set of cipher suites.

The objective of this paper is to analyze the security of the WTLS version 1.1. The following questions is placed: "Is the provided security level sufficient?". Altough the wireless network sets a great deal of requirements, it is possible to provide the acceptable security level. For instance, a security protocol that allows an intruder to eavesdrop the data is not acceptable. On the other hand, the absolute security combined with a good usability is in theory impossible. The number of security problems have already been discovered in the WTLS as a consequence of the modifications. Fortunately, the development work of the WTLS is continued to block up these security holes, thus, giving us better security in the future. The comprehensive security also depends on other factors than the WTLS.

Data communication security is comprised of a smaller security entities. In the following sections, the different entities are introduced and explained as a criteria for the analysis of the WTLS. The following descriptions are based on the definitions introduced by Amoroso and Schneider. [1,6]

The Wireless Application Protocol specification defines privacy so that the used transfer method ensures a private end-to-end transfer. It is not understood by any intermediate party that may have intercepted the data stream. [1,9]

Maintaining privacy is mainly fighting against the disclosure threat. The main tool for providing privacy is cryptography. A plaintext is simply encrypted and decrypted to implement privacy. If the plaintext is encrypted using a strong encryption, it is almost impossible for eavesdropper to decrypt and read the original content. The requirements of the strong encryption are met when the security is created by using a shared secret, not secret algorithm. The keyspace, from which the used shared secret is chosen, has to be large. Moreover, the used cryptographic method must produce an output which appears random to all statistical tests. Finally, the used method should be resistant to all known attacks. [1,4]

However, encrypted data is useless unless the recipient is not able to decrypt data. The sender and the recipient have to share a method to encrypt and decrypt the data. They both have to know the used cryptographic method and the shared secret. The shared secret is a piece of information known by both parties but nobody else.

There is also other kind of privacy. It is not always the case that the information has a recipient. Sometimes there is data that is not supposed to be decrypted by anybody e.g. Unix-type passwords. This kind of encryption method is called a one way encryption, in other words, there is no formula for a reverse process back to the original information. Hash-values are the most common method for the one way encryption. [1]

According to Schneider, authentication is defined as follows. "It should be possible for the receiver of a message to ascertain its origin; an intruder should not be able to masquerade as someone else." [6]

Authentication is a technique to ensure that the stated identity of the user is correct. In the beginning, the other party introduces itself and claims to have some identity. This is not enough. The contacted party also needs to know for sure that the contacting party is the one it claims to be. The contacting party has to present some verification to prove its identity. It can be as simple as passwords, or more complicated digital signature or certificate. But then again, the contacting party also wants to be sure that the other end is valid. The contacted party has to present some identification about itself.

After the authentication, the service provider can be sure that the service is available to the user who has correct rights to use the service. On the other hand, the user can be confident about the service provider.

Schneider defines integrity, " It should be possible for the receiver of a message to verify that it has not been modified in transit; an intruder should not be able to substitute a false message for legitimate one." [6]

Maintaining integrity means securing the reliability of the information. We have to figure out a way to prevent unauthorized changes or at least find the means to notice those modifications. Integrity is guaranteed by calculating checksums from the original information to be sent. Of course, just a plain checksum is not enough. We need some sender-related information mixed into calculations e.g. information is signed with the user's digital signature.

In most cases, maintaining integrity is more critical than guaranteeing privacy. It is more important that the information is received unaltered but seen by someone else than somebody has been able to modify it without making out the whole information. For example, bank transactions apply this category. It is embarrassing if someone finds out how much money you have but it is infuriating if somebody steals your money.

The WTLS is designed to provide security in the Wireless Application Environment. The wireless mobile networks pose new challenges for implementing security architecture compared with the traditional connection oriented models like that used in Internet.

The purpose of this paper is to contemplate whether the WTLS meets the security requirements represented in the previous sections.

Security in the WAP architecture should enable services to be extended over potentially mobile networks while also preserving the integrity of the user data. The denial of service should also be prevented. The wireless mobile networks set many requirements to the security layer. The existing secure protocols cannot be used in mobile networks without adaptation. [12]

One of the most important requirement is to support for low data transfer rates. For instance, the SMS as a bearer can be as slow as 100 bit/s. The amount of overhead must be kept as small as possible because of the low bandwidth. Compared with the industry-standard Transport Layer Security (TLS), formerly known as Secure Socket Layer (SSL), datagram transport layer must also be supported because of the nature of the wireless mobile network. The protocol should handle lost, duplicated, and out-of-order datagrams without breaking the connection state. [12]

Other issues include slow interactions, limited processing power, and memory capacity. They also include the restrictions on exporting and using cryptography. The round-trip times can be long and the connection should not be closed because of that. For instance, the time between the request and response using the SMS bearer can be as long as 10 seconds. Used cryptographical algoritms must be light enough so that the mobile terminals are able to execute them. The number of cryptographical algorithms have to be minimized and small-sized algorithms must be used. The amount of available RAM in the mobile terminals must be taken into account. Export laws in some countries do not let strong cryptography to be exported outside the country. For that reason, the best permitted security level, as defined by the legislation of each area should be achieved all the time. There are also differences between exporting a strong authentication and encryption. In many cases, strong authentication is allowed to be used but strong encryption is prohibited. [12]

In short, the objective of the WTLS is to be a lightweight and efficient protocol with respect to bandwith, memory and processing power.

The WAP is developed by WAP Forum industry association to provide specifications for the applications that operate over wireless communication networks. The WAP defines a set of protocols in the transport, session, and the application layers. It also specifies an application framework. Furthermore, it has been developed to meet challenges in building advanced differentiated services and implementations in a fast and flexible way. [8,9]

Internet prompted the need to bring all the content and advanced services to the mobile phones and other wireless terminals. For the same reason, it was seen in advance that a global specification was the best and fastest way to make the applications to work across differing wireless networks. The protocol should be independent of bearer networks and device types. The existing Internet standards should be embraced and extended whenever it was possible. The WTLS is a fine example, because it is adopted from the existing Internet protocol

Internet technology could not be adopted because of the fundamental limitations of mobile terminals. They have less powerful CPUs and memory, restricted power consumption, smaller displays, and different input devices. As mentioned above, the mobile networks set limitations that must be taken into account. These include less bandwidth, more latency, less connection stability and less predictable availability. As a result, the WAP architecture has to meet those requirements by optimising protocols for narrow-band bearers with potentially high latency and efficient use of devices' resources. [7,8]

The programming model used in Internet has been adopted to the WAP as much as possible. The new component introduced in the WAP programming model is the WAP gateway also known as the WAP proxy. It connects the wireless domain and the WWW. The main function is to act as a protocol gateway and encode and decode content. The protocol gateway translates requests from the WAP protocol stack to the Internet protocol stack. The encoders translate WAP content into compact encoded formats to reduce the size of the transfered data over the network. This model allows the content and the application to be hosted on standard Internet HTTP servers and to be developed using existing Internet technologies like CGI, application servers, and servlets. [7,8]

Figure 3.1. The programming model

The WAP is a layered protocol stack that contains a session protocol, a transaction protocol, a security protocol, and a datagram protocol. This stack isolates the application from the bearer when used as a transport service.

Figure 3.2. WAP protocol stack [9]

The Wireless Session Protocol (WSP) provides ways to establish a session from client to server, agree on used protocol functionality, exchange content, and suspend and resume sessions. It provides, both connection-mode session and non-confirmed, connectionless services. The core of the WSP is the HTTP v1.1 protocol and all the methods defined by the HTTP v1.1 are supported. When providing connection-mode, the WSP utilizes the Wireless Transaction Protocol layer. In the case of connectionless mode, the WSP takes advantage of the the Wireless Datagram Protocol layer. [11]

The Wireless Transaction Protocol (WTP) provides a light-weight transaction-oriented protocol that reliably delivers requests from the client to the server and responses from the server back to the client. The WTP runs on top of a datagram service and it is designed for interactive browsing. [13]

The actual transport layer protocol in the WAP architecture is the Wireless Datagram Protocol called WDP. It is supported by various network types. The upper layers are able to operate independently of the underlying wireless network because of the WDP. They utilize the interface offered by the WDP to communicate transparently over one of the available bearer services. [10]

The WTLS layer operates above the transport protocol layer and it provides the upper level layer of the WAP with a secure transport service interface. The interface preserves the transport interface below it, and it also presents methods to manage secure connections.

The WAP, by means of the WTLS, provides end-to-end security between the WAP protocol endpoints. Actually the end points are the mobile terminal and the WAP gateway. When the WAP gateway makes the request to the origin server, it will use the SSL below HTTP to secure the request. This means that the data is decrypted and again encrypted at the WAP gateway.

The complete secure connection between the client and the service can be achieved in two different ways. The safest way for the service provider is to place a WAP gateway in their own network. Then the whole connection between the client and the service can be trusted because the decryption will take a place not until the transmission has reached the service provider's own network, not in the mobile operator's network. When placing the WAP gateway outside the mobile operator's network, the remote access server is needed. The origin server could be created to include the functionality of the WAP gateway. This gives the highest security solution available.

The service and content providers can also trust the mobile operators gateway and use virtual private networks to connect their servers to the WAP gateway. But then they do not have possibility to manage and control the parameters used by the WTLS at the WAP gateway.

The negotiating parties are able to decide the security features they want to utilize during the connection. According to the security requirements, the applications enable and disable the WTLS features. For instance, privacy may be left out if the network already provides this service at the lower layer. The connection between two terminals can also be secured by the WTLS.

The WTLS Record Protocol is a layered protocol which accepts raw data from the upper layers to be transmitted and applies the selected compression and encryption algorithms to the data. Moreover, the Record Protocol takes care of the data integrity and authentication. Received data is decrypted, verified and decompressed and then handed to the higher layers.

The Record Protocol is divided into four protocol clients. Their protocol stack is shown in Figure 3.3. The different clients are described in the following sections.

Figure 3.3. WTLS internal architecture [12]

3.3.1. The Change Cipher Spec Protocol

The Change Cipher Spec is sent to peer either by the client or the server. When the Change Cipher Spec message arrives, the sender of the message sets the current write state to the pending state and the receiver also sets the current read state to the pending state. The Change Cipher Spec message is sent during the handshake phase after the security parameters have been agreed on. [12]

3.3.2. The Alert Protocol

The Record Protocol also provides a content type of alert messages. There are three types of alert messages: warning, critical, and fatal. Alert messages are sent using the current secure state, i.e. compressed and encrypted, or under null cipher spec, i.e. without compression or encryption.

If the alert message, labeled as fatal, is sent, then both parties terminate the secure connection. Other connections using the secure session may continue but the session identifier must be invalidated so that the failed connection is not used to establish new secure connections.

A critical alert message results in termination of the current secure connection. Other connetions using the secure session may continue and the secure identifier may also be used for establishing new secure connections.

The connection is closed using the alert messages. Either party may initiate the exchange of the closing messages. If a closing message is received, then any data after this message is ignored. It is also required that the notified party verifies termination of the session by responding to the closing message.

Error handling in the WTLS is based on the alert messages. When a error is detected the detecting party sends an alert message containing the occurred error. Further procedures depend on the level of the error that occurred. [12]

3.3.3. The Handshake Protocol

All the security related parameters are agreed on during the handshake. These parameters include attributes such as used protocol versions, used cryptographic algorithms, information on the use of authentication and public key techniques to generate a shared secret. The flow chart of the handshake is depicted in Figure 3.4.

Figure 3.4. Full Handshake Flow Chart [12]

The handshake starts with a Hello message. The client sends a Client Hello message to the server. The server must respond to the message with a Server Hello message. In the two hello messages, communicating parties agree on the session capabilites. For example, the client announces the supported encryption algorithms and the trusted certificates known by the client. The server responses by determining the session properties to be used during the session. If the client does not suggest some property server must decide one.

After the client has sent the Client Hello message it starts receiving messages until the Server Hello Done message is received. The server sends a Server Certificate message if authentication is required on behalf of the server. Moreover, the server may require the client to authenticate itself. The Server Key Exchange is used to provide the client with the public key which can be used to conduct or exchange the pre-master secret value.

After receiving the Server Hello Done the client continues its part of the handshake. At request, the client sends a Client Certificate message where it authenticates itself. Then the client sends a Client Key Exchange message containing either a pre-master secret encrypted with the server's public key or the information that both parties can complete the key exchange. Finally , the client sends a Finished message which contains verification of all the previous data including the calculated security related information.

The server must respond with the Finished message where it also verifies the exchanged and the calculated information. In addition, either party must send a Change Cipher Spec message. By means of this message parties decide that they start to use the negotiated session parameters.

If the client and the server decide to resume a previously negotiated session the handshake may be started by sending a Client Hello message where the Session Identifier is initilalized with the identifier of the previous session. If both parties share a common session identifier they may continue the secure session. The parties may start to use the connection after they have confirmed the session and informed the other party with the Change Cipher Spec message.

Figure 3.5. Resumed Connection Handshake Flow Chart [12]

The WTLS also defines an abbreviated handshake where only the Hello and the Finished messages are sent. In this case, both parties must have the shared secret which is used as a pre-master secret.

Another variation is the optimized full handshake where the server can retrieve the client's certificate using the trusted third party, based on the information provided by the client in the Client Hello message. The information provided by the certificates both parties are able to complete the shared secret values using the Diffie-Hellman key exchange method. The server has to send the Server Hello, Certificate, and Finished messages to the client in order to complete the handshake on the server's behalf. The client responds with the Client Finished message. [12]

Figure 3.6. Optimized Full Handshake Flow Chart [12]

3.4. Authentication

Authentication in the WTLS is carried out with certificates. Authentication can occur between the client and the server or the client only authenticates the server. The latter procedure can happen only if the server allows it to occur. The server can require the client to authenticate itself to the server. However, the WTLS specification defines that authentication is an optional procedure.

Currently, X.509v3 [X509], X9.68 and WTLS certificates are supported. When the WTLS specification 1.1 was released the X9.68 certificate was not defined yet. The WTLS certificate is optimized for size.

Authentication procedure immediately follows after the client and server hello messages. When the authentication is used, the server sends a Server Certificate message to the client. The certified information given by the server is listed in Table 3.1.

Actually, the receiving end gets a list of certificates. The list is a chain of certificates where the first one is the server's own certificate. Each of the following certificate certifies the one preceding it. According to the WTLS specification, to optimize the traffic and the client processing it is possible for the server to send only one certificate; the server certificate certified with the CA's public key which is distributed independently.

The server may also send a Certificate Request message to the client in order to authenticate it. The message will immediately follow the Server Certificate message and the Server Key Exchange message (if sent). Needless to say, the Certificate Request message is optionally sent only if the Server Certificate message is sent. In the message the server lists all the accepted certificate authorities. If no authorities are listed, client may send any certificate.

At request, the client sends a Client Certificate message back to the server. The client end certificates follow the same structure as the server certificates. If the client does not have a suitable certificate the client must send an empty certificate message. Moreover, the client may send a fatal handshake failure alert message and close the secure connection. The Client Certificate message tends to contain multiple certificates. This is acceptable because the certificate list is processed by the server which is likely to possess more processing power than the client.

An explicit verification is carried out by the client, if the Client Certificate message is sent. The client concatenates all the messages received from the server or created by itself and calculates a hash value to be signed. This message is sent to the server which can ensure that authentication is gone well so far. [12]

3.5. Key Exchange

In order to ensure a secure communication channel encryption keys or initial values to calculate keys have to be exchanged in a secure manner. The certified exchange of public keys was described in the previous section. However, it is possible that the Server Certificate Message did not contain enough data to allow client to exchange the pre-master secret (pre-master secret is an initial value which is used to calculate the master secret). In this case a Server Key Exchange message is used to provide such data.

The key exchange mechanism of the WTLS also provides an anonymous way to exchange keys. In this procedure, the server sends a Server Key Exchange message which contains the public key of the server. The key exchange algorithm may be RSA [RSA], Diffie-Hellman [DH1], or the elliptic curve Diffie-Hellman [ECDH]. The message does not contain any certified information.

With both the RSA and the anynomous RSA the client encrypts the pre-master secret with the server's public key and sends it back to the server in the Client Key Exchange message. With the Diffie-Hellman based algorithms the client and the server calculate the pre-master secret based on one's private key and the counterpart's public key. This message is omitted if some Diffie-Hellman -based algorithm was used and the client certificate was requested so that the client was able to respond it.

If the client has listed the cryptographic key exchange methods, which it supports, the server may choose whether it is going to use one based on the client's suggestions or define another method. If the client has not proposed any method the server has to indicate them. [12]

3.6. Privacy

Privacy in the WTLS is implemented by means of encrypting the communication channel. The used encryption methods and all the necessary values for calculating the shared secret are exchanged during the handshake.

In the first messages, the Client Hello and the Server Hello messages, random values are exchanged. In latter phases the client and the server exchange the pre-master secret. This value is transferred over a secure connection as described in the previous section. These values are used to calculate the master secret. The master secret is a 20-byte sequence which is calculated with the following formula:

master_secret = PRF(pre_master_secret, "master secret", 
                    ClientHello.random + ServerHello.random)[0..19]; 

The used encryption algorithm is chosen in the Server Hello message. In this message the server informs the client that it has chosen a single cipher suite. The client provides the server with a list of cipher suites. The cipher suites comprise of a bulk encryption algorithm and a MAC algorithm. The first item in the list is the client's preference. If the server does not find an acceptable cipher suite the handshake fails and connection is closed.

Currently the most common bulk encryption algorithms are supported such as RC5 [RC5] with 40,56 and 128 bit keys, DES [DES] with 40 and 56 bit keys, 3DES [3DES], and IDEA [IDEA] with 40,56 and 128 bit keys. All the algorithms are block cipher algorithms, no streams ciphers except NULLs are supported.

Encryption keys are conducted based on a key block. The key block is calculated from the initial values transferred during the handshake.

	key_block = PRF(master_secret + expansion_label + 
			seq_num + server_random + client_random);

The key block is dependent on a sequence number which makes the key block variable. The key block is recalculated in certain intervals based on the key refresh frequency. The key refresh frequence is negotiated in the Client hello and the Server hello messages. The expansion label is just a string expression for calculation. The client uses string "client expansion" and the server "server expansion". The encryption key, the initial vector and the MAC secret are conducted from the key block based on the key lengths required by the chosen algorithms. [12]

Data integrity is ensured using the message authentication codes (MAC). The used MAC algorithm is decided at the same time as the encryption algorithm. The client sends a list of supported MAC algorithms where the preferred algorithm is the first in the list. The server returns the selected algorithm in the Server Hello message.

The WTLS supports common MAC algorithms, such as SHA [SHA] and MD5 [MD5]. There are several different versions of both algorithms e.g. SHA exists with 0, 40 and 80 bit MAC sizes. The keyed MACs are calculated using the SHA-1. The modified algorithms are based on the SHA-1 but only part of the output is used. Same kinds of versions exist of the MD5 algorithm.

A special MAC algorithm is the SHA_XOR_40 which is a 5-byte checksum. First the input data is divided into the 5-byte blocks. Then all blocks are XOR'ed one after another. It is required that the XOR MAC must be encrypted and is only used for CBC mode block ciphers. The algorithm is intended for devices with limited CPU resources.

The MAC is generated over the compressed WTLS data. The following values are used to calculate the MAC

	HMAC_Hash = (MAC_Secret, seg_num + WTLS_Compressed_data.record_type + 
		WTLS_Compressed_data.data_length + WTLS_Compressed_data.fragment);

3.8. Secure State

The previous sections explain how the secure session is negotiated. After the negotiations, both communicative parties have a uniform secure state which contains the security parameters described in Table 3.2.

Table 3.2. The security parameters of the secure connection [12]
Item	Description
Connection End	Indicates whether the entity is considered a client or a server
Bulk Encryption Algorithm	An algorithm used for bulk encryption.
MAC Algorithm	The algorithm to be used for guaranteeing the message integrity/authentication.
Compression Algorithm	The algorithm used to compress data before encryption. All the information required to do compression.
Master Secret	A 20 byte secret between the two peers in the secure connection
Client Random	A 16 byte value provided by the client
Server Random	A 16 byte value provided by the server
Key Refresh	The time interval how ofter some connection state parameters are updated (encryption key, MAC secret and IV).
Sequence Number Mode	Which scheme is used to produce sequence numbers in the secure connection. Current options are implicit, explicit sequence numbering or Off.

The current state is made by means of the security parameters. The current state is continuously updated. Each connection state includes the elements such as the current encryption keys, MAC keys, IVs, and sequence numbers. Both the server and the client have separate secret keys for encryption, MACs, etc. [12]

Knowing the security concepts and the ways how the WTLS implements them, the evalution can be done. Multiple security holes have already been found by independent researchers, but the decisision whether they are serious enough to affect the whole protocol design is under investigation. Hence, it is a question whether the development of the WTLS's next version can be carried out without complete architectural changes.

The SSL is developed by Netscape. It has been universally accepted in Internet for authenticated and encrypted communication between clients and servers. The new Internet Engineering Task Force (IETF) standard called Transport Layer Security (TLS) is based on the SSL. This was recently published as an IETF Internet-Draft, The TLS Protocol Version 1.0 [3]

The SSL protocol provides privacy, authentication, and integrity. Data is encrypted with symmetric cryptography and authentication is done using asymmetric or public key cryptography. The integrity of messages is checked using a keyed MAC. Secure hash functions like SHA or MD5 are used for MAC computations. The goals of the SSL are cryptographic security, interoperability, extensibility, and relative efficiency. [3]

The SSL is a layered protocol. At each layer, messages may include fields for length, description, and content. The SSL takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, and reassembled and then delivered to higher level clients. [3]

The TLS version 1.0 and SSL 3.0 are very similar. They differ from each other almost nothing. [2]

The protocol has been developed to support very wide range of mobile devices. The most weakest devices cannot support heavy encryption because of the limitations of CPU, memory and bandwidth resources. There is no real security when allowing the client to choose null or weak encryption methods. The security cannot be provided for the devices that cannot execute heavy algorithms.

Allowing anonymous connection to be established, can be very risky. Anonymous authentication prones the connection to man-in-the-middle attacks. To prevent this problem the client should define that during the handshake it will not support key exchange suites without authentication. It should always authenticate the server it is going to use. The client will remain anonymous if it does not send its own certificate to the server. The server can ask the client to send its certificate, but the client can send just an empty response. Then it is up to server if it accepts the client without autentication. The Server Key Exchange Method message will only be sent when using anonymous method like ECDH_anon, RSA_anon and DH_anon.

The support for the large amount of algoritms makes system vulnerable because some of the algorithms have been proven weak. Thus allowing the connections to be encrypted using weak algorithms raises security issues. To solve this problem the clients and the servers should accept to use only strong algorithms.

The restrictions legislated by goverments do not allow the algorithms with too long keys to be exported. For instance, the goverment of United States only allow 40-bit keys to be exported. This sets the limitations to the security requirements. As long as these kinds of laws are valid, there is no way to provide decent security. However, it is a good feature that the WTLS takes into consideration the local legislation and restrictions so that only one version of the protocol is needed. The Wassenaar agreement applies that the 56-bit keys are allowed to be used in the financing applications. [14]

The number of potential security problems have been identified in the WTLS. The WTLS specification has been adopted from the TLS specification with some modifications and changes. These modifications and changes have at least partly led to some security problems including the chosen plaintext data recovery attack, the datagram truncation attack, the message forgery attack and the key-search shortcut for some exportable keys. [5]

Initial vectors called IVs are used by the CBC mode block ciphers to create entropy. Entropy is needed to protect symmetric key that is used in the CBC mode block cipher. Without IV, a original plain text would be encrypted with master key. This would open a possibility to use brute force to find the shared secret. The usage of IV prevents this to happen because the first block in the packet is first XOR'ed with IV. Knowing the content of the original packet does not help in any way, because it is XOR'ed.

Because the WTLS supports an unreliable datagram support where datagrams may be lost, duplicated, or reordered, the CBC mode needs a new IV for encrypting each packets. The used IV is computed XOR'ing the sequence number of the packet and the original IV, which is derived during the key generation. This is also called a linear IV computation. The first plaintext block in the packet is then XOR'ed with the computed IV. The original IV is computed based on values sent during the handshake. All these values containing client_random, server_random and sequence number are sent without encryption, so they can be eavesdropped. These predictable IVs lead to chosen-plaintext attacks against low-entropy secrets. This security problem affects privacy. [5]

The WTLS supports a 40-bit XOR MAC, which works by padding the message with zeros, diving it into 5-byte blocks and XOR'ing these blocks together. The XOR MAC does not provide any message integrity protection if stream ciphers are being used, regardless of the key lenght. A bit can be inverted in the ciphertext if the inverting is also done to the MAC. Thus the integrity check will be successful even when the content has been modified. This security problem affects integrity. [5]

The DES key contains a parity bit in each byte. When using a 40-bit key, the effective key length of the DES encryption is actually only 35 bits (5*7=35). Nevertheless, a 56-bit DES-key has the correct amount of keying material, 56 bits (8*7=56). The best possible security level in export-weakened encryption modes has not been reached. Although the expanded key material in the 40-bit DES is eight bytes, actual key material is only five bytes. This security problem affects privacy. [5,12]

The PKCS #1 version 1.5 contains security problem when used with the protocol including an oracle that tells whether a given packets has a correct PKCS #1 version 1.5 padding. If the system in some way tells to the intruder whether the used key is correct, it said that the system has an oracle. Using this oracle the intruder can try to find the correct key trying all possibilities and checking the response of the system.

The RSA signatures and encryption are performed according to the PKCS #1 version 1.5 in the WTLS, thus enabling the RSA messages decrypting with approximately 2*e20 chosen ciphertext queries. In the WTLS bad_certificate and decode_error messages may provide an oracle to be used for illegal decrypting. This security problem affects authentication. [5]

The unauthenticated alert messages, used in the WTLS, let the active attacker to replace an encrypted datagram with an unauthenticated plaintext alert message with the same sequence number without being detected. This security problem affects integrity. [5]

The record_type field is sent unencrypted. The eavesdropper can determine the change of keys reading the contents of this field. The existence of encrypted error messages can be determined from this field. This security problem affects privacy. [5]

The brute force attacks against the block ciphers can be mounted, because the correct keys can always be recognized with a trial decryption of the last block in each packet. The last block is padded to the next full 8-byte limit by filling it with the padding length. [5]

The WTLS specification includes pre-defined values for variables used in Diffie-Hellman computations, but the group order of the multiplicative subgroup is left out. The absence of the group order makes it impossible to check that the given public value belongs to the correct multiplicative subgroup. This can be considered only as a minor problem, but it may affect to authentication. [5]

The 40-bit encryption is easily broken, so implementations requiring strong security should not allow 40-bit keys. Similarly, anonymous Diffie-Hellman is strongly discouraged because it cannot prevent man-in-the-middle attacks. For example, certificate chains containing 512-bit RSA keys or signatures are not appropriate for high-security applications. [3]

Whenever the server is authenticated, the channel should be secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients, since the client signature in the certificate verify message may require a server certificate to bind the signature to a particular server. Completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper-proof channel is used to verify that the finished messages were not replaced by an attacker, server authentication is required in the environments where active man-in-the-middle attacks are a concern. [3]

Care must be taken in designing and seeding PRNGs. PRNGs based on secure hash operations, most notably MD5 and/or SHA, are acceptable, but cannot provide more security than the size of the random number generator state. [3]

The 512-bit RSA keys are not secure enough for high-value transactions or for applications requiring long-term security. When the public key in the certificate cannot be used for encryption, the server signs a temporary RSA key, which is then exchanged. In exportable applications, the temporary RSA key should be the maximum allowable length (i.e., 512 bits). Keys should be changed often. For typical electronic commerce applications, it is suggested that keys be changed daily or every 500 transactions, and more often if possible. Note that while it is acceptable to use the same temporary key for multiple transactions, it must be signed each time it is used. [3]

For the man-in-the-middle attack, an attacker must actively change one or more handshake messages. If this occurs, the client and the server will compute different values for the handshake message hashes. As a result, the parties will not accept each others' finished messages. Without the master_secret, the attacker cannot repair the finished messages, so the attack will be discovered. [3]

4.4. What is an acceptable level of security?

A sufficient security level is always a compromise between the usability and the strength of the used encryption method. It is impossible to define certain standards for a sufficient level of security because the needed level is dependent on the transferred data. The transmitted information always has some value, hence, the owner of the information decides how much effort is put to preserve the confidentiality.

A company's strategic plan is such information which requires a usage of a remarkably strong encryption methods. It may even be the case that encryption requirements are not met because of the export regulations. On the other hand, some information may not require any encryption e.g. short message to someone where the receiver is asked to have a cup of coffee. One could think that if encryption algorithms exist then why they should not be used? Encryption is more than just selecting the algorithm. Different algorithms have a variable amount of requirements in order to work properly. Usually the stronger the selected algorithm is the more it requires computing resources.

From the WTLS's point of view the provided security level is always a trade-off with the usage of limited resources. There is no point in using over 50 % of the limited computing resources for encryption and decryption or create excess traffic to the narrow bandwidth. However, the WTLS has to ensure certain security level in order to be used for commercial purposes.

The worst flaw in the WTLS is that it allows users to choose extremely weak algorithms. An example of a weak algorithm is the SHA_XOR_40 which should provide intergrity for data. The other defect is that it is the server which makes the ultimate decision on the used algorithms though the decision is made based on the client's suggestions. If the client does not suggest certain algorithms which the server is willing to use the connection cannot be established.

For reference Table 4.1. gives a picture of the average time estimates for a hardware brute-force attacks. The figures are based on the estimates made in 1995.

Table 4.1. Average time estimates for a hardware brute-force attack in 1995[6]
Length of key in bits
Cost [$]	40	56	64	80	112	128
100 K	2 s	35 h	1 a	70 000 a	10xE14	10xE19
1 M	0.2 s	3.5 h	37 d	700e0 a	10xE13	10xE18
10 M	0.02 s	21 min	4 d	700 a	10xE12	10xE17
100 M	2 ms	2 min	9 h	70 a	10xE11	10xE16
1 G	0.02 ms	13 s	1 h	7 a	10xE10	10xE15

According to the Moore's Law, nowadays the time estimates can be divided by 10. In the WTLS, the most used encryption algorithms for ciphering the communication channel will be the RC5_CBC with 40- and 56-bit keys and DES_CBC with a 40-bit key. Needless to say, 40 or 56 bits are not enough. There are no technical restrictions for using longer keys, even the current CPU resources and the available bandwidth would be adequate for a stronger encryption. The export regulations dictate the current level of security. The WTLS also provides 3DES_CBC_EDE with a 168-bit key but it is not allowed to be used outside the USA.[14]

In addition to the short key length, some of the keying material is used as parity bits in DES-based algorithms. This causes the effective key length drop even more. Actually, the effective key lengths are 35 bits, DES_40, and 56 bits, DES_64. Generally, the DES is an old standard and there are several implementations for breaking DES.

The public keys are used in exchanging the pre-master, hence, it is vital that the exchange is performed in a secure manner. Table 4.2. illustrates some recommendations for the public-key lengths.

Table 4.2. Recommended public key lenghts (in bits)[6]
Year	vs. Individual	vs. Corporation	vs. Government
1995	768	1280	1536
2000	1024	1280	1536
2005	1280	1536	2048
2010	1280	1536	2048
2015	1536	2048	2048

In the WTLS, for anonymous key exchange only 512- and 768-bit versions are available. For certified authentication no restrictions are set on behalf of the WTLS. However, no information about the currently supported key lengths were available. According to the Wassenaar Arrangement, it does not have any restrictions for authentication or digital signatures. This applies on the condition that only directly authentication related information is transferred using these protection mechanisms. [14]

Assuming that certified authentication uses key lengths above 1024 bits, the WTLS provides a sufficient level of confidentiality for the key exchange and the authentication. But when it comes to anonymous key exchange, a 512-bit key is far too short in order to provide a secure key exchange. The 768-bit option is on the limits of acceptability.

The keyed MAC functions, SHA-1 and MD5, provided by the WTLS can be considered secure if the full key length is used. According to Schneider, there are no known cryptographic attacks against SHA or MD5. However, it is said that MD5 has a weakness in the compression function, but it has no practical impact on the security of the hash function. [6]

The WTLS is the first attempt to provide a secure end-to-end connection for the Wireless Application Protocol. The most common protocols, such as TLS v1.0 and SSL v3.0, were adopted as a basis of the WTLS. However, it was not possible to apply the procedures, used in the traditional connection-oriented world, as such. The development work resulted in a protocol which resembles the TLS but it has some properties in order to adjust to the wireless world.

The WTLS supports a coverable span of algorithms to meet the requirements of privacy, authentication, and integrity. Currently, privacy is implemented using the block ciphers, such as DES_CBC, IDEA, and RC5_CBC. RSA- and Diffie-Hellman-based key exchange suites are supported to authenticate the communicating parties. Finally, integrity is implemented with SHA-1 and MD5 MAC algorithms. [13]

We came to a conclusion that it is possible to guarantee a sufficient security level on condition that the supported algorithms are combined in an appropriate way. By doing this, most of the known security problems can be dodged. For example, by using a strong authentication, RSA key exchange with RSA-based certificates and key length at least 1024 bits, a block cipher, RC5 with 56-bit key, and a full MAC algorithm, SHA-1, an ordinary user can be fairly confident on the security level. However, the WTLS allows the client or the server to select a NULL-cipher algorithm, hence, communicating without ensuring privacy, authentication, or integrity. Moreover, the selected algorithms have to be in balance. There is no point in selecting public key exchange algortihm which only uses 512 bits and a block cipher which uses 168 bits.

We concluded that the WTLS does not contain any significant security holes, hence, no drastic architectural changes are needed. Nevertheless, it is desirable that some technology updates and minor procedural changes are carried out. A technology update required is replacing the current PKCS#1 version 1.5 with version 2.0, where a few important security holes are fixed. The RSA is used, both in the authentication and in providing integrity in the WTLS. Another major defect is the initial vector for block ciphers. All the values used in the calculation are known by any listening party. Some unique and secret information should be used in the IV-calculations providing more security. However, the secret information must not be the same piece of information used as the encryption key in the block cipher.

The Record Layer uses an optional sequence numbering. Nevertheless, the sequence number is obligatory with datagram transports. We discoveder that when the sequence number is used, it is transferred without encryption. This makes it for eavesdropper to generate the used initial vector. In the next WTLS versions, it should be desirable that the feature is modified so that the sequence number is encrypted.

In order to prevent man-in-the-middle attacks, the anynomous authentications should be denied, at least from the server side. One of the priority area is the public key infrastructure, especially, in the wireless environment. The problem will be the trusted third parties. Who will be the trusted third party? Are the mobile users willing to get a certificate from the present certificate providers or do they get certificates from the operator whose subsciber identification module they own? The subscribers, users, want to have their certificates as easy as possible.

We concluded that the WTLS is not capable of implementing privacy, which can be applied for valuable information, until the export regulations allow strong block ciphers to be exported. A 40-bit key cannot be regarded as suffiecient in any circumstances, a 56-bit key is on the limits of acceptance. However, as mentioned above, a realiable authentication and a guaranteed integrity are more important than privacy for everyday use. For delicate information, at least 128 bits are required. In the future stream ciphers are introduced in WTLS, it remains to be seen whether they will fix the privacy problem or will new security problems occur.

Regardless of the defects in the SSL and the TLS, they have gained a remarkable popularity providing security for the connection-oriented communication. They are considered to provide a sufficient security level. Same kinds of considerations can be taken into account when contemplating the WTLS. It is not a perfect, but a sufficient protocol. In order to help the WAP to spread, people have to rely on the security provided by the WTLS. Users should always bear in mind that an absolute security is a pure impossibility. Under any circumstances the users take a controlled risk when using the distributed services. They just have to accept certain risks related to network communication and decide what kind of information they are willing to hand in for transfer. The same rule applies to the WTLS and the WAP.

Further Information

[DES] American National Standards Institute, American National Standard for Information Systems-Data Link Encryption, ANSI X3.106, 1983.

[RC5] Baldwin, R. and Rivest R., RFC 2040: The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms, October 1996
<ftp://ftp.isi.edu/in-notes/rfc2040.txt>

[X509] CCITT, The Directory Authentication Framework, Recommendation X.509, 1988.

[DH1] Diffie, W. and Hellman M. E., New Directions in Cryptography, IEEE Transactions on Information Theory, V. IT-22, n. 6, Jun 1977, pp. 74-84.

[HMAC] Krawczyk, H., Bellare, M., and Canetti, R., RFC 2104: HMAC: Keyed-Hashing for Message Authentication, February 1997
<ftp://ftp.isi.edu/in-notes/rfc2104.txt>

[IDEA] Lai, X., On the Design and Security of Block Ciphers, ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.

[DSS] National Institute of Standards and Technology, U.S. Department of Commerce,Digital Signature Standard, NIST FIPS PUB 186, May 1994.

[SHA] National Institute of Standards and Technology, U.S. Department of Commerce,Secure Hash Standard, NIST FIPS PUB 180-1, DRAFT, May 1994.

[MD5] Rivest, R.,RFC 1321: The MD5 Message Digest Algorithm, April 1992.
<ftp://ftp.isi.edu/in-notes/rfc1321.txt>

[RSA] Rivest, R., Shamir, A. and Adleman L.M., A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126.

[PKCS1] RSA Laboratories, PKCS #1: RSA Encryption Standard, version 1.5, November 1993.

[3DES] Tuchman, W., Hellman Presents No Shortcut Solutions To DES, IEEE Spectrum, v. 16, n. 7, July 1979, pp 40-41.