WIRELESS NETWORK SECURITY 53 4.2 The Adaptation Path Search Algorithm

The goal of the adaptation path search algorithm is to find certain PADs from PAT to form an adaptation path for a client so that the overhead occurred by using the PADs along the path, is reduced as much as possible. For more complicated PAT such as the one in Figure 5, the Fractal framework [1] proposed an adaptation path search algorithm to find the path efficiently. For the one-level PAT in the adaptive encryption protocol the adaptation path search algorithm reduces to evaluate the overhead of each encryption PAD algorithm one by one and choose the one with the least overhead.

PADtotal=P ADdownload time+P ADservercomp +P AD client

comp+P AD_{traffic overhead} (1) We define the total overhead of each PAD as the sum of PAD download time, server side and client side computing time for unit data, i.e. RC4 encryption time for 1KB data on server side and decryption time for 1KB data on client side, finally the traffic overhead incurred by this PAD as shown in Equation 1. Since the PAD size is very small as we can see in Table 1, large amount PAD download experiment from the three PlanetLab nodes shows that the average download time are as close as 1 millisecond difference. Furthermore, each PAD is at most downloaded once in the whole application procedure. We consider the PAD download time as a constant and eliminate it from the PAD total overhead evaluation. On the other hand, since the three PADs, 3DES, AES, and RC4 do not change the size of the input data even with different key length, the traffic overhead of each PAD can also be excluded. Eventually, the PAD total overhead is simplified as Equation 2.

PADtotal=P ADcompserver+P AD client

comp (2)

Server side computing time of each PAD can be obtained proactively by testing each PAD on the application server. In order to evaluate the client side computing time of each PAD, running each PAD on each client configuration to get the overhead is not a wise solution because there are so many different client configurations. Instead, we use a linear model to estimate the overhead, which inspired by the observation that the computing overhead of each PAD is roughly proportional to the processor speed. As shown in the second part of the new total overhead equation 3, if the computing overhead of a PAD on a standard processor speed,Stdcpu, i.e. 500MHz Pentium IV in the platform, is known as theP ADStd

comp, the computing overhead on the client side can be deducted from the linear ratio of the speed of the standard processor and client processor. However, this linear model is not so accurate because other parameters of the system introduces error into the linear model, i.e. the operating system. We abstract normalized ratio parameters about two key properties: processor typesasA andapplication types as B in the equation. Note that it is easy to introduce more parameters if necessary, e.g., the operating system types and the network types defined in Fractal framework [1].

54 HANPING LUFEI and WEISONG SHI

PADtotal=P ADservercomp +A × B ×

Stdcpu

Clicpu

×P ADStd_comp (3)

Usually, the normalized ratios such asAandBare in the form of matrix, as shown in Equation 4, to measure the performance ratios of 7 PADs on 3 kinds of processor types and on 2 kinds of application types, legacy and new system since they have different encryption requirements.P,D, andLrepresent the Intel PXA 255 processor in Pocket PC, Pentium IV 2.0GHz processor in Desktop, and Pentium IV 3.06GHz processor in Laptop respectively. We use the following simple example to explain the normalized matrix. WinCE PalmOS WinMedia Kinoma 1 ∞ ∞ 1

The above matrix shows the impacts of two operating systems (the top line) on two multimedia players (the left most column). The values in the matrix mean the Windows Media works fine in the WinCE operating system (WinCE) [19] but not in PalmOS, while Kinoma player [20] runs well in PalmOS instead of WinCE. The value of ratios does not have to be an integer. Suppose now we are about to find the better one in terms of the computing time from these two players on WinCE platform. We get the time value using the linear method as, for instance, 5 sec for WinMedia and 2 sec for Kinoma. Without the normalized matrix, Kinoma will be chosen as the better player; however, the fact is that Kinoma can not run on WinCE at all. To get the correct result, we can use the first column of this normalized matrix to adjust the linear results by multiplying 2 sec with ratio 1 for WinMedia and multiplying 5 sec with ratio∞for Kinoma. Then the computing time of Kinoma becomes ∞, which immediately disqualifies itself. Go back to the normalized matrixAandB, because most of the operations in these encryption algorithms are bit operations instead of float-point operations, they have almost same running efficiency in these client CPU types. We set all values as 1. Different encryption requirements of applications are reflected inB. For example, the legacy systems only use the DES algorithm while the new applications will utilize the new encryption algorithms. Correspondingly in the normalized ratio matrix, we set the ratio as 1 for 3DES algorithm and∞for others in legacy systems. In our experimental platform, we specify the client applications on desktop as a legacy system and that on laptop and PocketPC as a new system. This may not be always true in reality, but just for comparison purpose in this experimental platform.

WIRELESS NETWORK SECURITY 55