Yasuhiro Takahashi <email@example.com>
Susumu Matsui <firstname.lastname@example.org>
Yukio Nakata <email@example.com>
Takeshi Kondo <firstname.lastname@example.org>
Systems Development Laboratory, Hitachi, Ltd.
292 Yoshida-cho, Totsuka-ku, Yokohama, Kanagawa, 244 Japan
We propose a communication method with compression and encryption for mobile computing environments. Our method can be used without modifying network equipment, communication control software, or application software. Our method uses WinSock API (Application Programming Interface) between application software and TCP/IP software and intercepts WinSock commands temporarily. In the meantime, our secure communication add-in program compresses and encrypts the sending and receiving data of that command. It also does negotiating and encryption key controlling. Our program originally separates, assembles and disassembles data from the application software. And it does step-by-step compressing, controlling protocol and synchronizing compression dictionary information between the sending and receiving stations.
This method offers communication data compression and encryption from end to end by adding a process via WinSock API without changing the existing TCP/IP-based application.
Mobile computing has been given special attention as the next personal computing and communication environment because of the enormous improvement in performance of the portable computer, personal digital assistant (PDA), and wireless networking infrastructure . However, mobile communication infrastructures, especially wireless data networks, lack communication speed, reliability and security. Mobile users are worried about information leakage by wireless tapping. Therefore, research and development is needed for communication security of mobile computing environments . Encryption tools and new applications that use exclusive API for security control have been proposed [3,4]. However, we think most users want to use existing application software without having to change it.
This paper describes a communication method with data compression and encryption for mobile computing environments (Figure 1). This method offers communication data compression and encryption from end to end by adding a process via WinSock API without changing the existing TCP/IP-based application.
There are two methods of compressing and encrypting communication data: (1) Encryption done by the application and compression done by the modem and (2) embedding the functions of encryption and compression into the communication control software. Both methods have problems. High-performance compression is not anticipated using method 1, because data randomizing by the first encryption process removes regularity, thereby preventing efficient compression in the compression sequence after the encryption sequence . Applications should have the encrypting function in the case of method 1. There is another problem: In method 2, changing the TCP/IP software is necessary, which is against our goal. The method of data compression and encryption processing in PPP (Point to Point Protocol) is popular, but it only takes effect between client and access server.
WinSock API is a standard application programming interface for TCP/IP-based PC communication programs. We achieved embedded data compression and encryption without changing the TCP/IP and application software by intercepting WinSock commands from WinSock API temporarily and adding individual processing. Figure 2 shows intercepting WinSock commands.
First, our application execution support program changes the linkage between the target application program and WinSock DLL program when the target application program is loaded into memory by the loader before its execution. The secure communication add-in program that we developed intercepts the send command of the application program from WinSock API, compresses its data in the send command, encrypts the data, and then returns this command to WinSock DLL, which is properly transferred. On the other hand, the receive command is intercepted from WinSock API, as with the send command. Also, the secure communication add-in program decrypts the data received from WinSock DLL, decompresses it, then returns it to the application program, which is properly transferred. Other commands of WinSock are processed in the same way as above. By using this method, we have achieved these features without changing any program or any interfaces.
A negotiation function is needed to achieve communication between a PC that has a security function and one that does not. However, we do not want to change TCP/IP protocol. So we decided to execute a negotiation sequence in the middle of the original TCP/IP connection establishment sequence without changing TCP/IP protocol and programs. In our negotiation sequence, secure ability check of the other party, selection of the compression method, selection of the encryption method, identification of the encryption key, etc., are done.
To put it concretely, in the negotiation sequence, first the connect command from the application program is intercepted by our secure communication add-in program. The secure communication add-in program changes the original port number in the command intercepted from WinSock API to the secure port number that has previously been prepared. The secure port number is prepared for secure communication in order to classify normal communication. Figure 3 shows communication with the secure port. The connection command, which is modified, is then transferred to WinSock DLL. The connection requirement with the secure port number is sent to the other party. If that party has the secure function, connection will be established with that secure port. But if that party does not have the secure function, it cannot establish the connection with that secure port. After recognizing the ability of the other party by monitoring whether a secure port connection was established, secure communication or normal communication will be done as needed. If that party has the secure function and secure connection is established, our secure communication add-in program will not return the "connect complete" indication to the application program immediately. The secure communication add-in program will continue the negotiation sequence with the secure communication add-in program of the other party. After the negotiation sequence of our exclusive secure function, the "connect complete" indication will be returned to the application program. On the side of the other party, the accept command from the application program is intercepted by the secure communication add-in program, and it is re-transferred to WinSock DLL. The accept command is returned after completion of the negotiation sequence between the two sides of the secure communication add-in program.
These negotiation sequences are treated as the normal data transfer phase for TCP/IP protocol. Therefore, we could implement the negotiation without changing TCP/IP protocol (Figure 4).
In our method, data compression processing is done before transferring to TCP/IP. So the length of data transferred from the application program and the length of data compressed and sent to the other party via TCP/IP are not the same. Also in the non-block mode send sequence of TCP/IP protocol, the return value of the send command should indicate the length of buffering in the send buffer of TCP/IP. However, in our method, the buffering data are part of the compressed data, and the length is measured by compressed data size. So size conversion is necessary. The return value should be indicated by the measuring of real data size, not compressed data size. However, size conversion of one part of the compressed data to real size data is difficult. Figure 5 shows data size conversion for the return value to the application program.
In addition to this problem, if the compression method uses a dynamic renewing and reconstructing dictionary method in the communication sequence, all of the compressed data should be transferred to the other party completely. If only one of the parts of the compressed data is received, inconsistency of compression dictionary maintenance between the send and receive sites will occur. Figure 6 shows the unmatch problem of compression dictionary on both sides. In this case, renewed dictionary information should be put back, but this process is difficult.
To solve this problem, we considered methods of packetizing the TCP/IP stream-type data. Figure 7 shows the compress and send operation step by step. In our method, a secure communication add-in program divides the stream-type data from the application program into fixed-size frames. It compresses and encrypts every fixed-size frame, packetizes it, and transfers it to TCP/IP. It is very easy to calculate the real data size of send completion data, because every packet is sent completely under the control of the secure communication add-in program; the original real data size of every compressed packet is known and is a multiple of the fixed-size frame. In addition to this processing, put-back operation of the compression dictionary is not necessary, because the compression and send processes are done step by step, and every frame that is compressed is sent. Due to this feature, the application program does not need to know whether the data are compressed in the communication control layer.
The selection of compression method and encryption method varies in accordance with the kind of data and security policy. The compression routine and encryption routine are treated like an external library. The user can select them freely. Our secure communication add-in program controls the order of the process sequence of compression and encryption. The encryption key is also handled by this program. Figure 8 shows the program structure.
We measured the overhead of our methods. Evaluation was done between two PCs, and we found that the overhead of intercepting WinSock commands from WinSock API was less than 10 percent.
A secure client and server system is easy to construct using our method. Every client and server implements our secure communication add-in program. If its network is via the Internet, a firewall will be established. Within the firewall, by implementing proxy function that exchanges secure port communication, secure client and server communication will be achieved in the Internet environment.
We described a communication method with data compression and encryption for use as middle ware in a mobile computing environment. Our method offers communication data compression and encryption from end to end by adding a process without changing TCP/IP program and the existing TCP/IP-based application. This system, which intercepts WinSock commands between the application program and the WinSock DLL program from the WinSock API and processes compression, encryption and negotiation, can be achieved with low overhead. This method can easily achieve secure and efficient communication with all existing communication application programs and popular TCP/IP programs.
The authors would like to thank Masanori Kataoka, Dr. Matsuaki Terada, and Dr. Ryoichi Sasaki for their encouragement. Thanks are also due to Shigeru Motobayashi and Hisashi Hashimoto for their valuable discussions.
Yasuhiro Takahashi received a B.E. degree in electrical engineering from Keio University, Yokohama, Japan, in 1981. In 1981, he joined the Systems Development Laboratory of Hitachi, Ltd., Japan. He has been involved in research and development of LAN systems, communication protocol, and computer-supported multimedia communication systems. He is currently engaged in research on mobile computing and communication systems. He is a senior researcher at the Systems Development Laboratory, Hitachi, Ltd. Mr. Takahashi is a member of the Institute of Electronics, Information and Communication Engineers of Japan and of the Information Processing Society of Japan. E-mail: email@example.com
Susumu Matsui received a B.S. degree in physics from Kobe University, Kobe, Japan, in 1978, and an M.S. degree in physics from Osaka University, Osaka, Japan, in 1980. In 1980, he joined the Systems Development Laboratory of Hitachi, Ltd., Japan. He has been involved in research and development of LAN systems, communication protocol engine, and multimedia communication protocol. He is currently engaged in research on mobile computing and communication systems. He is a senior researcher at the Systems Development Laboratory, Hitachi, Ltd. Mr. Matsui is a member of the Institute of Electronics, Information and Communication Engineers of Japan, of the Information Processing Society of Japan, and of IEEE. E-mail: firstname.lastname@example.org
Yukio Nakata received B.E. and M.E. degrees in electrical engineering from Nagoya University, Nagoya, Japan, in 1970 and 1972, respectively. In 1972, he joined Hitachi, Ltd., Japan. He has been involved in research and development of wireless LAN systems, communication control software, and distributed file access systems. He is currently engaged in research on mobile computing and communication systems. He is a senior researcher at the Systems Development Laboratory, Hitachi, Ltd. Mr. Nakata is a member of the Information Processing Society of Japan. E-mail: email@example.com
Takeshi Kondo received B.S. and M.S. degrees in physics from Chiba University, Chiba, Japan, in 1986 and 1988, respectively. In 1988, he joined the Systems Development Laboratory of Hitachi, Ltd., Japan. He has been involved in research and development of communication control software. He is currently engaged in research on mobile computing and communication systems. Mr. Kondo is a member of the Institute of Electronics, Information and Communication Engineers of Japan and of the Information Processing Society of Japan. E-mail: firstname.lastname@example.org