This is the author version of an article published as: Alzaid, Hani and Abanmi, Suhail and Kanhere, Salil

and Chou, Chun Tung (2006) Detecting Wormhole Attacks in Wireless Sensor Networks. Technical Report, Computer Science and Engineering School - UNSW, The Network Research Laboratory - UNSW. Copyright 2006 (The authors) Accessed from http://eprints.qut.edu.au

DetectingWormholeAttacksin WirelessSensorNetworks

Abstract
The development of wireless sensor devices in terms of low power and inexpensive datarelaying has been partially achieved because of the rapid progress in integrated circuits and radio transceiver designs and device technology. Due to these achievements,thewirelesssensordevicesareabletogatherinformation,processthem ifrequiredandsendthemtothenextsensordevice.Thecapturedinformationmightbe regardingtemperature,pressureorlight,andsoon. In some applications, these wireless sensor devices must be secured, especially when thecapturedinformationisvaluable,sensitiveorformilitaryusage.Wormholeattacks areasignificanttypeofsecurityattackswhichcandamagethewirelesssensornetworks if they go undetected. Unfortunately, these attacks are still possible, even if the communication is secured. The wormhole attack records packets at one point of the network,passesthemintoanothernodeandthislastnodeinjectsthepacketintothe wirelesssensornetworkagain. The main objective of this project is to build an actual test bed to simulate the wormhole attack on a wireless sensor network and to implement one of the current solutionswhichiscalledpacketleashestoprotectsensornetworksfromthesekindsof attacks.ThisprojectstestbedconsistsofacombinationofMica2motesandStargate sensordevices.

TableofContents
Introduction 1 Background 7 9 1.1 MICA2Motes..... 9 1.1.1 1.1.2 MICA2MotesFeatures.... 9 HardwareLayouts... 10

1.1.3 SoftwareEnvironment.... 11 1.2 StargateSensorDevices..... 12 1.2.1 1.2.2 1.2.3 StargateFeatures. 12 HardwareLayouts... 13 SoftwareEnvironment.... 16

1.3 Summary... 16 2 SettinguptheEnvironment 17

2.1 SettingupthePC.... 17 2.1.1 2.1.2 TinyOSConfigurationStepsunderWindows2000/XP.. 18 TinyOSConfigurationStepsunderLinux(Redhat9)... 19

2.1.3 armlinuxgccConfigurationSteps... 21 2.1.4 2.1.5 SettinguptheUSBtoSerialCable 22 Difficulties.. 22

2.2 SettingupMICA2Motes.. 22 2.3 SettinguptheStargate.... 24 2.3.1 2.3.2 ConfigurethePC 24 ConfiguretheStargate..... 25

2.4 Summary.... 26

 3 BuildingtheTestBed 27

3.1 DesignoftheTestBed.......27 3.2 TheAODVAlgorithm.29 3.3 TheImplementationoftheTestBed.30 3.3.1 3.3.2 3.3.3 TheAODVProgram....31 TheTOSBaseProgram........33 TheStargatePrograms....34

3.4 DemonstrationoftheTestBed. 35 3.5 Thevisibilityofthewormholeattack36 3.6 WormholeAttackSolution...37 3.7 TheImplementationoftheSolution..39 3.8 Difficulties.40 3.9 Summary.................................41 Conclusionandfuturework References 42 43

 ListofFigures
1.1 MICA2Motewithoutanantenna... 10 1.2 MIB510SerialInterfaceBoard.. 11 1.3 ProcessorBoard(TopView) 14 1.4 ProcessorBoard(BottomView).. 14 1.5 DaughterCard(TopView)... 15 1.6 DaughterCard(BottomView) 15 3.1WirelessSensorNetworkDesign.. 28 3.2ProjectDesign............................... 39

ListofTables
3.1 PacketFormat.............................. 31 3.2 RoutingTable............................... 31

Introduction
The capability of combining sensing, processing, and communicating wirelessly have been enabled by the advances in microelectronics fabrication. The main objectives of deploying the Wireless Sensor Network (WSN) are remote monitoring and gathering information[4].AWirelessSensorNetwork(WSN)iscomposedofagroupoftinysensor devices which can be networked together and deployed in a wide spectrum of applicationsinvariousmilitaryandcivildomains. However, many applications run in untrustworthy environments and require secure communications such as emergency response operations, military or police networks, andsafetycriticalbusinessoperations.Forexample,inemergencyresponseoperations such as after a natural disaster like a flood, tornado, or earthquake, a wireless sensor networkcouldbeusedforrealtimefeedback.Therefore,theemergencyrescuewillrely onthatparticulartypeofnetwork[5]. Wireless sensor networks are vulnerable to several attacks; consequently, securing WSNsisamajorchallenge.Oneofthemajorattackstothistypeofnetworksisknown asaWormholeattack.Inthisattack,anattackerrecordsapacketorbitsofthepacketat onelocationinthenetwork,tunnelsthepackettoanotherlocation,andreplaysitthere. Thewormholeattackplacestheattackersinaverypowerfulposition,allowingthemto gain unauthorized access, disrupt routing, or perform a DenialofService (DoS) attack [5]. Inthisproject,anactualtestbedhasbeenbuilttodemonstratethewormholeattackin a wireless sensor network. This network consists of several Mica2 motes and two Stargatesensordevices.Todetectthewormholeattack,therearesomecontemporary techniquestodothat.Oneofthesetechniqueswillbeimplementedinthisproject. This report is composed of three chapters. In Chapter 1, an introduction about Mica2 motesandStargatesensordeviceswillbegiven.Next,Chapter2isadescriptionofthe

designing and building of the test bed, and it will explain the implementation of the solution.Finally,technicaldetailsaboutsettingupthistestbedandrelateddevicessuch asaPC,Mica2motes,andStargatesensordeviceswillbepresentedinChapter3.

Chapter1
Background
It is more important to have some background information about the wireless sensor devices prior to building a test bed for a group of them. Consequently, a short description of the sensor devices that were used in this test bed will be given in advance. Section 1.1 will explain all related and necessary information about Mica2 motes.Afterthat,theothersensordeviceswhichareknownasStargateareexplained inSection1.2.Finally,abriefsummaryconcludesthischapterinSection1.3.

1.1 MICA2Motes
DifferentmodelsofMoteshavebeenproducedbyCrossbow,andeachofthesemodels has different features. These models are MICAz, MICA2, MICA2DOT, and MICA, all of whichexceptMICA2arebeyondthescopeofthisproject.MICA2Moteshavebeenused in this project to build the test bed. Therefore, the features, hardware layouts, and softwareenvironmentofMICA2Moteswillbedescribedinthefollowingsubsections.

1.1.1 MICA2MotesFeatures
The MICA2 Motes come in three types according to their RF frequency band: the MPR400 (915 MHz), MPR410 (433 MHz), and MPR420 (315 MHz). The Motes use the ChipconCC1000,FSKmodulatedradio.AlltypesutilizeapowerfulAtmega128Lmicro controller and a frequency tunable radio with extended range. The MPR4x0 and MPR5x0radiosarecompatibleandcancommunicatewitheachother.(Thex=0,1,or2 dependingonthetype/frequencyband)[1].Figure1.1showsasampleoftheMICA2 Mote.

Figure 1.1: MICA2 Mote without an antenna [1].

TheMICA2Motescanbepoweredthrougheithertheexternalpowerconnecterorby usingtwoAAbatteries.

1.1.2 HardwareLayouts
The MICA2 Mote can be reprogrammed using an external board called the MIB510 Serial Interface Board. This board is a multipurpose interface board used with the MICA, MICA2, MICAz, and MICA2DOT Motes family. It supplies power to the devices through an external power adapter option, and provides an interface for an RS232 Mote serial port and reprogramming port [1]. Figure 1.2 shows an example of the MIB510serialinterfaceboard.

10

Figure 1.2: MIB510 Serial Interface Board [1].

TheMIB510serialinterfaceboardisusedtoprogramtheMICA2Mote.Thisboardhas the PC connection capability using the RS232 serial port. Programming the Motes requiresaspecialoperatingsystemcalledTinyOS,whichshouldbeinstalledonthePC.

1.1.3 SoftwareEnvironment
MICA2Motesuseaspecialoperatingsystem,whichisusedforwirelesssensornodes, called TinyOS. This operating system is an opensource eventdriven operating system designed for wireless embedded sensor networks. It features a componentbased architecturewhichenablesrapidinnovationandimplementation,whileminimizingcode sizeasrequiredbytheseverememoryconstraintsinherentinsensornetworks.TinyOS's componentlibraryincludesnetworkprotocols,distributedservices,sensordrivers,and data acquisition tools, all of which can be used as is, or can be further refined for a customapplication.TinyOS'seventdrivenexecutionmodelenablesfinegrainedpower management,yetallowstheschedulingflexibilitymadenecessarybytheunpredictable nature of wireless communication and physical world interfaces. It has been implemented in a language called nesC. This language is an extension to C which has beendesignedtoembodythestructuringconceptsandexecutionmodelofTinyOS[1]. ProgramswritteninnesClanguagearebuiltoutofcomponentswhicharewiredtoform

11

entireprograms.Eachcomponenthasinterfaceswhichcanprovideitsfunctionalityto otherusers.

1.2 StargateSensorDevices
Stargate is a powerful single board computer with enhanced communications and sensor signal processing capabilities. Stargate uses Intels latest generation 400 MHz XScaleprocessor(PXA255). ThisproductwasdesignedwithinIntelsUbiquitousComputingResearchProgram,and islicensedtoCrossbowforproduction.Inadditiontotraditionalsingleboardcomputer applications, Stargate directly supports applications around Intels OpenSource Robotics initiative as well as TinyOS based Wireless Sensor Networks and Smart Dust Technology[2].

The features, hardware layouts, and software environment of Stargate sensor devices willbedescribedinthefollowingsubsections.

1.2.1 StargateFeatures
TheStargatesensordeviceusedinthistestbedhasvariousfeatureswhichcanalsobe usedindifferentapplications.Thesefeaturesareasfollows[2]: Smallformfactor(3.52.5) 32bit,400MHzIntelPXA255XScaleRISCprocessor. SA1111StrongARMcompanionchipformultipleI/Oaccess. 32MBofIntelStrataFlash. 64MBofSDRAM. 1TypeIICompactFlash+slot. 1PCMCIAlot Resetbutton Realtimeclock Lithiumionbatteryoption MICA2andMICAzMotecapability,GPIO/SSPandothersignalsvia51pin expansionconnector I2Cconnectorviaaninstallableheader 12

51pindaughtercardinterfacefor: WiredEthernetviaa10BaseTEthernetport HostUSB JTAGport ExternalA/Cpowersupplyadapter RS232serialportviaDB9connector

The main feature that has been used extensively in the test bed is the Compact Flash slot.StargatehasthecapabilitytohaveaWiFiCompactFlashcard.Anotherexpansion inStargateistheMICA2Moteconnector,whichallowsStargatetocommunicatewith other MICA2 Motes through the radio channel. Stargate consists of two hardware pieces: the processor board and the daughter card. These pieces will be explained in detailinthefollowingsubsection.

1.2.2 HardwareLayouts
Asmentionedinthepreviously,Stargateconsistsoftwohardwarepieces:aprocessor boardandadaughterboard.Eachofthesepieceswillbedescribedinthissubsection. TheprocessingboardasshowninFigure1.1andFigure1.2showsallthemainbuttons andslots.Figure1.1showsthetopviewoftheprocessingboard,anditisclearfromthis view that Stargate has two slots. These slots can be used to communicate with other devices.ThefirstslotisusedtoallowStargatetocommunicatewithotherMICA2Motes byconnectingaMICA2MoteovertheStargate.ThesecondslotisusedtoconnectWiFi CompactFlashcardtotheStargatedevice,whichallowsittocommunicatethroughthe standard802.11aor802.11bwirelessprotocols.

13

Figure 1.3: Processor Board (Top View) [2].

Figure1.2showsthebottomviewoftheprocessorboard.ThereisaPCMCIAslotwhich could be used to connect a PCMCIA WiFi card. The daughter card, which will be explainedlater,canbeconnectedtotheprocessorboardthroughaconnectorshownin Figure1.2.

Figure 1.4: Processor Board (Bottom View) [2].

The processor board gets its power from the daughter card. The daughter card has a powersupplyjackasitappearsinFigure1.3andFigure1.4.Furthermore,thedaughter

14

cardallowstheusertocommunicatewithStargateusingdifferenttypesofinterfaces. TherearethreedifferentwaystocommunicatewithStargate.Thefirstoneisbyusing theSerialRS232Connecter.ThesecondwayisviatheRJ45EthernetPortandthethird oneusestheUSBPort.Alltheseinterfacesgivetheabilitytocontroloruploadprograms totheStargate.

Figure 1.5: Daughter Card (Top View) [2]

Figure 1.6: Daughter Card (Bottom View) [2].

All switch buttons in the Stargate processor board and daughter card have to be switched on before using Stargate. There are two switch buttons, S1 and S2, in the processorboard.Thethirdswitchbutton,S3,islocatedinthedaughtercard.

15

Stargates software platform is an embedded Linux operating system kernel. All information regarding the software environment of the Stargate is described in subsection1.2.3.

1.2.3 SoftwareEnvironment
As mentioned, Stargate uses an embedded Linux operating system kernel, which is installed on the processing board of the Stargate. There is also additional software shipped with the Stargate development platform, which could be used to enable programdevelopment. StargatesplatformprovidesthecapabilityofinstallingprogramswritteninClanguage. Thedevelopercancontrolvariousfunctionsin StargatebyusingClanguageprograms aftercompilingandinstallingthem.

1.3 Summary
The main objective of this project is to build an actual test bed of a group of sensor nodes, which includes MICA2 motes and Stargate, in order to simulate the wormhole attack. In addition, one of the wormhole attack deterrent solutions has been implementedinthistestbed.

16

Chapter2 SettinguptheEnvironment
As mentioned, the test bed in this project consists of two different wireless sensor devices. Before programming these devices, it is necessary to configure a number of settingstoenableapropercommunicationmethodbetweenthemandthePC. Inthischapter,adetailedexplanationwillbegivenaboutsettinguptheenvironmentof thePCandwirelesssensordevicesaswellashowtoinitializeaconnectionbetweenthe PC and these sensor devices. Section 2.1 explains the necessary steps to set up the connection between the PC and the sensor devices. Then, a short description about installingtherequiredprograminMICA2moteswillbegiveninSection2.2.Afterthat, settinguptheenvironmentoftheStargatesensordeviceswillbeillustratedinSection 2.3.Finally,Section2.4willconcludethischapter.

2.1SettingupthePC
As mentioned, the TinyOS platform needs to be installed in the PC to enable it to communicateanduploadprogramsintoMICA2motes.Itisnecessarytoperformsome stepsaccordingtothetypeoftheoperatingsysteminthePCtobeabletocompileand install programs in the sensor devices. There are some specific steps under Windows 2000/XPwhichwillbeexplainedinsubsection2.1.1.UnderLinux,especiallyRedhat9, thereareotherstepswhichwillbeexplainedinsubsection2.1.2. However,thereisnoneedtoinstallaspecialplatforminthePCtocommunicatewith Stargate.ItneedsaspecialCcompilertocompileandinstallanyprogramintoStargate. Thiscompileriscalledarmlinuxgccandthestepsofdoingthatwillbeexplainedlater.

17

2.1.1 TinyOSConfigurationStepsunderWindows2000/XP
To enable a PC with Windows 2000/XP to communicate with MICA2 motes, it is necessarytoperformthefollowingsteps[8]:

DownloadandinstallSun's1.4JDK,fromhttp://java.sun.com Downloadthecygwinpackagefrom http://webs.cs.berkeley.edu/tos/dist1.1.0/tools/windows/tinyoscygwin1.1.zip unzipthis,andruntheinstall.batscript

DownloadandinstallSun'sjavax.commpackagefrom http://java.sun.com/products/javacomm/ andinstallitasfollows(instructionsforacygwinshell),assumingyouinstall JDK in c:\Program Files\jdk:

o o o o

unzip javacomm20-win32.zip cd commapi cp win32com.dll "c:\Program Files\jdk\jre\bin" chmod 755 "c:\Program Files\jdk\jre\bin\win32com.dll"

o o

cp comm.jar "c:\Program Files\jdk\jre\lib\ext" cp javax.comm.properties "c:\Program Files\jdk\jre\lib"

IfyouaregoingtousetheInstallshieldsetuptoinstallTinyOSinthefuture,dothisas well:
o

cp javax.comm.properties "c:\Program Files\jdk\lib"

Downloadgraphvizfrom http://webs.cs.berkeley.edu/tos/dist-1.1.0/tools/windows/graphviz-1.10.exe andinstallitbyexecutingit.

18

Downloadthefollowingrpmsfrom http://webs.cs.berkeley.edu/tos/dist1.1.0/tools/windows avarice-2.0.20030825cvs-1w.cygwin.i386.rpm avr-binutils-2.13.2.1-1w.cygwin.i386.rpm avr-gcc-3.3tinyos-1w.cygwin.i386.rpm avr-insight-pre6.0cvs.tinyos-1w.cygwin.i386.rpm avr-libc-20030512cvs-1w.cygwin.i386.rpm Andfrom http://webs.cs.berkeley.edu/tos/dist-1.1.0/tinyos/windows nesc-1.1-1w.cygwin.i386.rpm tinyos-tools-1.1.0-1.cygwin.i386.rpm tinyos-1.1.0-1.cygwin.noarch.rpm

Install the rpms with "rpm ignoreos ivh *.rpm" in the directory where the files are saved(inacygwinshell).Thiswilltakeawhile(theTinyOSpackageinstallationincludes compilingthejavacode).TinyOSisinstalledin/opt/tinyos1.x.

Checkthedocumentationin/opt/tinyos1.x/doc/index.htmlformore information.

In addition, the MICA2 motes kit from Crossbow comes with a CD which contains the TinyOSsoftwarewhichisreadytobeinstalledinthePC.

2.1.2TinyOSConfigurationStepsunderLinux(Redhat9)
IfthePChasLinux(Redhat9),thenthefollowingstepsshouldbefollowed[8]:

DownloadandinstallIBMs1.4JDKandjavax.commrpms,currentlyat https://www6.software.ibm.com/dl/lxdk/lxdk-p (http://www.ibm.com/developerworks/java/jdk/ isagoodstartingpointifthislink changes)

19

o o o

selecttheIBMSDKfor32bitxSeries(Intelcompatible) youneedtoregister downloadtheIBMJava2SDKandIBMJava2JAVACOMMrpms,andinstall them

Downloadthefollowingrpmsfrom http://webs.cs.berkeley.edu/tos/dist1.1.0/tools/linux avarice-2.0.20030825cvs-1.i386.rpm avr-binutils-2.13.2.1-1.i386.rpm avr-gcc-3.3tinyos-1.i386.rpm avr-insight-pre6.0cvs.tinyos-1.3.i386.rpm avr-libc-20030512cvs-1.i386.rpm graphviz-1.10-1.i386.rpm Andfrom http://webs.cs.berkeley.edu/tos/dist-1.1.0/tinyos/linux nesc-1.1-1.i386.rpm tinyos-tools-1.1.0-1.i386.rpm andinstallthemwith"rpmivh*.rpm"inthedirectorywhereyousavedthefiles.

Changethepermissionson/dev/ttyS<n>to666forallserialportsyouwilluse withTinyOS.

Changethepermissionon/dev/parport0to666ifyouplantoprogrammotesvia theparallelport(thiswillallowuisptoaccesstheport).

DownloadtheTinyOSrpmfrom http://webs.cs.berkeley.edu/tos/dist-1.1.0/tinyos/linux/tinyos-1.1.0-1.noarch.rpm installthisrpmwith rpmivhprefixTINYOSDIRtinyos1.1.01.noarch.rpm cdTINYOSDIR;chownRUSER.GROUPtinyos1.x

20

ThiswillinstallTinyOSinTINYOSDIR/tinyos1.x),foruserUSER(withgroupGROUP). Installingthisrpmwilltakeawhileasthejavacodewillbecompiled.

Checkthedocumentationin/opt/tinyos1.x/doc/index.htmlformore information.

2.1.3 armlinuxgccConfigurationSteps
The PC that has been used in this project has the Linux (Redhat 9) operating system. Therefore, the armlinuxgcc compiler has been installed in the PC to enable it to compileanyprogramwritteninCandexecuteitinStargate.TheCDROMshippedwith theStargateProcessorBoard,containsthearmlinuxgcccompiler,version3.3.2,forthe LinuxHostplatformonly.

These tools may also be obtained directly from the following link http://gpe.handhelds.org/pub/linux/arm/toolchain/. The zipped toolchain archive file, cross3.3.2.tar.gz, shipped with the CDROM, is available at the following directory: <CDROM>/tools/ .

ToinstallthesetoolsonyourLinuxHostDevelopmentmachine,loginasroot.Changeto therootdirectory: cd / . ExtractthezippedarchivefilesandinstallthemonyourHost machinebyenteringthefollowingcommand: tar -xvfz <CDROM>/tools/arm-linux-gcc-3.3.2.tar.gz

This command will install the tools on your Host machine in the /usr/local/arm/3.3.2/ directory. Add the path to the directory containing the binaries for the tools in your environmentvariablePATH.Thefollowingcommandcanbeusedonthebashshell: export PATH=$PATH:/usr/local/arm/3.3.2/bin

21

Alternatively, this line can be added in your shell configuration file, such as $HOME/.bashrc forbashshell.Moredetailsofperformingthisinstallationcanbefound in[1].

2.1.4 SettinguptheUSBtoSerialCable
Inordertocommunicatewithsensordevices,itisnecessarytosetuptheserialcableor USBtoserialcableconnection.ThePCthathasbeenusedinthisprojectdoesnothavea serialport,butithasaUSBport.Therefore,aUSBtoSerialcableisneededtoestablish thecommunicationbetweenthePCandthesensordevices.Tosetupthiskindofcable underLinux,performthefollowingcommandsasarootuser: root# chmod 666 /dev/tty* root# insmod usbserial root# ln sf /dev/ttyUSB0 /dev/ttyS0

2.1.5Difficulties
Therewereanumberofdifficultiesduringthisproject.ThePCcouldnotcommunicate with the sensor devices using the USB to Serial cable. The operating system was changedfromWindowsXPtoRedhatandthisdidnotsolvetheproblem.Finally,itwas found that the USB to Serial cable brand is not supported by these sensor devices. Therefore, another brand called Belkin was used, according to Crossbows company recommendation,andthisworked[3]. Moreover,downloadingthelatestversionofIBMJava2SDKandIBMJava2JAVACOMM causedconflictswiththeTinyOSrpms.Therefore,thejavaversionbeforethelatestone wasusedinstead.

2.2 SettingupMICA2Motes
It is imperative to set up a suitable radio frequency for the motes to give them the opportunitytocommunicatewitheachotherthroughtheantenna.Otherwise,theywill notbeabletoreceiveanyinformationfromeachother.Thissortofsettingshouldbe

22

doneonceintheMakerulefilelocatedunder /opt/tinyos-1.x/apps/ byaddingtheline:

PFLAGS += -DCC1K_DEF_FREQ=916700000

Thislinetellsthemotesthattheradiofrequencyis916MHz.Moreover,thereisaspecial commandusedtoinstallprogramsinMICA2moteswhichwillperformthecompilation oftheprogramandthenuploadittothemote.Theprocessisasfollows: MIB510=COMx make mica2 install This command is under Windows 2000/XP, where x is the COM number connected to theUSBtoSerialcable.TheothercommandusedunderLinuxis: MIB510=/dev/ttyUSBx make mica2 install wherexisthenumberoftheUSBport.IftheserialportisusedinsteadoftheUSB,the commandwillbe MIB510=/dev/ttySx make mica2 install Where x is the number of the serial port Asmentioned,threedifferentprogramswereusedduringthisproject.Thefirstprogram waswrittentobeinstalledinmotes1,2,3,4toperformtheAODVroutingalgorithmand implementthewormholeattackdeterrent.Thisprogramiscalledsenderandislocated under the directory called AODV. This directory has been posted on a CD with this report.Gotothisdirectoryandtypethepreviouscommand.

Moreover, the second program was installed into motes (5, 6) that are connected to Stargate.Thisprogramiscalled:TOSBaseandcomeswiththeTinyOSplatform.Toinstall this program, go to the directory: /opt/tinyos1.x/apps/TOSBase/ and then execute the previouscommand. Finally,thethirdprogramwaswrittentobeinstalledintomoteno.7toactasaglobal clock.ThisprogramiscalledsenderandislocatedunderthedirectorycalledData.This directory has been posted on a CD with this report. Go to this directory and type the command that has been explained earlier to compile and install the program into the mote.

23

2.3 SettinguptheStargate
TosetuptheStargatesensordevices,itisnecessarytoconnectthemotesandtheWiFi flashcardtoeachStargate.Thissettingconsistsoftwoparts:settingthePCandsetting theStargatewhichwillbedescribedinthefollowingsubsections.

2.3.1 ConfigurethePC
IfthePChasLinux,thenrunthefollowingcommandstoconnecttotheStargateusing theUSBtoSerialcable[2]: 1.LoginasrootonyourLinuxhostmachine. 2.Typeminicoms TheMinicomconfigurationmenuappears. 3. Select Serial port setup. Configure Minicom to use the tty port that is connected to the target, for example /dev/ttyS0 (com1), 115200 baud, 8 data bits,Noparityand1stopbitandflowcontrolsettoNone. 4.PressEntertoreturntothemainconfigurationmenu. 5.SelectSavesetupasdfltosavetheseasdefaultsettings. 6.SelectExitfromMinicom.

YouhavenowsuccessfullyconfiguredMinicomtoaccesstheconsoleportforStargate. 1.WhenyouneedtoenterMinicomagain,youwillbeabletocommunicatewith yourtargetbyusingthecommandminicom 2.ToexitMinicom,usethecommand:CtrlAX 3.YouwillbepromptedtoconfirmthatyouwanttoexitMinicom.PressEnterto exit. 4.ForhelpusingMinicom,usethecommand:CtrlAZ If the PC has Windows 2000/XP, then use the HyperTerminal to connect to Stargate usingthesameparametersvaluesinminicom.

24

It is possible now to connect to Stargate and explore its files, but it is not enough to transferanyfileorprogramfromthePCtoStargate.Therefore,therearetwochoicesto enablefiletransfersbetweenthePCandStargate:eitheruseEthernetcableoruseWiFi connection.Tosetupthesecondchoice,runthefollowingcommandsinthePC: root#iwconfigethXessidGROUPNAME root#iwconfigethXmodeAdHoc root#iwconfigethXchannel3 root#iwconfigethXenc1234abcd1234abcd1234abcd12 root#ifconfigethX10.1.1.1netmask255.255.255.0 where X is the number of the WiFi card port and GROUPNAME is any name of the network chosen by the user. The IP addresses that have been used in this project are 10.1.1.1forthePC,10.1.1.2forStargate1,and10.1.1.3forStargate2.

2.3.2 ConfigureStargate
InStargate,itisnecessarytosetuptheWiFiflashcardusingthesamecommandsinthe PC,butwithdifferentchanges[7,8]: root#iwconfigwlan0essidGROUPNAME root#iwconfigwlan0modeAdHoc root#iwconfigwlan0channel3 root#iwconfigwlan0enc1234abcd1234abcd1234abcd12 root#ifconfigwlan010.1.1.2netmask255.255.255.0(forStargate1and10.1.1.3 forStargate2).

TheGROUPNAMEshouldbethesameforthePC,Stargate1,andStargate2.Afterthat, itispossibletotransferanyprogramorfilefromthePCtoStargateusingthefollowing command:

25

scproot@10.1.1.2:ptest/root/(where10.1.1.2or10.1.1.3andptestisthenameofthe executablefileaftercompilingtheprogram).

Inthisproject,twoprogramsareneededtobecompiledandinstalledinbothStargate sensor devices. The first one is called packet_test102.c under the directory /library/lib_serial/example,whichshouldbecompiledandinstalledinStargate1using thefollowingcommandsunderthesamedirectory: 1. OpenMakefilefileandchangethislinetobeMAINFILE=packet_test102 forStargate1,orMAINFILE=packet_test103forStargate2. 2. Runthefollowingcommand:make 3. Anexecutablefilecalledptestwillbegeneratedunderthesamedirectory 4. Runthepreviouscommand:scproot@10.1.1.X:ptest/root/toinstallthe programwhereX=2or3basedontheStargate. 5. To run the program in Stargate, do the following command: ptest /dev/tts/0

2.4 Summary
It is necessary to read this chapter in order to understand how to set up the environmentofalldevicesinvolvedinthisproject.Thischapterdescribedindetailhow tosetupthePCeitherunderWindows2000/XPorLinuxtoenableittocommunicate with the sensor devices. Next, it explained the steps to configure MICA2 motes by installingtheproperprogramsineachofthem.Finally,thestepsthatshouldbeusedto setupandinstallprogramsinStargatehavebeengiven.

26

Chapter3
BuildingtheTestBed
It is necessary to have a clear background about the sensor devices which have been used to build this test bed. A brief description about MICA2 Motes and the Stargate sensordeviceshasbeengiven. The design, implementation, explanation of the wormhole attack, and the implementationofitssolutionwillbedescribedinthischapter.InSection3.1,thetest bedsdesignisexplainedindetail,includingbothtypesofsensornodesofMICA2motes andStargate.Next,thealgorithmthatwasusedtoimplementtheproposeddesignwill bedescribedinSection3.2.Therearedifferentsolutionstowormholeattacks;theone that was implemented in this project will be illustrated in Section 3.3. After that, describinghowthissolutionwasimplementedinthisprojectwillbegiveninSection3.4. Finally,Section3.5providesabriefsummarythatconcludesthischapter.

3.1 DesignoftheTestBed
The objective of this project is to build an actual test bed to simulate the wormhole attack in wireless sensor networks. Deciding the design of a wireless sensor network was one of the important parts of this project. There are some assumptions for the chosennetworkdesign.Oneoftheseassumptionsisthatthechosennetworktopology is assumed to be fixed. This topology is composed of seven MICA2 Motes and two Stargatesensordevices.Figure3.1showstheproposeddesignofthetestbed.

27

Figure 3.1: Proposed Wireless Sensor Network Design. Where: Represents the MICA2 Mote. Represents the Stargate sensor device. Represents the WiFi connection. Represents the Radio connection.

Another assumption in this topology is that each node is assumed to know its neighbours. In this network design, the original source is Mote 1 and the original destinationisMote4.Mote7isactingasaglobalclock,whichwillkeepsendingaclock packettosynchronizealltheothermotes.EachMoteineachStargatewillonlyforward anyreceivedmessagefromtheradioconnectiontotheWiFiconnectionandviceversa withoutchangingthesemessages.Theroutingalgorithmthatwasusedinthistestbed is the Ad hoc On Demand Distance Vector (AODV). This routing algorithm will be explainedindetailinSection3.2. Moreover,thewormholeattackoccursduringthephaseofbuildingtheroutesbetween nodesinAODV.Theattackwillaffecttheroutingtableentriesintheoriginalsourceand 28

destination motes. Therefore, the actual path that a message should pass from the originalsourcetotheoriginaldestinationwillbeimprecise.Theimpactofthewormhole attack on the network will appear clearly in both the original source and the original destinationmotes.Theoriginalsourcemotewilldealwiththeoriginaldestinationmote asitsdirectneighbourandviceversa,whichisnotright,becausetheyareseparatedby twointermediatemotes.

After this brief description of the proposed design of the test bed, the following subsectionswillexplainindetailtheAODValgorithmthatwasusedinthistestbed.In addition,thewayofrunningtheAODValgorithminthetestbedandhowtodisplaythe assumednotationsinmotessuchascoloursoflightswillbeexplained.

3.2 TheAODVAlgorithm
TheAdhocOnDemandDistanceVector(AODV)routingalgorithmisaroutingprotocol designed for ad hoc mobile networks. It is an on demand algorithm, meaning that it buildsroutesbetweennodesonlyasdesiredbysourcenodes.Itmaintainstheseroutes aslongastheyareneededbythesources. AODV builds routes using route requests and reply query messages. When a source node desires a route to a destination for which it does not already have a route, it broadcasts a route request (RREQ) packet across the network. Nodes receiving this packetupdatetheirinformationforthesourcenodeandsetupbackwardspointersto thesourcenodeintheroutetables.AnodereceivingtheRREQmaysendaroutereply (RREP) if it is either the destination or if it has a route to the destination and the sequencenumberinRREQpacketisnotpresentinthenode.Ifthisisthecase,itsendsa RREP back to the source. Otherwise, it forwards the RREQ. Nodes keep track of the RREQ's packets by storing their sequence numbers. If they receivea RREQ which they havealreadyprocessed,theydiscardtheRREQanddonotforwardit.

29

As the RREP propagates back to the source, nodes set up forward pointers to the destination. Once the source node receives the RREP, it may begin to forward data packetstothedestination.Theroutingtableforeachnodewillbeupdatedaccordingto thehopcountfieldinRREQorRREPpackets.Thereceivedpacketwiththesmallesthop countwillbechosenasthebestroutepath.

However, in this project, not all of the AODV routing algorithm features have been implemented;featuresthatmeettheaimofthisprojectarejustimplementedforthe sakeofsimplicity.Forexample,featureslikesendingandreceivingRREQ/RREPpackets, andbuildingtheroutingtablesforeachnodewereimplemented,whereasfeatureslike maintainingtheroutepathsandsendinghellomessageswerenotimplemented. Thepseudocodeforallprogramsthathavebeenusedinthetestbedwillbeexplained inthenextsection.

3.3 TheImplementationoftheTestBed
According to the proposed design of the test bed, there are seven MICA2 Motes and two Stargate sensor devices. Two motes have been combined with the two Stargate sensordeviceswhicharemote5andmote6. Toimplementthetestbed,threetypesofprogramswerewrittenandinstalledinthe motesandtheStargatesensordevices.Thefirstprogramwasinstalledinmotes1,2,3, and 4, which is implementing a simple customized AODV algorithm. The second programwasinstalledinmotes5and6,whichissimplyforwardinganyreceivedpacket fromtheradioantennatotheserialportthatconnectsthemotewithStargateandvice versa,withoutchangingthispacket.ThethirdprogramwasinstalledinbothStargate1 and2.WhenapacketisreceivedbyStargatefromitsserialport,whichisconnectedto thecorrespondingmote,theprogramwillforwardittotheotherStargatethroughits

30

WiFiconnectionandviceversa.TheotherStargatewillreceivethispacketfromitsWiFi connection and forward it to its serial port, which is also connected to the correspondingmote.Thispacketisbroadcastedviatheradioantennaofthemote.The third program does not make any change in any sent or received packets. All these programsaredescribedindetailinthefollowingsubsections.

3.3.1 TheAODVProgram
Thisprogramperformsthemostimportantpartofthisproject,sinceitimplementsthe AODV routing algorithm, synchronizes with the global clock, and implements the deterrenttothewormholeattack.Thisprogramhasbeenwrittenincombinationwith thenesCandClanguagesandwasuploadedintoMote1,2,3,and4.Beforewritingthe pseudocode,abriefexplanationabouttheimportantvariableswillbegiven: First,thepacketformat:
0 1 2 3 4 5 Table 3.1: Packet format. 6 7 8

Where 0 1 2 3 4 5 6 7 8 = Original sender address. = Original destination address. = Current mote address. = Next mote address (used to deliver data). = Hop counter. = Message ID. = Message type. = Represents whether the packet comes from Mote or Stargate. = Time stamp.

Second, the two dimensions array to represent Routing Table Destination Address Next Hop
Table 3.2: Routing Table.

Hop Count

Third,onedimensionarraytorepresentRREQandRREPList

31

Then,thepseudocodeforthisprogramisasfollows: Initialization phase ; Send PKT ; // just for the source to start sending the packet Synchronize internal clock with the global clock; If ( PKT_MSG_Type == 0 ) then // RREQ Mode { if ( PKT_MSG_ID is not in RREQ List ) then { Add entry into Routing Table; Add PKT_MSG_ID into RREQ List; If ( PKT_Orig_Destin == Current_Mote_Address ) then preparing RREP PKT and send it; else forward PKT; } else { Check RT for PKT_Orig_Source and get the Hop_Count; If ( Hop_Count > PKT_Hop_Count ) then { update the entry in Routing Table; Send PKT; } } } else if ( PKT_MSG_Type == 1 ) then // RREP Packet { if ( PKT_MSG_ID is not in RREP List ) then { Add an entry into my RT (Routing Table); Add PKT_MSG_ID into RREP List; If ( PKT_Orig_Destin == Current_Mote_Address ) then { the RREP PKT reach its destination; send routing information for this mote; } else forward PKT; } else { Check RT for PKT_Orig_Source and get the Hop_Count; If ( Hop_Count > PKT_Hop_Count ) then

32

{ } }

update the entry in Routing Table; Send PKT;

} else if ( PKT_MSG_Type == 2 ) then { if ( PKT_Orig_Destin == Current_Mote_Address ) then the packet reach its destination; else { Check RT for PKT_Orig_Destin and get Next_Hop ; Send PKT for the next hop; } } End;

3.3.2 TOSBaseProgram
This program was written and delivered with the TinyOS tool kit as one of the many readymadeapplications. The nameof this application is TOSBase, which can be found under the application directory in TinyOS files (more details have been provided in Chapter2). As mentioned, this program simply forwards any received packet from the radio antenna of the mote to the serial port (51pin Hirose Connector), which is shown in Figure 1.1, without changing it. The mote is connected to Stargate through this serial port.ThisprogramiswritteninnesClanguageandwilluploadintoMotes5and6.This programspseudocodeisasfollows: Initialization phase; Event#1: if (Radio receive msg) then { Call UARTSendTask to send msg; // it will send msg to the // serial port } Event#2: if (UART receive msg) then

33

{ }

Call RadioSendTask to send msg; // it will send msg to the // radio

3.3.3 TheStargatePrograms
The program consists of two threads or processes. The first process is the main program,whichkeepslisteningtotheserialportconnectedtothemoteandsendsany receivedpackettotheclientsocket.TheclientsocketwillinitiateaWiFiconnectionwith theserversocketintheotherStargate.Thesecondthreadorprocessrunsasaserver that keeps listening to any client connection via WiFi. It receives the packet and forwardsittotheserialportconnectedtothemote,whichwillbroadcastthepacketvia itsradioantenna.Inthisproject,theprograminStargate1willonlyforwardmessages fromtheradiothatemitsfromtheoriginalsource,whichisMote1.TheotherStargate2 willonlyforwardmessagesfromtheradiothatemitsfromtheoriginaldestinationMote 4. The two versions of these programs are the same, except for one difference in checking the type of the message before starting to forward it. The first program in Stargate1hasbeenwritteninClanguageanditspseudocodeisasfollows: Initialization phase; Open Serial port; Run server thread with IP: 10.1.1.2; // it runs forever to receive any msg // from Stargate 2 with IP: 10.1.1.3 // and forward it to the serial port to // be sent by mote via radio While (1) do { If (Stargate receive a msg from the serial) then // the msg comes // from radio by mote 5 { If (msg comes from mote 1 and it is RREQ) then { Call client to forward the msg through WiFi to Stargate 2;

34

} } End;

TheotherprograminStargate2isalmostthesame,exceptforsomeconditions asfollows: Initialization phase; Open Serial port; Run server thread with IP: 10.1.1.3; // it runs forever to receive any msg // from Stargate 1 with IP: 10.1.1.2 // and forward it to the serial port to // be sent by mote via radio While (1) do { If (Stargate receive a msg from the serial) then // the msg comes // from radio by mote 6 { If (msg comes from mote 4 and it is RREP) then { Call client to forward the msg through WiFi to Stargate 1; } } } End; Theprogramusesotherwrittenfunctionssuchasopenserialport,readthepacketfrom serialport,andwritethepackettotheserialfromradio.

3.4 DemonstrationoftheTestBed
It is important to understand how the test bed is operating. The MICA2 Motes have some indicators which have been used to simulate this type of attack. Each Mote has three lights: red, green, and yellow. These lights have been used in this project to simplifythedemonstrationofthissolution,suchasshowinghowpacketsaretraveling fromoneMotetoanotherandshowingwhenandhowthewormholeattackhappens.

35

Forexample,whenthegreenlightblinks,thismeansthattheMoteissendingapacket. TheredlightindicatesthattheMotehasreceivedaRREQpacketfromotherMotes.The yellowlightturnsonwhentheMotehasreceivedaRREPpacketfromotherMotes.The greenandyellowlightstogetherindicatethataRREQorRREPhasbeenreceivedatthe destination.Itiscleartosaythattheredlightwillbeseenbeforetheyellowlight,since therequestpacketcomesbeforethereply.However,iftheyellowlighthasbeenseen before the green light, this means that a wormhole attack has been detected. The reasonforthisisthatthereplycomesbeforeorfasterthantherequestpacket.Bydoing this,itiseasiernowtounderstandwhatishappeningduringthedemonstration.

3.5 VisibilityoftheWormholeAttack
There are two situations to run the test bed. The first situation demonstrates the customized AODV routing algorithm without implementing the wormhole attacks. In other words, it demonstrates the customized AODV without the Stargate sensor devices.Thesecondsituationdemonstratesthewormholeattackbesidethecustomized AODV. Todemonstratethefirstsituation,itisimportanttoturntheStargatesensordevicesoff. Thewormholeattackwillnotoccurinthissituation.Tostartthisdemonstration,firstly turn on Motes 2, 3, 4, and 7. Then, turn on Mote 1 which acts as the original source. Mote1willstartsendingtheRREQpacketbyblinkingitsgreenlight.Thissendingwill occur after being synchronized with the global clock. Mote 2 will receive the RREQ packet,turnonitsredlight,andforwardthispacketbyblinkingitsgreenlight.Mote3 will do the same thing that Mote 2 has done. Finally, Mote 4 will receive the RREQ packet, turn on its red and yellow lights, indicating that the RREQ has reached its destination,andpreparetheRREPpacket.ThesameprocesswillhappenfortheRREP packet,butthedifferenceisthateachMotewillturnonitsyellowlightonreceivingthe RREPpacket.Finally,Mote4willturnonitsredandyellowlightsonreceivingtheRREP packetindicatingthattheRREPhasreacheditsdestination.

36

TheothersituationdemonstratesthewormholeattackbyaddingthetwoStargateswith theirMotes.Firstly,turnonallMotesandStargates,exceptMote1whichistheoriginal source.Then,turnonMote1tostartsendingtheRREQpacket.Inthissituation,Mote4, whichistheoriginaldestination,willreceivetheRREQfromMote1directlythroughthe Stargate path, since the WiFi path is faster than the radio path. This happens when Mote 5 receives the RREQ packet from Mote 1 and sends it directly through the WiFi connectiontotheotherStargate.Mote6intheotherStargatewillsendthispacketto Mote4viaitsradioantenna.TheRREQpacketwilltravelthroughtheWiFiconnection faster than the normal path which is through the intermediate Motes 2 and 3. In this situation,Mote4willthinkthatMote1isitsdirectneighbouranditwillturnonitsred andyellowlightsinpreparationfortheRREPpacket.Mote4willsendtheRREPpacket whichwillbedeliveredthroughtheWiFiconnectionbetweenthetwoStargates.Mote1 willturnonitsredandyellowlightswhenitreceivestheRREPpacket.Also,Mote1will thinkthatMote4isitsdirectneighbourandthisishowthewormholeattackhappens.It ispossibletodisplaytheinformationofthepacketsandthefinalroutingtableinMote1 byusingaPC.MoredetailsofhowtoperformthathavebeenprovidedinChapter3. There are a number of techniques to solve the wormhole attack in a wireless sensor network. Some of these techniques will be briefly described in section 3.6. The implementationofoneofthemwillbeexplainedinsection3.7.

3.6 WormholeAttackSolution
Asmentioned,thewormholeattackinawirelessnetworkisasevereattackwhichmay cause damage and changes in the network. To detect and deter such attacks, some proposed solutions have been presented in different papers. One of them will be describedinthissection.

37

There is a wormhole attack solution that could be applied and implemented in this project. This solution is called packet leashes, which is a general mechanism that can detectandpreventwormholeattacks.Aleashisaportionofinformationthatisadded tothepackettorestrictitstravelingdistanceortime.Thissolutionconsistsoftwotypes of leashes: geographic leashes and temporal leashes. Each of these types will be describedbrieflyinthissectionandmoredetailsareavailablein[5]. A geographic leash detects and prevents the wormhole attack by ensuring that the sender and the receiver are within a specified distance. To do that, each node must knowitslocationandbetimelysynchronizedwithothernodes.Whenthesenderstarts sending the packets, it stores its location and the sending timestamp in the packet. Then,thereceiverwillcalculateitslocationandthereceivingtimestampandcompare themwiththevaluesinthepacket.Bydoingthat,thereceivercandetectifthesender iswithinitsdistanceornot,whichwillhelpdetectionandpreventionofthewormhole attack.Formoredetailsonhowthegeographicleashworks,referto[5]. The other type of solution is a temporal leash. It detects and prevents the wormhole attackbyensuringthatthepacketstravelingtimeiswithinaspecifiedperiodoftime. To do that, all nodes must be timely synchronized in terms of their clocks. When the senderstartssendingthepackets,itstoresitssendingtimestampinthepacket.Then, the receiver can compare its receiving timestamp with the value in the packet. Therefore, the receiver will be able to detect if the packet traveled as fast as the specifiedtransmissiontime.Formoredetailsonhowthetemporalleashworks,referto [5]. Inthistestbed,thetemporalleashsolutionhasbeenusedandimplementedtodetect andpreventthewormholeattackinthewirelesssensornetwork.Thegeographicleash solutionwasnotconsideredinthisproject,becauseitiscomplicatedtoimplement.This solutionneedsspecialhardwarethatcanspecifythelocationsofallnodessuchasGPS, whichisexpensiveandunavailableforthisproject.

38

Instead,theconceptofthetemporalleashwasusedtoimplementthesolutioninthis project. In the proposed network design, six MICA2 Motes were used. An additional MICA2Mote,whichisno.7inFigure3.1,wasconsideredasaglobalclockfortheother Motes.EachMotewillsynchronizeitselfaccordingtotheglobalclock.Inthiscase,the temporalleashsolutioncanbeeasilyimplementedusingthisglobalclock.Anexpected range of transmission time of the packet from the original source to the original destinationwasdetermined.Moredetailsabouttheimplementationofthissolutionwill beexplainedinthenextsection.

3.7 TheImplementationofthePacketLeashesSolution
As discussed earlier, a timing mechanism is required to distinguish if the packet is received from the fake path or the real path to avoid the wormhole attack. A packet received from Stargate is going to be faster than the packet received from the Mote since the WiFi transmission is faster than the radio transmission. Therefore, applying this timing mechanism will allow the destination to recognize the real packet by comparingitstimestampwiththetimestampofthereceivedpacket.Ifthedifference betweenthesetwotimestampsislessthanorequaltoX,thismeansthatitisafake packet. To compute the value of X according to the project design:
5 6

Figure 3.2: Project Design.

39

There is a transmission delay in each Mote. The average transmission delay is around 45 msec (Tr = 45 msec). [6]

The real path consists of Motes 1,2,3, and 4 where the fake path consists of Motes 1,5,6, and 4.

The processing time at each Mote will be neglected since both paths have the same number of Motes. Therefore, the total processing time for the Motes in each path will be almost the same.

The WiFi transmission delay is neglected since the data rate is high.

Delay on the real path: = = = No. of Motes that will do transmission X Tr 3 ( Motes 1,2, and 3 ) X 45 3 Tr

Delay on the fake path: = = = No. of motes that will do transmission X Tr 2 ( Motes 1 and 6 ) X 45 2 Tr.

Therefore, the destination is able to distinguish between the real andfake packets by subtracting the time stamp at the destination by the time stamp at the source. If the result<=2Tr,thenthepacketisfake.Otherwise,itisreal.

3.8 Difficulties
Unfortunately, synchronization cannot be applied at this stage since there is no clock implementedintheMote.Consequently,aglobalclockhasbeenimplementedtosend thecurrenttimeperiodicallytotheotherMotes.Then,theMoteswillupdatetheirlocal timeaccordingtowhattheyhavereceived.Inthisway,thesynchronizationofallMotes withtheglobalclockcanbeachieved.Then,thetimingmechanismcanbeapplied.

40

However, there is still a scenario where a wormhole attack can not be detected, especiallyiftheenvironmentisnotreliableandsomeclockpacketsmightbedropped. Ashasbeenknown,therearefourclocksbetweenthesenderandreceiverinthereal path,butonlythreeclocksinthefakepath.Therefore,ifthedestinationhasdropped thefourthclockpacket,thelocaltimeatthedestinationwillbethreeclocks.Therefore, thedifferencebetweenthetimestampatdestinationandsenderwillbejusttwoclocks. This means that the destination will drop the packet, assuming it is a fake packet accordingtotheformulaabove.

3.9 Summary
Thesimulationofthewormholeattackinawirelesssensornetworkneedstoproposea testbeddesignthatwillbeusedtodoingthat.Furthermore,proposedalgorithmswere implementedandinstalledineachsensordeviceinthistestbed. This chapter explained the proposed network design that was used to build this test bed.Moreover,someassumptionsonthisdesignwereprovided.Thedesignisassumed to be fixed and consists of seven MICA2 Motes and two Stargate sensor devices. The AODV algorithm was described to understand how the sensor devices in this test bed will communicate with each other. Some of these sensor devices use a customized AODV algorithm, which has been illustrated. In addition, the algorithm used in the Stargatesensordeviceswasexplained. Finally,somesolutionsforthewormholeattackwereprovidedinthischapter.Oneof these solutions was explained and implemented with some changes made in this project.

41

Conclusionandfuturework
The rapid development in the wireless sensor networks field has allowed this technologytobeusedinmanyapplications.Someoftheseapplicationsarecriticaland require secure and trusted environments. Therefore, different research studies have beenconductedtoanalyzethewirelesssensornetworksanddiscovertheirthreats.One of the attacks which may damage wireless sensor networks is the Wormhole attack. Thus,thisprojecttriedtobuildatestbedofagroupofsensordevicestosimulatethe wormholeattackandimplementoneofthesolutionstodetectandpreventthisattack. Thisreporthasexplainedtheprocessesfollowedinthisproject.First,abriefbackground aboutthesensordevicesoftheMICA2MotesandStargatewasgiven.Then,itexplained thedesignandtheimplementationofthetestbedbydescribingtheproposednetwork topology,thealgorithms,andthechosensolution.Finally,detailedstepsofsettingup the environment of all the devices used in this project were illustrated. In future, the timingmechanismthatwasusedmightbeimprovedon,especiallywiththenewversion of TinyOS that gives the opportunity to implement internal clocks in the Mote. In addition, this project could be enhanced by some additional improvements. One of these improvements is to apply this test bed on a large wireless sensor network. Moreover, different solutions for the wormhole attacks could be implemented and evaluated.

Acknowledgment
TheauthorswouldliketoacknowledgeWenHu,aPhDCandidate,CSE,UNSW,forhis supportwithsettinguptheenvironmentforTinyOS,Mica2,andStargate.

42

References
[1] Crossbow Technology, Inc., MPR/MIB Mote Hardware Users Manual, http://www.xbow.com/Support/Support_pdf_files/MPR MIB_Series_Users_Manual.pdf [2] Crossbow Technology, Inc., Stargate Developers Manual, http://www.xbow.com/Support/Support_pdf_files/Stargate_Manual.pdf [3] Crossbow Technology, Inc., FAQ, http://xbow.custhelp.com/cgi bin/xbow.cfg/php/enduser/std_alp.php [4] Ganeriwal, S., Kumar, R., & Srivastava, M.B. Timingsync protocol for sensor networks, ACM Conference on Embedded Networked Sensor Systems (SENSYS 2003). [5] Hu, Y., Perrig, A., & Johnson, D.B. Packet Leashes: A Defense against Wormhole Attacks inWireless AdHoc Networks, Proceedingsof the TwentySecond Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM 2003),vol.3,pp.19761986,IEEE,SanFrancisco,CA,April2003. [6]Paek,J.,Chintalapudi,K.,&Govindan,R.AWirelessSensorNetworkforStructural HealthMonitoring:PerformanceandExperience2005. [7]StargateMailingList,http://www.cens.ucla.edu/pipermail/stargateusers [8]TinyOSwebsite,http://www.tinyos.net/tinyos1.x/doc/install.html [9] TinyOS Mailing List, http://www.tinyos.net/search.htmlhttp://www.cens.ucla.edu/pipermail/stargate users/

43