Experimental Measurements and Design Guidelines for Real-time Software Encryption in Multimedia Wireless LANs Aura Ganz, Se Hyun Park, and Zvi Ganz Multimedia Wireless LAN Laboratory ECE Department, University of Massachusetts Amherst, MA 01003 ganz,shpark@tikva .ecs.umass.edu AIM Engineering Inc.
[email protected] Abstract To secure interactive multimedia applications in wireless LANs (WLANs) it is pertinent to implement real time cryptographic services. In this paper we evaluate the use of software based encryption algorithms that are implemented in the layer service provider as de ned by WinSock 2 for Windows 95/NT. Our measurements show that software implementation of various encryptors can sustain the throughput requirements of interactive multimedia applications for WLANs such as telephone-quality audio, video conferencing, and MPEG video. We present a design methodology that includes guidelines for a secure multimedia system design in terms of the encryption method chosen as a function of required application throughput, system con guration, protocol layers overhead and wireless LAN throughput.
This work was supported in part by NSF under contract number CISE-CDA-9529462. This paper was presented in part at MILCOM'98.
1
1 Introduction Wireless Local Area Networks (WLAN) markets are driven by a number of applications or scenarios such as: 1) LAN installation for temporary events in which wiring is very costly or impossible, 2) Extension of existing networks which may be permanent or temporary, 3) Savings in terminals. e.g., patients admission in hospitals in which the process is done in front of the patient without the need to move him to the desk, 4) LAN installation in old buildings in which cost of running cables is high, etc. In these examples users focus on data applications like email, le transfers and database transactions. Future Wireless LANs will need to support multimedia applications, e.g., teleconferencing, videoconferencing. These applications require guaranteed service, e.g. throughput, maximum time delay and time delay variation. In case these guarantees are not met, the quality and e ective delivery of these applications will be severely degraded. In 1997 the Wireless LAN standard, IEEE 802.11 [9] was approved for both physical layers, Infrared and Radio with employ either Narrowband or Spread Spectrum communication techniques. In this paper we will experiment with radio WLANs which employ Spread Spectrum (SS) techniques. Spread spectrum techniques provide resistance to intentional jamming by another source and the degrading e ects of multi-path transmission. The characteristics of SS modulation are also advantageous from the security standpoint, since both direct sequence (DS) SS and frequency hopping (FH) SS distribute the bits of transmission information for a chip duration [10]. The security aspects of SS communication have been investigated in [11]. The authors concluded that the use of SS as the only security mechanism will not be sucient. Active intruders in the same service area can easily know or detect the initial spreading code [1, 3]. Therefore, the design and implementation of secure communication is of seminal importance in wireless networks. Such design faces new challenges intrinsic in the wireless medium itself [1, 3], e.g. limited throughput in the ISM band, interference which causes noisy channels and limited power at the portable stations. Moreover, the integration of multimedia applications with security services is even a more challenging task. This is due to the fact that interactive applications (e.g. video conferencing) with strict Quality of Service requirements (in terms of throughput) will compete with the security services on the same scarce network and system resources. Inline security service is de ned as a mechanism, implemented either in hardware or software that encrypts/decrypts in real-time every packet transmitted/received by the application. Some military applications use cryptography boxes plugged into the very high speed network lines, e.g., FASTLANE and TACLANE (members of NSA's MISSI security family) [7]. These cryptographic boxes are a necessity in a very high speed communication network (tens or hundreds of Mbps). Due to their high cost, these boxes are usually shared by a number of computers. Dedicated cryptography hardware may not be the best choice for WLANs due to the WLAN characteristics: 1) relatively low data rates, 2) relatively low cost, 3) used mostly in portable devices, and 4) a distributed mobile environment. 2
In this paper we evaluate the use of software based inline encryptors which are implemented in the layer service provider (as de ned by WinSock 2 for Windows 95/NT) in each PC that is part of the wireless LAN. Software based inline encryptors are suitable for the WLAN characteristics listed above. Moreover, it is cheaper than hardware implementation and more exible for upgrades. The disadvantage is that its performance is limited by the computer system con guration which impedes the implementation of computational intensive encryption algorithms such as public key cryptography. Clearly, software encryption introduces one more potential bottleneck in the system performance. However, since the throughput of wireless links is limited, the di erence between software based encryption throughput and actual link throughput may not be dramatic as in high speed ber optic networks. We provide design guidelines for a secure WLAN that supports interactive multimedia applications. The choice of a suitable inline encryptor is a function of the required application throughput, the PC con guration and load, the WLAN throughput, and the protocol stack overhead. To determine the suitability of software inline encryptors for WLANs, we have implemented in software a number of encryption algorithms. Using a number of realistic WLAN scenarios and interactive multimedia applications, we have shown that software implementation of various encryptors provides a suitable solution for providing secure communication in WLANs that support multimedia interactive applications. The paper is organized as follows. In the next section we provide a brief description of multimedia applications that can be sustained by WLANs. In Section 3 we describe the proposed software architecture. The encryption algorithms we have implemented in software and their performance are introduced in Section 4. Section 5 describes application throughput measurements using inline software encryption. Section 6 provides the proposed design guidelines and Section 7 concludes the paper.
2 Multimedia Applications QoS applications will provide users with the following bene ts:
Videoconferencing with other network members. For example, remote consultation in hospitals in which physicians consult with each other while having the possibility to show the remote physician relevant information on the screen. Also in maintenance, a technician can request a remote technician to assist in solving a problem while providing him with pictures of the equipment he tries to x. Guaranteeing quality of service to preferred users or preferred applications when network load increases. In such a case a preferred user may send priority email and be con dent that his email will get to its destination with high probability. Collaborative work of several team members in which they share a document and simultaneously conduct voice conversation. 3
Required Throughput
Types of Applications
Non-Interactive Applications text email 2.4kbps http 9.6kbps multimedia mail < 64kbps multimedia notes < 100kbps Interactive Multimedia Applications telephone-quality audio 64kbps video conferencing 128kbps - 1Mbps MPEG video 1.54Mbps
Table 1: Candidate Applications for Multimedia Wireless LANs
Wireless Local Loop. Installing a single wireless delivery source of scalable communication services to a neighborhood. Thus, save on expensive infrastructure.
Since the current Wireless LAN technology can sustain data rates of up to 10 Mbps, a WLAN can support only a number of multimedia applications with relatively low throughput requirements such as video conferencing, text email, http and multimedia mail/notes. Table 1 shows the candidate applications and their required throughputs.
3 Encryption Throughput Measurements and Design Guidelines In this section we provide throughput measurements of encryption/decryption algorithms at the application layer for di erent computer con gurations and available CPU resources. We continue with design guidelines for inline software encryption.
3.1 Encryption Throughput Experimental Results In this section we provide a description of the experimental results, in terms of encryption throughput (Benc), that we have obtained for a number of encryption algorithms. To obtain the encryption throughput for two computer con gurations: 1) con guration M1: Pentium MMX 166MHz, 48M main memory, 512K L2 cache and Windows 95, and 2) con guration M2: Pentium 90MHz, 32M main memory, 256K L2 cache and Windows 95. We have tested at the application layer a number of bulk encryption algorithms: 1) RC2 (block cipher) and RC4 (stream cipher) [4] which are symmetric-key algorithms, implying 4
80Mbps 70Mbps
Encryption Throughput
60Mbps 50Mbps 40Mbps 30Mbps 20Mbps 10Mbps 0
0%
10%
30% - 50%
80%
90%
98%
90%
98%
Starting Available CPU (%) 0
0%
11 00
10%
11 00 00 11
30% - 50%
11 00 00 11
80%
11 00 00 11 00 11
11 00 00 11 00 11
100Kbps
11 00 00 11 00 11 11 00
M1: Pentium MMX 166MHz, 48M Main Memory, 512K L2 Cache, Windows 95 : RC4
: RC2
11 00 00: RSA 11
Figure 1: Throughput measurements of bulk encryption algorithms for con guration M1 and various available CPU resources. that both encryption and decryption operations use the same key, and 2) RSA [6] public key algorithm which encrypts and decrypts data much slower than symmetric algorithms . We have measured the encryption throughput which is de ned as the number of bits processed per second by the encryption algorithm. In Figure 1 we provide measurements of the encryption throughput versus the starting available CPU resources for a number of encryption algorithms, RC2, RC4 and RSA using computer con guration M1. From this gure we observe the deterioration of the encryption throughput as a function of decreasing available CPU resources. Figure 2 provides similar measurements for con guration M2. We observe that the encryption throughput is also sensitive to the computer processing power (90 MHz in M2 versus 166 MHz in M1).
3.2 Design Guidelines In this subsection we provide design guidelines for software inline encryptors for WLANs that support interactive multimedia applications. In our design space we take into consideration 1) the wireless LAN throughput, 2) the applications' QoS requirements in terms of throughput, 3) encryption throughput that is determined by the computer con guration, encryption algorithms and available CPU resources (as shown in the previous section), and 5
Encryption Throughput
10Mbps
5Mbps
0
0%
10%
30% - 50%
80%
90%
98%
Starting Available CPU (%) M2: Pentium 90MHz, 32M Main Memory, 256K L2 Cache, Windows 95 : RC4
: RC2
Figure 2: Throughput measurements of bulk encryption algorithms for con guration M2 and various available CPU resources. 4) additional processing overhead incurred by other protocol layers (also determined by the computer con guration, the application and the available CPU resources). We proceed with the following notations:
D data packet size (bytes). Bw wireless LAN e ective throughput (bps), i.e., we take into account the channel
noise and competition on the channel from other nodes in the WLAN. Therefore, this e ective throughput can be signi cantly less than the WLAN data rate. Bapp throughput requested by the application (bps). Benc encryption throughput at the source (bps) - as measured in Figures 1 and 2. Bdec decryption throughput at the destination (bps) - as measured in Figures 1 and 2. TSOH the time overhead spent by a packet at the source. This time includes the time required to process a packet in all the protocol layers (physical layer, data link layer, device driver, network layer, transport layer and application layer). This delay also includes any queueing delays in these protocol layers. This time overhead is determined by the computer con guration, application and available CPU resources. TDOH the time overhead spent by a packet at the destination. This time includes the time required to process a packet and its queueing delay all the protocol layers (similar to TSOH ). BS the maximum source throughput (bps), the maximum rate at which the source PC sends data to the network interface card, assuming that there is always a packet available to be sent from the source. 6
Distance Source PC
Wireless Channel NIC
TS
Destination NIC
PC
OH
Time
App. Tools
D / B enc
Encryption
D / B S TCP/IP Device Driver D.L.
D / Bw
Transmission D.L.
Device Driver
TD OH
TCP/IP
D / B dec
D / BD
Decryption App. Tools
NIC : Network Interface Card
D.L.
: Data Link
Figure 3: End-to-end packet journey.
BD the maximum destination throughput (bps), the maximum rate at which the destination PC sends data to the application, assuming that there is always a packet available to be sent to the destination from the network. the encryption delay ( BDenc )
the decryption delay ( BDdec )
Figure 3 depicts the application-to-application packet journey using the above notations. To sustain the end-to-end throughput required by an application, Bapp, with packet size D, we require:
min(BS ; BD ; Bw ) Bapp
(1)
We now compute the source and destination throughputs, BS and BD , as a function of the protocols' overhead and of the encryption and decryption throughput. We compute the time spent by a packet at the source and destination PC. Since at the source and at the destination we have one CPU that handles the protocols in all the communication layers including the encryption/decryption algorithms and assuming high loads, i.e., there is always a packet for transmission from the application layer (worst case computation) we obtain:
D = D + TS OH BS Benc 7
(2)
Zone for Offline Software Encryptor
Max. Value of Time Overhead per Packet (msec)
B enc
min
B enc
max
TS OH max
TS OH
This curve is achieved by Equation (2).
higher bps
TS OH
lower bps log Encryption/Decryption Throughput (bps) min
B enc
Zone for Inline Software Encryptor
Figure 4: Zone of inline security encryptor
D = D + TD OH BD Bdec Using equations (2) and (3) we obtain:
(3)
BS =
1 TSOH Bapp + Benc D
(4)
BD =
1 TDOH Bapp Bdec + D
(5)
1
1
The minimal encryption and decryption throughput to sustain the application throughput with the given system parameters is given by min = Benc min = Bdec
1
Bapp 1
Bapp
1
, TSDOH
(6)
1
(7)
, TDDOH
Using Equation (6) and (7) the maximum application throughput, assuming Bw Bapp, max is given by: Bapp 8
max = min[( Bapp
1 ); ( 1 1 TDOH )] TS OH Benc + D Bdec + D 1
(8)
max For given values of Bw , Bapp, Benc and D, the maximum value of TSOH , denoted by TSOH that will still provide the required application throughput is given by: max = D ( 1 , 1 ) TSOH (9) Bapp Benc max as a function of Benc for various values of TSOH and Figure 6 shows Figure 5 depicts Bapp max as a function of Benc for various values of Bapp , and D. We observe: TSOH The shaded area in Figure 4 depicts the design space. We provide a number of scenarios for determining some system design parameters. Scenario 1: For given Benc, D and TSOH , interactive applications can be admitted to the max (Equation (8)). network if their required throughput Bapp Bapp Example: for an inline encryptor with throughput of 4 Mbps, wireless LAN throughput of 2 Mbps, D = 64Bytes, and TSOH = 1msec, the inline encryptor can sustain applications of at most 454 Kbps. For example, if the current throughput of the selected encryption is 10 Mbps and the environment follows the second plot (TSOH = 1ms) shown in Figure 5, any multimedia application with required throughput lower than 480kbps can be securely supported by the software based inline encryptors. The candidate interactive applications are telephone-quality audio conference and low/medium quality video conferences (see Table 1). max . Scenario 2: For given Benc, Bapp and D choose a protocol stack such that TOH TOH max as a function of Benc for various values of Bapp and D = 256Bytes. Figure 6 depicts TOH We observe: max increases as Benc increases. As the time spent for encryption decreases, the TOH
remaining time overhead increases. max decreases since less time can be spent For increased application throughput Bapp, TOH on the computer.
4 Software Implementation and End-to-end Throughput Measurements In this section we introduce the software architecture that we have adopted for our inline security layer. We also present end-to-end throughput measurements for o -the-shelf applications that use our inline security layer. 9
Packet Size: 64Bytes 1000
Max. Bandwidth Requested by the Application (Kbps)
TSoh=0.5msec TSoh=1msec TSoh=10ms 800
600
400
200
0 1e+07
9e+06
8e+06
7e+06 6e+06 5e+06 4e+06 3e+06 Encryption/Decryption Bandwidth (bps)
2e+06
1e+06
0
max , versus encryption Figure 5: Maximum throughput requested by the application, Bapp throughput, Benc for 64 bytes packets. Packet Size: 256Bytes
3
Max. Value of Time Overhead per Packet (msec)
Bapp=750Kbps Bapp=1Mbps Bapp=1.54Mbps 2.5
2
1.5
1
0.5
0 1e+07
9e+06
8e+06
7e+06 6e+06 5e+06 4e+06 3e+06 Encryption/Decryption Bandwidth (bps)
2e+06
1e+06
0
max , versus encryption throughput, Figure 6: Maximum value of time overhead per packet, TSOH Benc, for 256 bytes packets.
10
4.1 Software Implementation We present our inline security implementation based on Microsoft's WinSock 2 Layered Service Provider Interface [12] and CryptoAPI [5]. CryptoAPI and Intel's Common Data Security Architecture (CDSA) [8] exemplify commercial implementations of cryptologic APIs which allow an application to use di erent encryption algorithms without a ecting application services. This exibility allows developers to readily modify encryption engines - either because of changes in technology or changes in level of trust. Clearly, APIs make security easier to implement and deploy. We have used Microsoft's CryptoAPI. We proceed with a description of Microsoft's CryptoAPI and Winsock2.
The services provided by CryptoAPI enable application developers to add cryptogra-
phy to their Win32 applications. Microsoft's design goals were to make crypto-enabled application development functional, exible and exportable to Windows-based developers. The architecture of CryptoAPI is modular: all of the actual cryptographic operations are performed by replaceable components known as cryptographic service providers (CSPs). Each CSP contains the core cryptographic algorithm and is written independently of the application so that an application can run with a variety of di erent CSPs. A CSP is a dynamic link library (DLL) which communicate with an application through the operating system. We have used the CryptoAPI sample code and Microsoft CryptoAPI Application Programming Guide from Microsoft's Internet Development Toolbox web site (http://www.microsoft.com/intdev/security/cryptoapi.htm). CryptoAPI includes the two most common bulk data encryption such as RC2 block cipher and RC4 stream cipher. The encryption keys are limited to 40 bits. For the creation of message digest, or hashes, CryptoAPI supports the most common hash algorithms MD2, MD5 and SHA. Winsock 2 [12] accommodates the notion of a layered protocol or layer service provider model. An example of such a layered protocol is a security layer. A layered protocol is one that implements only higher layer communication functions, while relying on an underlying transport stack for the actual exchange of data with the destination. A major task of the data transport of the Winsock 2 DLL is to serve as a sort of trac manager between service providers and the applications. By abstracting the service provider into a consistent DLL interface and performing this automatic trac routing function, Winsock 2 DLL allows applications to interact with a variety of providers without requiring the application to be aware of the divisions between providers, where di erent providers are installed. We implemented our software encryption algorithms using CryptoAPI [5] as crypto service functions in WinSock 2 Layered Service Provider that resides between the principal WinSock 2 DLL and the lower-level base transport provider (see Figure 7). 11
User Application 1
User Application 2
User Application 3
GUI
Standard Winsock 2.0 DLL Module
Upper Layered Service Provider Lower Layered Service Provider
Software Inline Secure Layered Service Provider DLL Module
Software Inline Security Layer
TCP(UDP)/IP
Device Driver
Wireless Network Interface Card
Figure 7: Software Inline Secure Layered Service Provider (ISLSP) Architecture At the source, each packet that is generated by the application is intercepted at the layer service provider, is encrypted using CryptoAPIs and is sent down to the base transport protocol. At the destination the packets that belong to this application are intercepted by the layer service provider, are decrypted using CryptoAPIs and are forwarded to the application. The proposed architecture has the following advantages:
we can use any o -the-shelf applications, i.e., the applications do not need to be modi ed and made aware of the fact that we use encryption techniques. we can use any o -the-shelf network interface card, i.e., we do not need to choose a network interface card that incorporates encryption capability either in hardware or software. easy upgrade of the encryption algorithms. Of course the proposed implementation may not be suitable for very high speed networks since the encryption throughput may hinder the advantages of a high speed channel. 12
Available CPU at Start (%) CASE 1 2
M2**
M1 *
M2**
Server
Client
Server
Client
98%
98%
0%
3
98% 0%
4
98% 0% 0%
111111111111111111111111111 000000000000000000000000000 111111111111111111111111111 000000000000000000000000000 11111111 00000000 11111111 00000000 00000 11111 00000 11111 11111 00000 11111 00000
**
00111100
(1.65Mbps)
(80%) (50%)
1.64Mbps
84-90% 20-25%
(920Kbps)
(0%) (73%)
401Kbps
0%
(810Kbps)
(90%)
205Kbps
(670Kbps)
203Kbps
0
*
Available CPU during Connection (%)
M1 *
1Mbps
70-83%
(0%)
85-90%
0%
(0%)
(0%)
0%
0%
2Mbps
Average End-to-End Throughput with Security
(without Security)
M1 : Pentium MMX 166MHz, 48M Main Memory, 512K L2 Cache, Windows 95 M2 : Pentium 90MHz, 32M Main Memory, 256K L2 Cache, Windows 95
Figure 8: FTP application average end-to-end throughput measurements with and without inline security.
4.2 End-to-end Experimental Results In this subsection we introduce experimental results of a number of applications such as FTPs and Microsoft's Media Player using AT&T's WaveLAN ISA Card. We experiment with a client-server con guration using computer con gurations: M1 (server) and M2 (client) with and without the inline security layer. According to WaveLAN speci cations this wireless LAN adapter sustains data rates of up to 2Mbps in 915 MHz ISM band. We performed the experiment in the semi-open oce environment with approximately three meters distance between the computers. The available CPU resources are measured by System Monitor program provided with Windows 95. Experiment 1: Figure 8 provides FTP throughput measurements versus di erent values of available CPU resources at the beginning of the experiment using WaveLAN. We used two FTP applications that provide built in throughput measurements: FTP built in Windows 95 and WSFTP Pro from Ipswitch, Inc.. We have obtained these measurements for di erent le sizes. We notice that in case both computers M1 and M2 have available CPU resources (Case 1) we obtain the same average end-to-end throughput of 1.65 Mbps which is dictated by the wireless LAN bandwidth. In Cases 2-4 M1 or M2 do not have enough available CPU resources and therefore we observe lower end-to-end average throughput in both cases, with and without the security layer. In Case 2 with the secure layer we obtain a lower throughput (401 Kbps) than without the security layer (920 Kbps) since encryption requires M1 CPU cycles which are already very highly utilized. Now the system bottleneck is at the encryption throughput which is dictated by available CPU resources at M1. Experiment 2: In this experiment we use Microsoft's Media Player. The throughput measurements are obtained by DU Meter software by Hagel Technologies Inc. Media Player application displays at the client (M2) movie les retrieved from the server (M1). As opposed 13
Available CPU at Start (%) CASE 1 2
M1
*
M2
Server
Client
98%
98%
0%
98%
Wireless LAN (WaveLAN)
1111111111 0000000000 1111111111 0000000000 000 111 000 111
(1500Kbps)
M1 *
M2**
Server
Client
(82%) (37%)
520Kbps
78%
59Kbps 60Kbps
0
001111 00
Available CPU during Connection (%)
**
0%
(0%) (88%) 0% 1Mbps
42%
2Mbps
Average End-to-End Throughput with Security
(without Security)
* M1 : Pentium MMX 166MHz, 48M Main Memory, 512K L2 Cache, Windows 95 ** M2 : Pentium 90MHz, 32M Main Memory, 256K L2 Cache, Windows 95
Figure 9: Microsoft's Media Player application average end-to-end throughput measurements with and without inline security.
AT&T WaveLAN ISA Card
With
Without
Secure LSP
Secure LSP
2 - 3 msec
2 - 3 msec
Table 2: Packet delay measurements with and without inline encryption. to FTP, this application requires signi cant CPU resources at the client to decompress the le. This fact is re ected in throughput measurements in Figure 9. As can be seen from Case 1 in Figure 9 which has the same initial conditions as Case 1 in Figure 8 when we use encryption, we observe a signi cant decrease in performance (520 Kbps). This is due to the fact that there is competition for resources (0 available CPU resources during the experiment) at the client M2 which slows down the decryption process. In Case 2 we observe that for both cases in which we invoke or do not invoke the security layer we obtain very low throughput of 60 Kbps. In this case the bottleneck is created at the server (M1) which performs very slow processing of the le. Experiment 3: In this experiment we test the existence of additional end-to-end packet delay introduced by our inline security layer for the WaveLAN wireless LAN. The delay measurements are performed by using a ping application tested with and without the inline security layer. As shown in Table 2, the results suggest that there is no visible degradation of delay when we use the inline security layer.
14
5 Summary In this paper we have investigated the use of software inline encryption in WLANs that carry multimedia applications. We measured the throughput of a number of bulk encryption algorithms such as RC2, RC4 and RSA for a number of computer systems con gurations and di erent loads. We have implemented the inline software encryption in the Layer Service Provider that integrates CryptoAPI's crypto service functions. Using o -the-shelf FTP, and Microsoft Media Player applications, we have measured the suitability of software inline security services in wireless LANs. We draw a number of conclusions: 1) software inline encryption throughput is a function of the available computer resources such as available CPU resources and CPU speed, 2) inline encryption can limit the application throughput, 3) an application can decrease the encryption throughput in case it requires signi cant computer resources such as decompression, and 4) in case sucient computer resources are available, software inline encryption is a suitable solution for wireless LANs that support multimedia applications. To determine the suitability of software based inline encryption for multimedia applications, we provided design guidelines that consider the multimedia application requested throughput, the packet size, the time overhead per packet for communication protocols processing, and the WLAN data rate. In cooperation with AIM Engineering Inc., the Multimedia Wireless LAN Laboratory at University of Massachusetts at Amherst is developing a prototype for WLANs that support multimedia applications [2]. Our next step is to test the encryption algorithm in a multimedia testbed.
15
References [1] S.H. Park, A. Ganz, and Z. Ganz, \Security Protocol for IEEE 802.11 Wireless Local Area Networks," to appear in ACM Mobile Networks Journal Special Issue on Wireless Local Area Networks. [2] A. Ganz, D. Awduche, J. Euh, I. Kim, E. Haslett, S.H. Park, A. Phonphoem, and Z. Ganz, \Multimedia Wireless LAN Prototype," Third Telecommunication R&D Conference in Massachusetts, Lowell, MA, Nov. 1997. [3] A. Aziz and W. Die, \Privacy and Authentication for Wireless Local Area Networks," IEEE Personal Communications, First Quarter, 1994, pp. 25-31. [4] B. Schneier, \Applied Cryptography," Wiley, 1996. [5] Microsoft, \CryptoAPI: Cryptography Application Programming Interface," Version 2.0, 1997. [6] R.L. Rivest, A. Shamir, and L.M. Adleman, \A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, v. 21, n. 2, Feb. 1978, pp. 120-126. [7] G.N. Cohen, B. Kamenel, and C.M. Kubic, \Security for Integrated IP-ATM/TacticalStrategic Networks," MILCOM 96, McLean, Virginia, Oct. 1996, Proceedings, pp. 456460. [8] Intel, \Common Data Security Architecture Speci cation," Draft Release 1.2, March 1997. [9] IEEE Standard 802.11 for Wireless LAN, IEEE P802.11, 1997. [10] R.E. Ziemer and W.H. Tranter, \Principles of Communications : Systems, Modulations, and Noise," Houghton Miin, 1995. [11] H. Imai, \Information Security Aspects of Spread Spectrum Systems," Proceedings of the Advances in Cryptography - ASIACRYPT '94, 1994, pp. 195-208. [12] Microsoft, \Windows Sockets 2 Service Provider Interface," Revision 2.2.2, Aug. 7, 1997.
16
Aura Ganz received her Ph.D. degree in Computer Science from Technion - Israel Institute
of Technology, Haifa. She is currently an Associate Professor in the Department of Electrical and Computer Enginering at University of Massachusetts, where she serves as the director of the Multimedia Wireless LAN Laboratory. Her research interests include design of multimedia wireless LANs, protocol and architecture design of wireless networks, security issues in wireless networks, modeling and performance evaluation. She served as co-chair of the 1997 Massachusetts R&D Telecommunication conference. She is editor of Computer Networks and ISDN Systems and has been active in the program committees for a number of conferences such as IEEE Infocom, IEEE Globecom and IEEE ICC. She serves as co-guest editor for ACM Mobile Networks and Applications Journal (Co-published by ACM and Baltzer Science Publishers) Special Issue on Wireless LANs. Se Hyun Park is currently a Research and Teaching Assistant with the Multimedia Wireless LAN Laboratory at the University of Massachusetts, Amherst, where he is pursuing the Ph.D. degree. He received the B.S. and M.S. degrees in electronic engineering from Chungang University, Seoul, Korea, in 1986 and 1988, respectively. From 1988 to 1994, he was a senior research engineer designing the VLSI chips in the eld of CDMA Viterbi Decoder, high-resolution sigma delta AD/DAC, ISDN interfaces, DSPs and high-speed voice modems at ETRI, Korea. His research interests include real-time security protocols and management for wireless LAN, mobile communications and heterogeneous networks, and high-speed integrated circuit design related to wireless communication, ATM and cryptography.
Zvi Ganz serves as the president of AIM Engineering Inc. which provides business solutions using Internet and Intranet technologies, engineers business processes and develops wireless network solutions for multimedia and data applications. Before joining AIM, he worked in management and engineering capacities for corporations like the Travelers Insurance Companies. He holds a PhD from the University of Massachusetts at Amherst in Industrial Engineering and Operations Research and MSc and BSc from the Technion in Israel in the areas of Industrial Engineering and Management.
17
