This graphic is a representation of the layers of the WAP for reference2
Before a discussion on WTLS is entered upon, it is quite appropriate to describe SSL, which the WTLS and TLS are based off of. SSL (Secure Socket Layer) is the scheme proposed by Netscape Communications Corporation for security over the Internet. It is a low-level encryption scheme used to encrypt transactions in higher-level protocols such as HTTP, NNTP and FTP. The SSL protocol includes provisions for server authentication (verifying the server's identity to the client), encryption of data in transit, and optional client authentication (verifying the client's identity to the server).
The SSL sends encrypted data from the end user's browser (provided that the browser is capable of using SSL) to the server. This allows you to send confidential information across the Internet like passwords, credit card numbers or other confidential information.
Wireless Transport Layer Security, or WTLS, provides the main security elements of WAP communications. By using the WTLS protocol some measure of authentication and confidentiality in wireless applications can be achieved on the low power wireless devices. As stated earlier, WTLS is the wireless version of the industry standard Transport Layer Security (TLS), which is equivalent to the widely used SSL security protocol. Security in the WAP architecture should enable services to be extended over potentially mobile networks while also preserving the integrity of 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. One of the most important requirements 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 has to be kept as small as possible because of the low bandwidth. WTLS provides an optimized handshake through dynamic key refreshing and enabling more data compression than TLS and SSL. The dynamic key refreshing allows the encryption or session keys to be updated on a regular or configurable basis.
8The Internet's TLS establishes a secure network connection session between a client and a server, typically between a Web browser and a Web server. WTLS provides a secure network connection session between a WAP device and a WAP gateway. WTLS was developed because of the special needs of the high-latency, low-bandwidth wireless environment. 7Three classes of authentification can be implemented on different WAP-enabled devices, including:
Class 1 – anonymous authentification - is 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 authentification - 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 authentification - 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 also the client certificate has to be safeguarded and managed until the certificate expires. Client certificates need not be retained on the handheld device.
2The WTLS protocol is composed of three layers: the handshake protocol layer, the record layer, and the alert layer. The handshake protocol layer manages the secure connections and key exchanges, and provides client and server authentication. The record layer handles privacy and data integrity, and the alert layer reports error conditions and handles the close alert.
3SSL is widely used in the "web" world to encrypt the data stream between the browser and the web server is actually also used in the WAP environment. Wireless devices are low power, therefore incapable of performing the more complex algorithms that the SSL performs in order to encrypt data. Therefore, less complicated algorithms are implemented in the WTLS to incorporate the needs of a low power device. Currently, that seems to be the reason for the two different standards being used.
WTLS’s function is to add as much security as possible to low CPU-powered wireless devices by making the cryptography efficient. Because wireless device’s CPUs are typically slow, using SSL end to end can take anywhere from 30 seconds to several minutes, depending on the key size used to negotiate an SSL connection. WTLS can use familiar public key exchange algorithms, such as RSA or Diffie-Hellman, but these algorithms are resource-intensive and, therefore, slow. For RSA encryption, the wireless devices simply don’t have the system resources (i.e. RAM) to complete the complex algorithm.
11Different security items in the WTLS protocol include:
Connection End - Whether this entity is considered a client or server in this secure session.
Bulk Cipher Algorithm - An algorithm to be used for bulk encryption. This specification includes the key size of this algorithm, how much of that key is secret, whether it is a block or stream cipher, the block size of the cipher (if appropriate), and whether it is considered as an "export cipher".
MAC Algorithm - An algorithm to be used for message authentication. This specification includes the size of the key used for MAC calculation and the size of the hash which is returned by the MAC algorithm.
Compression Algorithm - The algorithm to compress data prior to encryption. This Algorithm specification must include all information the algorithm requires to do compression.
Master Secret - A 20 byte secret shared 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.
Sequence Number Mode - Which scheme is used to communicate sequence numbers in this secure connection
Key Refresh - Defines how often some connection state parameters (encryption key, MAC secret, and IV) are updated New keys are calculated at every n = 2key_refresh messages, ie, when the sequence number is 0, n, 2n, 3n etc.
Data path from WAP device to the Internet4
4The graphic above shows the model of how a WAP device communicates with the wired Internet. A WAP device, after sending data to the wired network, has been encrypted using WTLS. Thus the WTLS encrypted data must be translated to SSL which is the encryption standard of the Internet. After reviewing a description of the WTLS and examining the different features of it, along with the different parameters that can be chosen to work with it, the problems that will be conquered in the remainder of this paper are revealed.
4By seeing that the data from a wireless device must communicate with the Internet through a gateway, one such problem arises, and that is the problem of the encrypted WTLS data from a WAP device having to be decrypted and then encrypted again using SSL. This instant, most likely a couple of milliseconds, is the crucial time where the data is vulnerable to intruders, no matter how much is done to protect it currently. To some people, this problem does not present an immediate threat, but the problem exists nonetheless. For banking institutions, government work, and other high risk wireless transactions of data, this problem could possibly present a greater threat as more people in the world find this loop hole in the WTLS. Currently, physical restraints on who has access to the gateways are placed, but no practical solution has been implemented that ‘takes care’ of the data while in its vulnerable state. 14Several items must be taken into account when coming up with solutions to this problem of decrypted data shortly residing in the server’s memory:
- Ensuring the gateway never stores decrypted data to secondary storage media.
- Use a translation process that is designed for security and speed so clear-text content is erased from internal memory as quickly as possible.
- Provide physical security to ensure that only authorized administrators have access to the gateway and console.
- Restrict the gateway from remote administrative access.
- Apply appropriate hardening guidelines to the gateway server operating system.
9Another problem that is evident is the lower level algorithms that are used to encrypt data in the WTLS. The reason for the lower level algorithms is quite apparent, that being the low power nature of a wireless device and thus less system resources to accommodate a much more resource intensive algorithm that would provide greater security. Currently, if one of the more resource intensive algorithms were chosen to solve this problem, battery life would be exhausted just performing the calculations to encrypt data.
5One of the current algorithms that is currently used in part is elliptic-curve cryptography (ECC). 16Elliptic curves, through examination, provide a form of a public key method. Smaller and therefore faster keys can be used to provide an equivalent level of security to traditional public key. Older public key methods use discrete logs as there mathematical basis, and as they are attacked increasingly, require longer bit lengths to ensure security. Elliptic curves are much harder to solve. If the same number of bits are used for regular public key and for the elliptic-curve model, the elliptic-curve is a safer route.
Simulation Program
In order to effectively see if the “GAP in the WAP” is actually a big problem, a set of tests must be run in order to study this problem. People can look at it from a theoretical basis, and it might be said that data is unencrypted at one stage and that is unacceptable. Only through mathematical computations and case study can the conclusion can be drawn that the security leak presently is dangerous at all.
On the Internet or on any computer that I looked, it was very difficult to find a simulation program that didn’t cost a lot of money and did exactly what I wanted it to. The program would simulate a hacker trying to find out where in memory on a “server” a packet started. Currently, on a gateway server, a packet is unencrypted for just a split second of time while the server decrypts the WTLS encoded packet into a SSL encrypted packet for transport over the Internet. The program would see just how vulnerable data is given a memory size and duration of time the program is run. The program would assume that the hacker does not know the algorithm by which the server places the packet into RAM on the server computer. Because of this, the hacker must variably guess where the server would put the packet in RAM. I chose for the program that I created for the server to place the packet starting on any random starting point in the memory.
The gateway server would in the real world have just a subset of total memory to place its own data in, so the size of that subset is easily changed in the program itself. The program specifications include for it to put out a file of the results of each test performed for easy analysis by myself. Also, the program should be able to run for a user specified amount of time.
In order to effectively test how vulnerable data is, a set runtime had to be picked that was sufficiently large but also had to remain constant in order for the data to be easily analyzed. I decided that testing 1,000,000 starting points would be sufficient and give enough data to analyze. Looking at it from an outside view, 1,000,000 starting points would be that many points multiplied by 1024, which is the size of a packet by Internet standards. The total data amount then would be a gigabyte of data. The simulation would then be run ranging from memory sizes of one packet until there were no ‘hits’ by the hacker program. The size of the memory would be incremented based on powers of two.
This is a screenshot of the data file that was output from the program.
Data gathered by the program
The above is a graph of the hits by the ‘hacker’ program per memory size given. As visible, the hits become negotiable to nothing after a substantial size of memory is allocated to place packets.
First of all, one must realize that any person that can intrude on the server itself and figure the algorithm by which the server places packets on the gateway server after they are decrypted can effectively view all the packets coming on and off of the gateway server. Getting to the server itself in modern business can be a major problem for hacker. Currently, gateway servers in a corporation are highly protected pieces of equipment. Vendors know that the problem exists and keeping the gateway server physically secure is one thing that is easily implemented in order to make sure the problem stays behind a locked door. 6One of the only ways currently known to actually get to the server itself is to have someone on the inside of the business that is helping the hacker or that is the hacker. If the ‘hacker’ cannot determine the algorithm that stores items in RAM temporarily then the case study can come into effect and the data is very valid. The hacker program has no idea where the packet will start so it must guess very randomly each time.
The analysis of the data comes easily from the table of data, but even easier from the graph produced from that table. From the starting point of the data gathered of the memory size of 1024 bytes, which is the size of one packet, the hits by the hacker decrease dramatically by each power of two memory is increased. By each power of two memory is increased, the number of hits by the hacker program is about cut in half. In general, given the memory size large enough to place packets in temporarily, the hacker could not assemble enough packets in a row to gather enough data to be even somewhat ‘deadly’. Through the sample of 1,000,000 packets for each memory size given, the number of hits by the hacker never even was one percent of the total packets placed.
The question can now be answered as to whether the “GAP in the WAP” actually is very important at all to bother with. By analysis of the data gathered and by looking at the problem as a whole one can come to a few conclusions that are very relevant to the end solution presented later in this paper. One of those conclusions is that there is a hole, period. Some person somewhere in the world will figure out a gateway server’s placement algorithm and be able to snoop packets as they choose. This, by principle, is reason to do something different with today’s current system. Data, in theory, should be private to the user and any attempt by an individual other than the user to access that data should be avoided at all costs.
The second conclusion that can be come to after mainly data analysis study is that the hole is very minute, in fact, almost not worth bothering with in some aspects. For general web browsing on a cell phone, the security that will be implemented to fix the problem on the gateway server is not worth the effort or the time it will take to put the architecture in place to fix it. But, one does not know when a person will go from general use of the web to secure applications such as stock trading, banking, and other such high risk wireless applications. By increasing the size of the memory substantially enough such that the gateway server has a large amount of space to place decrypted packets in, it makes the job of the hacker much more difficult to even find the starting point of a packet on the system. Even if that information is found out, by the time the hacker figures the starting location out and tries to get the packet, another packet is already decrypted by the server in another location on the server in RAM and being encrypted again. The hacker would try to get the packet that was just found and would be faced with the problem of the constant flow of packets in and out of system RAM. Data would only be in RAM for less than a second, possible just a millisecond. For that reason alone, the problem effectively remains almost nothing now after study of the simulation results and data gather subsequently.
13Two options are becoming available for end-to-end WTLS security. The first is WTLS tunneling, which tunnels WTLS traffic through a service provider's network to a remote WAP gateway. Tunneling, in effect, allows data to pass through a gateway without decryption. Tunneling, through study of the WTLS protocol, requires WAP 1.3 or greater by the gateway server. The tunneling ensures backward compatibility with older handsets, rather than every single wireless user in the world to buy a special type of handset just to get secure transmission of data. The tunneling protocol is responsible for establishment, redirection, and clearance of tunnel sessions between the access point and the PPP server. There are two types of messages used by the tunneling protocol: control messages and data messages. Control messages are used to establish, maintain, redirect, and release tunnel sessions. Data messages are used to transport user data such as PPP frames. For each device connected to the access point, a separate tunnel session is established from the access point to the PPP server. Thus, there is a one-to-one relationship between a device and its associated tunnel session. The registration procedure of the wireless MAC protocol and tunneling protocol together achieve seamless roaming of mobile devices through the access points without breaking the PPP connections.
Example showing the path of data that is tunneled
12A second option is to let the translation from WTLS to SSL occur behind a firewall on another WAP gateway. A firewall is a system for easily blocking intruders from accessing anything that is occurring behind the firewall. However, this calls for the wireless device to process additional information to find and connect back to the end server where the transactions take place, requiring a technically proficient user who can enter the appropriate IP address, remote access server number, and URL. So, this technique is ruled out almost immediately because of the processing required by the wireless device and the overhead of installing many additional gateways, thus resulting in a greater cost to the user in the long run. For this reason, tunneling will be focused on for the remainder of the paper along with its benefits and downfalls.
1Tunneling is a technology that enables one network to send its data via another network's connections. Tunneling, in effect, puts the packets that are to be transported into packets carried by a second network. It is almost like having your own private network. Tunneling employs the Internet Protocol (IP), which specifies the format of packets and the addressing scheme. All data transmitted over the tunnel is encapsulated in IP packets. Protocols can be routed and bridged, and filters can be implemented quite easily. IP, IPX, and bridged data can be transmitted over a tunnel.
A couple of main conclusions can be drawn from this survey of the WTLS and its inherent problems and solutions. One of these conclusions is that current algorithms protecting data such as elliptic-curve cryptography are secure enough for now. Because the Internet’s public key has been attacked by hackers constantly for the past 20 years, much more powerful machines have to be used in order to process the lengthy string of bits to ensure encryption stays adequate. Elliptic-curve uses a more complicated mathematical basis to ensure its integrity, and therefore is safer in many aspects than public key. The algorithm in WTLS is definitely secure and need not be changed.
The other main conclusion that can be drawn is that something must be done to fix the problem of data being decrypted on the gateway server between a wireless device and a destination web server. The solution of providing a firewall to process the information behind is effective, yet it requires every site that wants to process the information to buy another gateway server to put behind the firewall and the cost of the firewall itself. I’m sure that server vendors would be happy with this solution, but the cost effectiveness of it is not paramount by any means. Therefore, the solution of tunneling seems to be the most effective solution per dollar spent to fix the problem. Data is secure through tunneling and it is a software solution without much overhead involved to process the data involved. No extra hardware must be bought, except an occasional extra server for large installations that process large amounts of wireless data. With the introduction of WAP 1.3 things such as digital certificates will be introduced to ensure data integrity even more, so data will be secure, and the world will find something else to complain about.
Source Code for Program
Dim memorysize As Long, spot As Long
Dim spot2 As Long, outputstring As String
Dim hits As Long, runtime As Long
Dim total As Long, totaltime As Long
Private Sub generate_Click()
spot = Int((memorysize * Rnd) + 1)
End Sub
Sub Hack_Generate()
spot2 = Int((memorysize * Rnd) + 1)
End Sub
Private Sub simulate_Click()
hits = Int(0)
total = Int(0)
memorysize = Int(memsizebox.Text)
runtime = Int(runtimebox.Text)
ReDim memory(memorysize)
For n = 1 To runtime
Call generate_Click
Call Hack_It
Next
display.Text = hits
percentbox.Text = hits / total
outputstring = memorysize & " " & total & " " & hits
'MsgBox outputstring
SaveTextToFile "c:\windows\desktop\output.txt", outputstring
End Sub
Sub Hack_It()
Call Hack_Generate
If spot = spot2 Then hits = hits + 1
total = total + 1
End Sub
Works Cited
1) “Internet Secure Tunneling Implementation Guide.” Intel. . 10 Mar 2001.
2) “Security in the WTLS.” Helsinki University of Technology. . 10 Mar 2001.
3) “How secure is WAP with SSL and WTLS?” 123 Wap Info. http://www.123wapinfo.com/faqs/security/index04.htm . 10 Mar 2001.
4) “Wireless Application Protocol – the future of the Internet?” Tomas Johansson. . 10 Mar 2001.
5) “Crossing the Wireless Security Gap.” Alan Radding, Computer World. . 10 Mar 2001.
6) “Implementing Secure WAP e-commerce applications.” Global Solutions. . 10 Mar 2001.
7) “Tutorial: Wireless Security.” Network Computing. . 10 Mar 2001.
8) “WAP Security: Little Browsers Need Big Protection.” Web Tools. . 10 Mar 2001.
9) “WAP Security.” Grady67. . 10 Mar 2001.
10) “Are you really safe?” Wapband. . 10 Mar 2001.
11) “WapForum Wireless Security.” WapForum. . 10 Mar 2001.
12) “Fixing WAP’s security flaw.” Mbizcentral. . 10 Mar 2001.
13) “Tunneling Protocol.” University of Maryland. . 10 Mar 2001.
14) “Security Models for M-Commerce.” Sand Institute. . 10 Mar 2001.
15) “Wireless Application Protocol and Security.” Sans Institute. . 10 Mar 2001.
16) “Elliptic Curve Cryptography.” The World.com. . 1 May 2001.
