Security broker for multimedia wireless LANs

Security broker for multimedia wireless LANs

A. Ganza,* , S.H. Parkb, Z. Ganzc

aMultimedia Networks Laboratory, ECE Department, University of Massachusetts, Amherst, MA 01003, USAbEE School, Chung Ang University, Seoul, South Korea

cAIM Engineering Inc., USA

Abstract

To secure interactive multimedia applications in wireless LANs (WLANs), it is pertinent to implement a number of security services suchas authentication, key exchange and real-time encryption/decryption. WLANs, though, present a complex and challenging environment forimplementing such security services since these services may deplete the limited network resources and increase the burden of supportingquality of service for multimedia applications. Consequently, a broker is needed to mediate proper security considering inputs such as usersecurity requirements, user security literacy, available network resources, and security routines performance. In this paper we introduce aSecurity Broker that we have designed to fulfill these complex mediation needs. This broker is implemented in software and tested in awireless LAN testbed. The reported security broker design and implementation considers the wireless LAN environment as well as themultimedia applications’ Quality of Service requirements such as delay and throughput. We also introduce an Inline encryption/decryptionsoftware that encrypts/decrypts traffic on the fly.q 2000 Elsevier Science B.V. All rights reserved.

Keywords: Multimedia; Wireless LANs; Security broker

1. Introduction

Wireless local area networks (WLANs) are becoming aviable complementary solution to wired networks. WLANsprovide support for wireless residential and business needswhere cables are not cost-effective or prohibitive. SuchWLANs are expected to carry legacy data traffic as wellas video, audio and other multimedia applications. Trans-missions over the open air carry a significant security riskfor users since unauthorized users can intercept such trans-missions or malicious attackers can penetrate the WLAN byimpersonating legitimate users.

WLANs designers face a number of challenges dictatedby users’ requirements to transfer multimedia applica-tions that need predetermined Quality of Service supportas well as requirements for secured information delivery.These challenges are intensified by the WLAN poorchannel quality, dynamic network behavior, limited avail-able bandwidth and relatively low computational powerstations.

In this paper we introduce the concept of aSecurityBroker that mediates proper security services in a WLANenvironment. This broker provides security services such as

authentication, re-authentication during the session, real-time encryption that encrypts packets arriving from theapplication and heading to the network and real-timedecryption of traffic entering from the network. The real-time encryption/decryption service, denoted as the InlineSecurity Layer, is implemented in the Service LayerProvider [5] and uses Microsoft’s CryptoAPI [4]. Toease the mediation process between the user and thenetwork, we introduce the security services classifica-tion criteria and three security classes. Differentdesigners may reflect their users needs with differentclassifications.

The paper is organized as follows. In Section 2 we intro-duce the concept of the Security Broker, its security servicesand security classes. In Section 3 we present the softwareimplementation of the Security Broker and its graphical userinterface. Section 4 concludes the paper.

2. Security broker

The Security Broker design was guided by the followinggoals:

• easy to use by security-illiterate users as well as security-literate users;

• feasible to implement on a Windows operating systemplatform;

Computer Communications 23 (2000) 588–594

0140-3664/00/$ - see front matterq 2000 Elsevier Science B.V. All rights reserved.PII: S0140-3664(99)00211-X

www.elsevier.com/locate/comcom

* Corresponding author.E-mail addresses:[email protected] (A. Ganz),

[email protected] (Z. Ganz).

• can be used by commercial off-the-shelf standardapplications (i.e. do not need to require security awareapplications);

• possible to use standard encryption functions (e.g. asprovided by CryptoAPI);

• provides the necessary security functions such asauthentication and inline encryption;

• easy to expand and upgrade;• low cost of ownership;• independent of the wireless network interface cards.

A number of security mechanisms are required toeffectively manage resources and provide a suitable securityprocedure for each connection. We have developed andimplemented the following security features (see Fig. 1):

• Authenticationassures that the identity is not false.• Re-Authenticationprovides enhanced robustness during

an established session.• Encryption/Decryption (Confidentiality)secures that the

information is accessible only to authorized parties.• Integrity ensures that an intruder should not be able to

substitute a false message.• Graphic User Interface (GUI)provides ease of use.• Security Classesdefines the level of security according to

users’ requirements.

We differentiate between two main concepts: pre-establish-ing security and post-establishing security.

The pre-establishing security mechanisms are theAuthentication Protocolswe have published in Ref. [1].These protocols were designed for the WLAN charac-teristics such as limited bandwidth and limited

computational power. Our authentication protocolsprovide a unique session key and therefore reduce thetotal number of expensive computations such as publickey encryption.

The post-establishing security mechanisms we havedeveloped are theRe-Authentication Protocol[3] and theInline Security Layer[2]. Upon successful conclusion of theauthentication protocol, these two mechanisms are used toperform real-time encryption and re-authentication duringthe session. The goal of Re-Authentication Protocol is toobtain a low computational complexity authentication andkey exchange procedure that provides enhanced robustnessin face of active and passive security threats. The re-authen-tication that is executed during the session, is implementedby a one-way handshake protocol with the agreed-oncertificate parameters.

2.1. Security classes

2.1.1. Criteria for classificationThe main objective of theSecurity Brokeris to support

continuous security service for WLANs. This purposeshould be considered with respect to user types, applicationproperties, and terms of attacks. Therefore, we introduce anumber of criteria for classifying the security levels.

The first criterion is based on three main goals of crypto-graphy (confidentiality, integrity and authenticity) toprevent security attacks. We consider the followingcategories of attack:

• An unauthorized party gains access to an asset(interception). This is an attack onconfidentiality.

• An unauthorized party not only gains access to but

A. Ganz et al. / Computer Communications 23 (2000) 588–594 589

Fig. 1. Security mechanisms.

tampers with an asset (modification). This is an attack onintegrity.

• An unauthorized party inserts counterfeit objects into thesystem (fabrication). This is an attack onauthenticity.

Second, more advanced security aspects might beencountered to prevent passive and active attacks from adifferent angle by combining new security mechanisms ofthe security broker. These aspects might be engaged in thesecurity levels by looking at the generic types of attack.These attack types involve replay which implies thatintruders in the same service area actively capture a dataunit and subsequently retransmit to make an unauthorizedeffect. Another general type of replay attacks is the modifi-cation of message to convert the meaning of originalmessages.

Third, the classification of security needs to provide awide scope for various users. In the viewpoint of securitymatters, casual and security illiterate users are usually notaware of security risks. Since these types of users do notproperly understand the security services that ensureprotection of their information, they may be frustrated ifrequired to set up security parameters. This aspect is takeninto account in the security levels.

2.1.2. Proposed security classesIn this design we propose three security classes which

determine security services and which can be easily selectedby users. Other designs may consider different classes.Table 1 provides a summary of the security classes.

Most of security aspects such as confidentiality, integrityand authenticity have been considered in Class 3. This is thehighest security. This class is geared for security literateusers that have to make two decisions. First, the user mustdetermine if the security parameters are suitable for theapplication in particular circumstances. Second, even ifthe remote side is only capable of accepting agreed-onparameters, the sending user must decide whether these

parameters can be used for the requested session. Forexample, in our implementation, the security servicespecifications of Class 3 (Table 1) recommend the 160-bitSHA, 128-bit MD5 withauthentication protocol, re-authen-tication protocoland inline security layer(bulk encryptionwith RC4). However, in the viewpoint of brute-force attack,there is a need to replace the popular MD5 with a hashfunction that has a longer hash code.

For Class 2, the advanced security service such as “Re-Authentication Protocol” is optionally supported pendingusers’ request. This option might reduce the complexity ofthe security procedure for users, but may be vulnerable tothe time-based information analysis. We have implementedin Class 2 two types of hash functions MD2 and MD4. Thisclass takes into account the most important security aspectsincluding the service againstReplaywith the pre-establish-ing and the post-establishing mechanisms.

Class 1 provides instant access to security illiterate usersthat do not request any encryption services. This class mayestablish a wireless connection using weak securityservices, since both post-establishing mechanisms (re-authentication protocoland inline security layer) areoptional. Therefore, if the quick connection is the mainreason, the security broker allows the user to perform anyapplications just based on the initial authenticity.

2.2. CORBA discussion

CORBA (Common Object Request Broker Architecture),ORB (Object Request Broker) provides interoperabilitybetween objects. Multiple-inheritance among static anddynamic request mechanisms can be managed by CORBAInterface Definition Language (IDL). In the viewpoint ofobject request method, the concept of Security Broker cancover all types of ORB. Especially, the agreed-on securityparameters for both pre-establishing and post-establishingsecurity procedures makes it possible to create a new targetobject shared by clients and servers. This new target object

A. Ganz et al. / Computer Communications 23 (2000) 588–594590

Table 1Security classes

Class 1 Class 2 Class 3

Security aspectsInterception (confidentiality) Possible or difficult Difficult Very difficultModification (integrity) Possible Difficult Very difficultFabrication (authenticity) Possible Difficult Very difficultAdvanced security aspectsReplay a data unit Possible No NoPropertiesEase-of-adaptation Easy Moderate HardUser type (security aspect skill) Novice Trained ExpertPerformance High or moderate Moderate ModerateSecurity servicesInitial authentication protocol Yes Yes YesBulk encryption with secure LSP Yes or no Yes YesOptions of hash functions None or MD2 MD2, MD4 MD5, ShaRe-authentication protocol Optional Optional Yes

incorporates the Security Broker Software Architecture thatruns as the Implementation Skeleton of CORBA providingthe interface through which a method acquires a securerequest. Therefore, one of the merits of implementing theSecurity Broker is to support various secure utilities that canbe readily accessed to those services of a CORBA-compliant product. Table 2 implies that the basic conceptof Security Broker’s skeleton meets CORBA specifications.If more functions of the Security Broker, related to ORBnetwork interfaces, are developed, the Security Broker willshare system and network resources of local and remotepeers, and will dynamically determine proper objectoperation for any off-the-shelf applications and networkinterface card.

3. Software implementation

TheSecurity Brokeris implemented in software and runson the Microsoft’s Windows operating system. Thefunctions ofSecurity Brokerare implemented in both theapplication layer and the service layer provider above TCP/IP. Fig. 2 shows the entire architecture of the softwaresecurity broker. The security broker invokes the securityservices through theGraphic User Interfaces.

The authentication and re-authentication protocols areimplemented at the application layer with shared memorybetween these applications and the inline encryptionmodule.

The software implementation of the inline security layer

was described in detail in Ref. [2]. For completeness of thepaper we briefly present the inline security layer softwareimplementation.

We implemented our software encryption algorithmsusing CryptoAPI [4] as crypto service functions in WinSock2 Layered Service Provider that resides between theprincipal WinSock 2 DLL and the lower-level base transportprovider (see Fig. 2). At the source, each packet that isgenerated by the application is intercepted at the layerservice provider, is encrypted using CryptoAPIs and issent down to the base transport protocol. At the destinationthe packets that belong to this application are intercepted bythe layer service provider, are decrypted using CryptoAPIsand are forwarded to the application.

The proposed architecture has the following advantages:

• we can use any off-the-shelf applications, i.e. the appli-cations do not need to be modified and be made aware ofthe fact that we use encryption techniques;

• we can use any off-the-shelf network interface card, i.e.we do not need to choose a network interface card thatincorporates encryption capability either in hardware orsoftware;

• easy to upgrade the encryption algorithms.

Of course the proposed implementation may not be suitablefor very high speed networks since the encryption through-put may hinder the advantages of a high speed channel.

3.1. Graphic user interfaces (GUIs)

In this subsection, we present the GUIs of the securitymechanisms (Authentication Protocol, Re-AuthenticationProtocol and Inline Security Layer). The main objectiveof employing a graphic user interface is to resolve conflictsbetween complex security procedures and ease of use. AllGUIs are programmed in C11 for Windows 95 environments.Each GUI follows the security services that we described.

The Security Broker GUImain window is presented inFig. 3. The security broker GUI supports three mainfunctions: set the client server role, set the class level andsecurity parameters, and open the gate of the authenticationprotocol. We describe next the GUI for each security service.

3.1.1. Authentication protocolTheAuthentication ProtocolGUI is shown in Fig. 4. The

GUI consists of graphical and textual inputs as well as anoutput message box. The user needs to choosereceive modeor send modebefore starting the authentication protocol. IfSend Modewas chosen, the IP address of the remote sidemust be specified. The agreed-on initialSession Keyshouldalso be provided. TheMessage-Boxdisplays the progress ofthe authentication protocol.

The Authentication protocoluses a three way handshakeprocedure to validate the remote side. This protocol isperformed with shared information such as a session key, anencryption type, a hash function type and a class level. The


Table 2CORBA comparison

CORBA components Related components of security broker

Dynamic invocation Re-authentication protocolAdaptive time interval due to securelevel requirementsDynamic agreed-on-re-authenticationnumber to construct secure objectsestablishing unique ORB operation foreach connection (in the viewpoint ofQoS-based object operation)

Implementation skeleton Security broker software architectureThis skeleton provides the Interfacebetween the upper layer (WinSock 2.0)and the lower layer (TCP/IP) andreceives the request to present theinline secure object creationSecurity protocol mechanismsContains the interface providing clientand system based secure ORB

Object adapter Inline security layerActivates bulk encryption modulebased on an end-to-end agreementKey management moduleProvides particular key distribution forvarious objects employing differentsecurity classes

client sidewill acceptand use the security parametersprovidedby the server side. If this obligation is satisfied and the properauthentication protocol is executed by both sides, theMessageBoxof the authentication protocolGUI displays in the messagebox ‘AUTHENTICATION: OK’.

If the authentication protocol cannot verify the remoteside, theMessage Boxof the authentication protocol GUIdisplays in the message box both the failed step and themessage ‘AUTHENTICATION FAILED!!!’. Furthermore,this message box displays other errors caused by inappropri-ate TCP or socket connections.

3.1.2. Re-authentication protocolUpon successful conclusion of the authentication protocol,

theRe-Authentication Protocol, published by us in Ref. [3],can be executed. For the ‘Client Side’, the GUI of the Re-Authentication Protocol (Fig. 5) is invoked. This GUIcontains three main textual inputs to define the re-authenti-cation parameters. These inputs are for setting the number oftimes we want to execute the re-authentication procedureand time intervals between consecutive re-authenticationexecutions.

The main types of message boxes for the re-authentication


Fig. 2. Security broker software architecture.

protocol are ‘Re-Authentication SUCCESS!!’ and ‘WARN-ING!’. In case of successful re-authentication, the messagebox shows the number of times we wish to perform the re-authentication procedure.

3.2. Test tools

The first tool is the Windows Sockets (WinSock) Con-figuration Tool. This tool is included in the WinSock 2development kits and called ‘Sporder’. The main functionof this tool is to display the installation of WinSock 2Service Provider. We use this tool to show the status of

our Inline Security Layer(or Security Layered ServiceProvider (SLSP)).

EtherPeek developed by the AG Group, Inc. is a networkand protocol analyzer. EtherPeek monitors (or snoops) thenetwork data and helps us determine the correctness andperformance of the protocols we have developed. Thisnetwork tool can be viewed as a virtual intruder.

4. Conclusions

We have developed and implemented a Security Brokerin the Windows platform that mediates and simplifies thedaunting task of coordinating network resources, securityneeds and executed applications. The inline encryptionwas implemented in software in the Layer Service Providerand integrates CryptoAPI’s crypto service functions.

The proposed architecture has the following advantages:

• we can use any off-the-shelf applications, i.e. the appli-cations do not need to be modified and be made aware ofthe fact that we use encryption techniques;

• we can use any off-the-shelf network interface card, i.e.we do not need to choose a network interface card thatincorporates encryption capability either in hardware orsoftware;

• easy to upgrade the encryption algorithms.

References

[1] S.H. Park, A. Ganz, Z. Ganz, Security protocol for IEEE 802.11wireless local area networks, ACM Mobile Networks andApplications Journal (Special Issue on Wireless LANs) 3 (1998)237–246.

[2] A. Ganz, S.H. Park, Z. Ganz, Experimental results and designguidelines for real-time software encryption in multimedia wirelessLANs, Special Issue on Multimedia Collaborative Environments ofCluster Computing, to appear.


Fig. 3. Security broker graphic user interface.

Fig. 4. Authentication protocol graphic user interface.

Fig. 5. Re-authentication protocol graphic user interface.

[3] S.H. Park, A. Ganz, Z. Ganz, Robust re-authentication and keyexchange protocol for IEEE 802.11 wireless LANs, IEEE MilitaryCommunications Conference, October 1998.

[4] Microsoft, CryptoAPI: Cryptography Application ProgrammingInterface, Version 2.0, 1997.

[5] Microsoft, Windows Sockets 2 Service Provider Interface, Revision2.2.2, 7 August 1997.


Se Hyun Park received the BS and MS degrees in electronics engineer-ing from Chung Ang University, Seoul, South Korea, in 1986 and 1988,respectively, and the PhD from the University of Massachusetts,Amherst, in 1998, in electrical and computer engineering. From 1988to 1999, he was a senior research staff at ETRI, South Korea. He iscurrently an Assistant Professor of School of Electrical and ElectronicsEngineering at Chung Ang University, where he has established theCipher Internet-World Lab. His research interests include multicastsecurity protocols and constructions for Wireless Internet and VirtualPrivate Network.

Aura Ganz is an Associate Professor at the University of Massachusettsat Amherst and director of the Multimedia Networking Laboratory. Sheis also a co-founder of EnrichNet Inc., a University spin-off thatprovides QoS LAN solutions. She received her BSc, MSc and PhDfrom the Technion in Israel. She has been organizer and invitedspeaker for numerous conferences such as general co-chair of theMassachusetts 3rd Annual R&D Conference, keynote speaker at theNSF sponsored workshop in Mobile Computing, Personal and LocalWireless Network Solutions conference and Motorola Wireless FuturesForum.

Dr. Zvi Ganz is EnrichNet‘s VP Technology and Research, Founder,and Chairman of the Board of Directors. Zvi has worked and consultedin Process engineering and Operations Management for more than 15years. He also worked for the Travelers insurance companies as adirector for process engineering and taught at Clark University.Prior positions included Director for Infrastructure Capital Invest-ments for RAFAEL in Israel and management of the IndustrialEngineering Department in the Israeli Navy Logistics Division. HisPh.D. is in Industrial Engineering and Operations Research from theUniversity of Massachusetts. His MSc and BA are in Management andIndustrial Engineering from the Technion in Israel.

Documents

Security broker for multimedia wireless LANs